Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2
RFC 6240
Yes
(Mark Townsley)
(Ralph Droms)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Gonzalo Camarillo)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Sean Turner)
(Tim Polk)
Note: This ballot was opened for revision 16 and is now closed.
Lars Eggert
No Objection
Comment
(2011-02-03)
Unknown
Section 7., paragraph 54: > An agent with CEP capability MUST be capable of supporting > at least n intervals. The minimum value of n is 4, the > default of n is 32 and the maximum value of n is 96. I don't get this. How can you state a MUST requirement for a specific value, and then give a range for that value?
Adrian Farrel Former IESG member
Yes
Yes
(2011-02-02)
Unknown
I'm entering a 'Yes' ballot because this work is technically sound and useful. However, I found a slew of nits that really should be worked on to make the RFC more valuable. --- The various write-ups and announcements should be updated to reflect the new responsible AD --- The double page-throws are a nuisance --- Section 1 Need to expand CEP on first use --- Section 2 The mechanism for structured emulation (as outlined in the CEP draft) Hmmm? do you mean RFC 4842? --- Section 2 s/Since A SONET/Since a SONET/ --- 6.3. PW-STD-MIB Modules Usage s/Modules/Module/ --- Section 7 The comments on the IMPORT clauses are welcome, but should not show in square brackets as they are not references (because the MIB module is standalone with section 10. --- Section 7 You can remove the two notes to the RFC Editor in the IMPORTS clause as you have already fixed up the RFC numbers yourselves. --- MODULE-IDENTITY DESCRIPTION CLAUSE -- RFC Editor: Please replace yyyy with actual RFC number and -- remove this note I think this is xxxx --- TEXTUAL CONVENTIONS I'm a bit disappointed that the TCs defined here don't come with REFERENCE clauses. --- PwCepFracAsyncMap, pwCepType, pwCepFracMode, pwCepFracSdhVc4Mode, and pwCepPerfIntervalReset Although not a requirement, it is usual for INTEGER enumerations to start at zero. Sometimes other schemes are used to stay in synch with protocols - if so, it is nice to say so and give a reference. --- pwCepEntry however change of some objects (for example pwCepCfgIndex) during PW forwarding state MAY cause traffic disruption. s/MAY/may/ --- pwCepValidIntervals Telling us the default value for a read-only object is a little distracting. --- pwCepPeerCepOption How is this object set when the PW is statically provisioned? --- pwCepCfgIndex Should indicate what meaning is assigned to the value zero since zero is not a valid index to pwCepCfgTable --- pwCepCfgJtrBfrDepth The actual jitter buffer MUST be at least twice this value for proper operation. I think this warrants a REFERENCE --- pwCepFracSdhVc4Tu3Map1 and similar objects "If the first TUG-3 within the VC-4 contains a TU-3, this variable must be set to the required mode. " DEFVAL { other } So, I was going to say s/must/MUST/ but since you have a DEFVAL defined for each case, I don't understand the meaning of the text. --- pwCepPerfCurrentAbsPtrAdjust. pwCepPerfIntervalAbsPtrAdjust, and pwCepPerf1DayIntervalAbsPtrAdjust Are the Description clauses in English? --- pwCepPerfIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number (normally between 1 and 96 to cover a 24 hour period) which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15-minute interval and the interval identified by N is the interval immediately preceding the one identified by N-1. The minimum range of N is 1 through 4. The default range is 1 through 32. The maximum value of N is 1 through 96." I'd be interested in the non-normal case given the SYNTAX ! I find the text about ranges clumsy. Anyway, since the object is not-accessible, it is moot. --- UNITS clauses would be nice in objects like pwCepPerfIntervalTimeElapsed and pwCepPerfIntervalInPtrAdjustSecs --- pwCepPerf1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32(1..31) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the current day measurement period, interval 2 is the most recent previous day; interval 30 is 31 days ago. Intervals 3..31 are optional." ::= { pwCepPerf1DayIntervalEntry 1 } What does "optional" mean in a not-accessible object? --- pwCepPerf1DayIntervalUASs looks like it needs a Reference clause --- Section 10.1 As indicated by idnits... The RFC number is missing from the BCP14 reference. ---
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(2011-03-07)
Unknown
This is a placeholder comment to note that the following were not addressed as of version 15 of the document. Lars Eggert Comment (2011-02-03) Section 7., paragraph 54: > An agent with CEP capability MUST be capable of supporting > at least n intervals. The minimum value of n is 4, the > default of n is 32 and the maximum value of n is 96. I don't get this. How can you state a MUST requirement for a specific value, and then give a range for that value? SB> I see no text change. Adrian Farrel Comment (2011-02-02) Section 2 The mechanism for structured emulation (as outlined in the CEP draft) Hmmm? do you mean RFC 4842? --- Section 7 You can remove the two notes to the RFC Editor in the IMPORTS clause as you have already fixed up the RFC numbers yourselves. SB> The Editors note is still there for PWMIB - isn't that an RFC? --- TEXTUAL CONVENTIONS I'm a bit disappointed that the TCs defined here don't come with REFERENCE clauses. --- PwCepFracAsyncMap, pwCepType, pwCepFracMode, pwCepFracSdhVc4Mode, and pwCepPerfIntervalReset Although not a requirement, it is usual for INTEGER enumerations to start at zero. Sometimes other schemes are used to stay in synch with protocols - if so, it is nice to say so and give a reference. SB> Does not seem to be addressed --- pwCepValidIntervals Telling us the default value for a read-only object is a little distracting. --- pwCepPeerCepOption How is this object set when the PW is statically provisioned? --- pwCepPerfCurrentAbsPtrAdjust. pwCepPerfIntervalAbsPtrAdjust, and pwCepPerf1DayIntervalAbsPtrAdjust Are the Description clauses in English? --- pwCepPerfIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number (normally between 1 and 96 to cover a 24 hour period) which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15-minute interval and the interval identified by N is the interval immediately preceding the one identified by N-1. The minimum range of N is 1 through 4. The default range is 1 through 32. The maximum value of N is 1 through 96." I'd be interested in the non-normal case given the SYNTAX ! I find the text about ranges clumsy. Anyway, since the object is not-accessible, it is moot. --- pwCepPerf1DayIntervalUASs looks like it needs a Reference clause
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2011-01-23)
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-02-01)
Unknown
Please remove this paragraph prior to publication: Comments should be made directly to the PWE3 mailing list at pwe3@ietf.org.
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown