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

From: Meral Shirazipour <[email-masked]>
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.

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

-[Page 12, 13], "UNIX timeval" or  timespec?
(please verify if usec or nsec)

-[Page 17], "An unique"--->"A unique"

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 24 Nov 2017 15:58:50 +0900 (JST)

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

> -please spell out acronyms at first use.

Thank you. Done.

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

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

---

From: Meral Shirazipour <[email-masked]>
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-masked]] 
Sent: Thursday, November 23, 2017 10:59 PM
To: Meral Shirazipour <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21

Dear Meral Shirazipour,

We've almost addressed your comments, and will submit the revision whenever we, co-authors, agree on the changes.

Please see inline.

Thank you. Done.

>    ignore and silently discard the TLV and any remaining portion of 
> the containing packet.  Any data in the packet after the specified TLV
> 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."

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

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

We'll say;

Done. Thanks.

Best Regards,

Hitoshi

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 28 Nov 2017 15:47:43 +0900 (JST)

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-masked]>
Subject: RE: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
Date: Sat, 25 Nov 2017 04:57:12 +0000

---

From: Leonard Giuliano <[email-masked]>
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-masked]>
| 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-masked]] 
| > Sent: Thursday, November 23, 2017 10:59 PM
| > To: Meral Shirazipour <[email-masked]>
| > Cc: [email-masked]; [email-masked]; [email-masked]
| > 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
|

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 29 Nov 2017 09:49:05 +0900 (JST)

Lenny,

Got it.
I discuss with Kerry about it and give you back.

Hitoshi

From: Leonard Giuliano <[email-masked]>
Subject: Re: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
Date: Tue, 28 Nov 2017 09:13:53 -0800