Re: [Gen-art] Last Call review of draft-ietf-trill-oam-mib-06

[Tom Taylor <[e-mail]>]

I recommended a short-term solution in this module alone in off-line 
discussion. In the longer term, there should be a coordinated update of 
this module and the IEEE module to move the discontinuity time object 
into the latter, while retaining references to that object in the 
descriptions of the counters.

Tom

On 19/08/2015 5:12 PM, Deepak Kumar (dekumar) wrote:
> Hi,
>
> I have updated latest draft taking care of discontinuity time also.
>
> Thanks,
> Deepak
>
> On 8/19/15, 2:06 PM, "Jari Arkko" <[e-mail]> wrote:
>
>> 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 <[e-mail]> wrote:
>>
>>> For an example, look at
>>> <https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/?includ
>>> e_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" <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>
>