1. Proposal for Simple Diagnostics
Month Year
November 2005
November 2005
Proposal for Simple Diagnostics
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Joe Epstein
Joe Epstein

2. Month Year
November 2005
November 2005
Abstract
This document contains an outline of the Simple Diagnostics proposal in document v-simple-diagnostics.doc, fulfilling requirement 2070.
Joe Epstein
Joe Epstein

3. Month Year
November 2005
November 2005
What is Simple?
Just allow management frames to encode a nearly-arbitrary block of strings and codes.
Strings and codes are nearly human-readable—a log message, essentially.
STA (probably non-AP) places the IE in management frames, to send up to a log-collecting “function” the contents.
Joe Epstein
Joe Epstein

4. November 2005
Why Simple?
Key takeway: the implementer knows best what information is important.
Most stations have more reasons for doing things than we can code or assign, here.
Although there is a class of diagnostic events (such as standard traps that the other proposals mention) that ought to be looked at, there are a lot more events that are not in common across devices.
Thus, let the implementer own the space of diagnostic messages.
Very analogous to remote syslog
Syslog messages are somewhat human readable.
They are conveyed across the network, if activated by the administrator.
Joe Epstein

5. November 2005
Proposed Changes
Capabilities flag on AP to advertise that log messages should be added.
The turning on or off of this shall not require a reassociation of any clients.
The posting of diagnostic log messages is always optional.
Posting should not be done if the AP doesn’t advertise support for it, unless explicitly activated on the client.
Then, add IE to all Management Frames
Additionally, dedicate a special Action frame to convey any non-management-triggered events.
Like an arbitrary syslog post
Joe Epstein

6. Proposed Diagnostic Log IE
November 2005
Proposed Diagnostic Log IE
Element ID
Length
Vendor
OUI
Flags
In Response
To Field
(optional)
Log Message
Code
Reporter Version
Octets: 1 6 10 4
Variable
Specifies arbitrary (but hopefully ASCII-like)
Device Version
Log Message
Contains optional information about any one frame that led to the generation of this log message.
Separates out all of this arbitrariness by Vendor OUI.
Joe Epstein

7. Proposed Diagnostics Log Message Action Frame
November 2005
Proposed Diagnostics Log Message Action Frame
If the STA has log messages queued up, or wishes to send log messages that are not caused by any particular exchange, it can send this frame.
This Action frame contains the IE at the end (not even specified as a part of the frame itself).
The frame contains an optional TSF of the BSS when the log message was generated, if known.
Category
Action
TSF
Octets: 1 8
Figure v4— Roaming Management Query frame body format
Joe Epstein

8. Benefits Yes, the contents are truly wide-open Very simple
November 2005
Benefits
Yes, the contents are truly wide-open
For protocols proper, this is a bad thing. You need to know, as an implementer, what the other devices will do with your messages.
But for logs, this is a good thing. You want the freedom to convey whatever information you see fit.
Very simple
Joe Epstein

9. Consequences No standard for the contents Why do this at all, then?
November 2005
Consequences
No standard for the contents
And we are a standards body!
Why do this at all, then?
I believe that only implementers can meaningfully define their log messages.
There is tremendous value in having an arbitrary log message carrying protocol, without regard to the contents of the log. Syslog is very effective, when used that way.
Thus, like people do with syslog, we hope that implementers publish their error and log codes, and that they maintain some discipline in the construction of the codes.
Why not syslog, then?
Requires an active, associated link, IP, some server discovery infrastructure, the log message itself… Too much, and not usable when things are not working at L2!
Joe Epstein

10. Consequences (II) High overhead
November 2005
Consequences (II)
High overhead
Really, this should be turned on selectively.
But this is not something new to logging…the tradeoffs are well understood.
Joe Epstein

11. Open Issues Security Activation
November 2005
Open Issues
Security
These messages leak a lot of information.
They also take a lot of resources.
I envision having the ability to trigger only in Class 3, and the ability to buffer out-of-class messages and to convey them in Class 3 when the STA next comes into the network.
However, I did not write this in the normative text yet, and so I left out the capabilities flag there.
Activation
There should be a STA-specific Action frame exchange to turn on logging.
Joe Epstein