Subject: RE: Genart last call review of draft-ietf-mpls-ldp-mrt-06

From: Chris Bowers <[email-masked]>
Date: Mon, 6 Nov 2017 06:03:44 +0000

Thanks. This feedback is addressed in the following commit (unless they were fixed based on other comments.)  

https://github.com/cbowers/draft-ietf-mpls-ldp-mrt/commit/11eb7ee2c0c7853d576a3b461674b5a00dfcd1cc

See responses to feedback below with [CB].

Chris

-----Original Message-----
From: Peter Yee [mailto:[email-masked]] 
Sent: Friday, September 1, 2017 8:15 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart last call review of draft-ietf-mpls-ldp-mrt-06

Reviewer: Peter Yee
Review result: Ready with Issues

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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-ldp-mrt-06
Reviewer: Peter Yee
Review Date: 2017-09-01
IETF LC End Date: 2017-09-01
IESG Telechat date: 2017-09-14

Summary:  The draft is ready for publication after correcting some minor issues.

Major issues:  None

Minor issues:

Page 3, section 3, IBR definition: the definition give here appears to be a duplicate of the one given for IN.  Copy the correct definition from RFC 7812 instead.
[CB] corrected in previous commit

Nits/editorial comments:

Page 3, section 1, 2nd paragraph, 1st sentence: append a comma after "e.g.".

[CB] corrected

Page 8, section 4.4., 1st paragraph, 2nd sentence: delete duplicate "on".

[CB] corrected.

Page 8, section 4.4, 2nd paragraph, 4th sentence: change comma after "computations" to a period.
[CB] corrected.

Page 9, section 5.1.1, 4th paragraph, 2nd sentence: the construction "red(blue)" is used without defining what it means exactly.  From the context, it isn't quite "red or blue".  An explanation of the meaning of this construction should be given.  I'm assuming it means something like use "red"
in the sentence in all cases or use use "blue", but don't mix them.  There's also red/blue used later in the document which muddies the point.
======
[CB] I added the text below at the end of the terminology section, and I converted the usage of red/blue to red(blue).

<t> There are several places in this document where the construction 
"red(blue) FEC" is used to cover the case of the red FEC and the case of the 
blue FEC, independently. As an example, consider the sentence "When the 
ABR requires best-area behavior for a red(blue) FEC, it MUST withdraw 
any existing label mappings advertisements for the corresponding rainbow 
FEC and advertise label mappings for the red(blue) FEC." This sentence 
should be read as applying to red FECs. Then it should be read as 
applying to blue FECs. </t>
 ======
Page 10, 1st full paragraph, 2nd sentence: change "foll" to "follows:".
[CB] corrected in previous commit

Page 11, section 5.2.2, 2nd paragraph, 1st sentence: delete the period after "A.1.7".
[CB] corrected

Page 12, 1st paragraph, 1st sentence: consider deleting "how".
[CB] corrected

Page 13, 2nd paragraph after numbered list, 1st sentence: append "to" after "respect".
[CB] corrected

Section titles for 5.2, 5.3, and 7: append a space after "RFC" to separate it from the number.  The spaceless form should only be used for references enclosed in brackets.
[CB] corrected