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
