Lenny, Got it. I discuss with Kerry about it and give you back.
Hitoshi From: Leonard Giuliano <[email protected]> Subject: Re: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21 Date: Tue, 28 Nov 2017 09:13:53 -0800 > > Hitoshi- if you are planning on addressing the IANA comments soon with > further revisions, I would think it's probably better to wait and cover it > all in a single revised draft. > > -Lenny > > On Tue, 28 Nov 2017, Hitoshi Asaeda wrote: > > | 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=eJjk2UTDYpdj7vvCfAPp4bHKPBAxhOZKnWKci4orDg8&s=0Fd5MYO3Dy-fxmds4vux_mZgH5b4lhQa23yjPZQK288&e=>. > | >> > | >> > | >> 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
