Hello Eric, Thanks for the advise. My reply was to acknowledge that we have seen the review. The "address" was indeed to answer questions or update the draft.
The draft is on the IESG telechat list of May 25. I think we cannot provide a new draft before that date and/or answer all of Christers questions. Best regards, Huub. Sent from my Nexus 6P On 22 May 2017, 10:11, at 10:11, Eric Gray <eric.g...@ericsson.com> wrote: >Huub, > >Many (if not most) of Christer's comments are in the form of questions. >Hence I suggest that - in addressing the comments - you and your >co-authors should first answer the questions and then determine what >changes are actually needed. > >I only suggest this as - for at least some of the questions - it might >not be a good idea to post a new version and ask if Christer's issues >are addressed, at least not as a first step. > >I do not assume you did not know this, but your ACK message below does >not seem to include this step in your plan to address Christer's >comments... > >-- >Eric >(Responding as Document Shepherd) > >-----Original Message----- >From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Huub van >Helvoort >Sent: den 22 maj 2017 00:32 >To: Christer Holmberg <christer.holmb...@ericsson.com>; >gen-art@ietf.org; >draft-ietf-mpls-tp-shared-ring-protection....@tools.ietf.org >Subject: Re: [Gen-art] Gen-ART review of >draft-ietf-mpls-tp-shared-ring-protection-05.txt > >Hej Christer, > >Thank you very much for reviewing this draft. >The minor issues and editorial issues you identified will be addressed >by the authors. > >Best regards, Huub (on behalf of the co-authors). > > >------- >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> >> >> >> Document: draft-ietf-mpls-tp-shared-ring-protection-05.txt >> Reviewer: Christer Holmberg >> Review Date: 17 May 2017 >> IETF LC End Date: 12 May 2017 >> IETF Telechat Date: N/A >> >> Summary: The document is well written, but there are a few issues >I¹d >> like the authors to address. >> >> >> Major Issues: None >> >> Minor Issues: >> ------------- >> >> Section 4.1.3: >> >> The text says: >> >> "When an MPLS-TP transport path, such as an LSP, enters the >> ring,Š² >> >> The ³such as an LSP² statement is confusing. Could there be something > >> else than LSP? >> >> >> >> Section 4.4: >> >> Would it be useful to say that, for a given ring, an interconnect >node >> acts as an egress node for that ring, meaning that all LSPs using the > >> interconnect node will use the same tunnel within the ring? >> >> >> >> Section 4.4.2: >> >> The text says: >> >> "The service LSPs that traverse the interconnected > >> rings use separate >> ring tunnels on each ring, and the LSPs on >> different rings are >> stitched by the interconnection node.² >> >> It¹s unclear to me what ³separate tunnels² mean. As there are two >> different rings, there will obviously be separate tunnels. Or, do you > >> mean to say something else? >> >> >> >> Section 5.1: >> >> The first sentence says: >> >> "The MSRP protection operation MUST be controlled >> with the help of the >> Ring Protection Switch protocol (RPS).² >> >> I think it would be good to have a few introduction sentences of the >> RPS protocol, before mandating the usage of it. >> >> >> The text says: >> >> "The RPS protocol MUST carry the ring status >> information and RPS >> requests, either automatically initiated or >> externally initiated, >> between the ring nodes.² >> >> This text is a little confusing. Is this a protocol requirement, or a > >> protocol usage requirement? Similar to my previous comments, a >generic >> introduction to the protocol, and the requirements it has to fulfil, >> would be useful. In addition, that text should reference to section >> 5.3 for the justification of defining a new protocol in the first >place. >> >> >> >> Editorial Issues: >> ----------------- >> >> Generic: >> >> In the document you use both ³ring node² and ³ring-node² terminology. >> Unless there is a reason for that, please use consistent terminology. >> >> >> >> Section 1: >> >> The text says: >> >> "As described in [RFC5654], MPLS-TP requirements, section >2.5.6.1" >> >> Šand later: >> >> "described in section 2.5.6.1 of [RFC5654]." >> >> Please use consistent wording. >> >> >> >> Section 3: >> >> I like the way the section describes how the requirements have been >met. >> As I assume most of the solutions are described more in detail >> elsewhere in the document, I wonder whether it would be possible to >add references? >> >> Something like: >> >> "For detailed information, see section x.x.x.x." >> >> >> >> Section 4.1: >> >> The text says: >> >> "A port can carry multiple ring tunnels, and a ring tunnel can >> carry multiple LSPs." >> >> I think it would be good to add a picture showing a port carrying >> multiple ring tunnels, carrying multiple LSPs. >> >> >> >> > > >-- >================================================================ >Always remember that you are unique...just like everyone else... > >_______________________________________________ >Gen-art mailing list >Gen-art@ietf.org >https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
