Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21

[Hitoshi Asaeda <[e-mail]>]

Greg and Lenny,

We addressed all comments given by the Gen-ART reviewer now.
Can I submit the revised draft (-22) to IETF now?
Or shall I do other procedures without (or before) submission?

(Note that the IANA comments are not addressed yet.)

Regards,

Hitoshi

From: Meral Shirazipour <[e-mail]>
Subject: RE: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
Date: Sat, 25 Nov 2017 04:57:12 +0000

> Hi,
>   Thank you for considering the comments.
> 
> Best,
> Meral
> 
> -----Original Message-----
> From: Hitoshi Asaeda [mailto:[e-mail]] 
> Sent: Thursday, November 23, 2017 10:59 PM
> To: Meral Shirazipour <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
> 
> Dear Meral Shirazipour,
> 
> Thank you for your careful review.
> (And sorry for this late response.)
> 
> We've almost addressed your comments, and will submit the revision whenever we, co-authors, agree on the changes.
> 
> Please see inline.
> 
> Subject: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
> Date: Fri, 17 Nov 2017 20:57:07 +0000
> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
>> For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> 
>> Document: draft-ietf-rtgwg-rlfa-node-protection-09
>> Reviewer: Meral Shirazipour
>> Review Date: 2017-11-16
>> IETF LC End Date:  2017-11-23
>> IESG Telechat date: NA
>> 
>> Summary:
>> This draft is ready to be published as Standards Track RFC but I have comments.
>> 
>> Major issues:
>> Minor issues:
>> Nits/editorial comments:
>> -please spell out acronyms at first use.
> 
> Thank you. Done.
> 
>> -[Page 7,8]
>> "If an implementation receives an
>>    unknown TLV type for the first TLV in a message, it SHOULD ignore and
>>    silently discard the TLV and any subsequent TLVs in the packet
>>    containing the TLV.  If an implementation receives an unknown TLV
>>    type for a subsequent TLV within a message, it SHOULD ignore and
>>    silently discard the TLV.  If the length of a TLV exceeds the
>>    available space in the containing packet, the implementation MUST
>>    ignore and silently discard the TLV and any remaining portion of 
>> the containing packet.  Any data in the packet after the specified TLV
>>    length is considered to be outside the boundary of the TLV and MUST
>>    be ignored during processing of the TLV.
>> "
>> 
>> this whole paragraph is a bit confusing.
>> 
>> e.g. "If an implementation receives an unknown TLV type for the first 
>> TLV in a message", is this refering to the header TLV?
> 
> Yes. It is referring to the header. This is clarified in the proposed re-wording as follows;
> 
> "If an implementation receives an unknown TLV type for the first TLV in a message (i.e., the header TLV), it SHOULD ignore and silently discard the entire packet."
> 
>> e.g. "If an implementation receives an unknown TLV type for a 
>> subsequent TLV within a message, it SHOULD ignore and silently discard 
>> the TLV.", does this mean TLVs after this one TLV should not be 
>> discarded?
> 
> For this statement, I'm asking to other co-authors to confirm the meaning, because I (Hitoshi) think this wording gives a wrong impression. We will clarify this statement in the revision ASAP.
> 
>> e.g. "Any data in the packet after the specified TLV length is 
>> considered to be outside the boundary of the TLV and MUST be ignored 
>> during processing of the TLV.", does this apply to last case only of 
>> when the length of a TLV exceeds the available space in the packet?
> 
> For that case (overflow bevond the packet boundary), there is no data after the last specified TLV length. This sentence is not needed and will be deleted.
> 
>> -[Page 12, 13], "UNIX timeval" or  timespec?
>> (please verify if usec or nsec)
> 
> We'll say;
> 
> "The following formula converts from a timespec (fractional part in
> nanoseconds) to a ..."
> 
>> -[Page 17], "An unique"--->"A unique"
> 
> Done. Thanks.
> 
> Best Regards,
> 
> Hitoshi
> 
> 
>> Best Regards,
>> Meral
>> ---
>> Meral Shirazipour
>> Ericsson
>> Research
>> www.ericsson.com