[EFM-OAM] Today's OAM conference call
Here are my notes on today's conference call.
Attendees: Matt Squire, Brian Arnold, Floyd Gerhardt, David Martin
In general, there were more comments on the frame formats and processing sections then on the earlier sections. I guess that means there's still more work to do here. Specific issues discussed are below.
The next conference call is THURSDAY, 1PM EASTERN. We will focus that call on non-Clause 57 items (Clause 30 in particular, but also 22, 36, 43B, etc.).
- Matt
-----------------------------
Error handling. We're still a bit weak in the specification of error handling. In particular the following issues were mentioned:
a) What do we do if we get an unknown op-code?
b) What do we do if we get an unexpected TLV type?
c) What to do if you get a TLV with the length less than expected?
d) What to do if you get a TLV with length greater than expected?
e) What to do if the TLV length is not correct (i.e. the frame ends first)?
f) Anywhere anything is reserved, it should be specified to ignore (or handle somehow) [Tables 57-5, 57-13, etc.]
It was suggested that we need better specifications on handling these error cases, where the remedy is likely to be
- ignore things you don't understand
- use a counter (# unknown op-codes, etc.) to help out for debugging
- if TLV lengths are >= expected, then use them as you expect and ignore extra bytes (allows TLVs to grow over time)
Some of these conditions were mentioned in comments of D1.3 but not adequately covered in our responses.
Action: Matt to comment on the above. Everyone should think about the negative test cases when doing their review this time to ensure behavior is adequately specified.
==================================
Timestamps. Spent a lot of time talking about timestamps again, in particular if they're needed at all, and whether they should be in the Event TLVs, the Event PDU, or both. We agreed to keep timestamps in the TLVs, but not in the PDUs.
Action: Floyd, Brian, and David to work off-line to figure out the appropriate comment(s) and wording.
==================================
Events and active/passive mode. The draft is currently written so that Active nodes don't send event notifications to passive nodes. We spend some time talking about the justification for this. The justification provided was basically that someone raised a concern that the events may violate some privacy concerns for the carrier (e.g. an event might inform the customer that the error rate is high, or something). However, the participants on the call didn't feel that this was a strong enough concern to override the benefits of the events. We decided that events should happen independently of the mode (active/passive) of the participants.
IF YOU DISAGREE WITH THIS DECISION, SHOUT NOW.
Action: Matt to make the comment.
==================================
Reserving zero. The call participants didn't understand the Editor's reluctance to use the value "0" very much, as it appears to be reserved in many tables though not all. As zero is a valid value, it would seem to make sense to allow it. This was brought up in the context of the loopback command. Loopback commands use 0x01 and 0x02 to enable/disable loopback mode, whereas 0x00 and 0x01 are generally "off"/"on" values.
Action: Ask editor why he hates the value zero.
===================================
TLV Processing. The TLV processing is not defensive enough. In particular, as pointed out earlier, we don't specify how to handle unexpected type values, or unexpected length values, or unexpected values in the value field (e.g. if an upper or lower bound is violated). Additionally, we currently use a single zero octet (0x00) to indicate the end of TLVs. It was suggested that we should use a real TLV as the end of TLVs, i.e. TLV type=0, TLV length=2 (0x0002) as an end-of-TLVs TLV.
Action: Matt to make the comment.
===================================
Event Definitions. We found it difficult to understand the descriptions of the events in the event section, in particular the Errored Frame Seconds Summary Event:
- Does this event indicate a threshold on the number of "Errored Frame Seconds", or a threshold on the number of "Errored Frame Second Events"?
We thought it to be the former, but weren't sure. After discussion, we decided it should be the former (threshold on the "Errored Frame Seconds").
Action: Floyd to offer better descriptive text for all event descriptions.
==================================
Passive mode optional? The PICS seem to indicate (57.8.2.3) that passive mode is optional to implement. We found this to be strange and that the requirement should be along the lines of
- An implementation may implement both Active and Passive mode
- An implementation must implement at least one of Active or Passive modes
Action: Clarify intent of PICS clause with editor and make suggested changes as needed.
===================================