Tom: thank you for extensive review and, from my perspective, very valid comments.
Deepak: thank you for accommodating Tom’s concerns. I have decided to ballot no-obj; please continue the discussion to determine if something additional is needed for the restart question. Jari On 16 Aug 2015, at 18:15, Tom Taylor <[email protected]> wrote: > For an example, look at > <https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/?include_text=1>. > Search on the text "DiscontinuityTime". You will find several instances, > relating to the different tables. A discontinuity can happen not just because > of restarts, but also when a new object is configured. > > Tom > > On 16/08/2015 1:47 AM, Deepak Kumar (dekumar) wrote: >> Hi Tom, >> >> Thanks for detailed review. >> I have taken care of all comments except need guidance on below comment. >> >> 4) Has any thought been given to including an indication of when the >> counters were last reset (e.g, due to restart)? >> >> Please provide more details on scenario of restart. >> >> >> Thanks, >> Deepak >> >> On 8/14/15, 6:40 PM, "Tom Taylor" <[email protected]> wrote: >> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. Sorry for the late review, but there was a pile of >>> reading to do in preparation. I admit I did not read the whole 1800 >>> pages of 802.1Q. >>> >>> Tom Taylor >>> >>> Document: draft-ietf-trill-oam-mib-06 >>> Reviewer: Tom Taylor >>> Review Date: 2015-08-14 >>> IETF LC End Date: 2015-08-13 >>> IESG Telechat date: 2015-08-20 >>> >>> Summary: Not quite ready. Minor issues and editorials/nits. >>> >>> Major issues: >>> >>> Minor issues: >>> >>> 1) Section 5.2 states that IEEE8021ServiceSelectorType has two values. >>> In fact, 801-1Q-2014 enumerates more than that. I'd suggest a slight >>> change in wording to reflect this: >>> >>> OLD >>> >>> IEEE8021-TC-MIB defines IEEE8021ServiceSelectorType with two values: >>> >>> - 1 representing a vlanId, and >>> >>> - 2 representing a 24 bit isid. >>> >>> NEW >>> >>> The IEEE8021-TC-MIB definition of IEEE8021ServiceSelectorType includes >>> the two values: >>> >>> - 1 representing a vlanId, and >>> >>> - 2 representing a 24 bit isid. >>> >>> 2) Section 6.2 indicates that TRILL OAM has no support for Link Trace >>> Message/Reply. Perhaps text could be added to say why this is so (i.e., >>> that Path Trace has been substituted, as indicated in Sec. 10 of RFC >>> 7455, and has been supplemented by Multi-destination Tree Verification >>> Message/Reply). >>> >>> 3) "Reference Overview" in the MIB module header indicates that the >>> TRILL MIB module refers to the original CFM document, IEEE 802.1ag-2007, >>> instead of IEEE 802.1-Q-2014. Why the older starting point? >>> >>> 4) Has any thought been given to including an indication of when the >>> counters were last reset (e.g, due to restart)? >>> >>> 5) description of trillOamMepTxPtmStatus refers to the MEP Initiator >>> State Machine. Reference should include pointer to the description of >>> this state machine. Where is it defined? -- not in RFC 7455. Similar >>> comment regarding the description of trillOamMepTxMtvmStatus. >>> >>> 6) Description of trillOamMepTxPtmMessages: there is no indication in >>> RFC 7455 of how this limit is used. More text is needed here. Does >>> number of hops affect the count of transmitted messages against this >>> limit? Similar comment regarding the description of >>> trillOamMepTxMtvmMessages. >>> >>> 7) Surely this document has normative dependencies on 802.1Q and the >>> LLDP-MIB, for which no reference is given, BTW. >>> >>> >>> Nits/editorial comments: >>> >>> 1) Under "Abbreviations" in the MIB module header, definition of SNMP >>> Agent, need to spell out NE. Similarly, spell out EMS and NMS in the >>> next definition. >>> >>> 2) Description of trillOamMepTable: s/rowsare/rows are/ >>> >>> 3) in the descriptions of trillOamMepPtrFlag and >>> trillOamMepPtrErrorCode, incorrect section numbers for RFC 7455 are >>> given in the references. Should be 8.4.3? >>> >>> 4) Description of trillOamMepPtrIngress: s/PTM/PTR/. Similar comment for >>> trillOamMepPtrEgress. >>> >>> 5) Syntax error for trillOamMepPtrIngressPortIdSubtype: syntax should be >>> LldpPortIdSubtype. Descriptions of trillOamMepPtrIngressPortIdSubtype >>> and trillOamMepPtrIngressPortId should be interchanged. Similar comments >>> for trillOamMepPtrEgressPortIdSubtype and trillOamMepPtrEgressPortId. >>> Note that syntax is also stated in the Entry definition and has to be >>> fixed there, too. >>> >>> 6) Same problem as 5) for the corresponding trillOamMtvrTable objects. >>> >>> 7) Security Considerations, third para, first-to-second lines: >>> s/MAC-ACCESS/MAX-ACCESS/ >> >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
