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 <[email protected]> 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:[email protected]] > Sent: Thursday, November 23, 2017 10:59 PM > To: Meral Shirazipour <[email protected]> > Cc: [email protected]; [email protected]; > [email protected] > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
