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

[Leonard Giuliano <[e-mail]>]

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 <[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 <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
|