Christer Thank you for your review and comments. Please see below.
Matthew On 24/11/2013 15:36, "Christer Holmberg" <[email protected]> wrote: >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 ><https://rvi.se.ericsson.net/owa/,DanaInfo=mail.internal.ericsson.com,SSL+ >redir.aspx?C=vCr1L8PWQUqCZeSAn6cKI_Abm6K8vNAI1hJJwcnXe8VAikdG2PcMrstLszaJe >Ao7bR8W3uA2uu0.&URL=http%3a%2f%2fwiki.tools.ietf.org%2farea%2fgen%2ftrac%2 >fwiki%2fGenArtfaq>> > >Document: draft-ietf-pwe3-dynamic-ms-pw-19 > >Reviewer: Christer Holmberg > >Review Date: 24 November 2013 > >IETF LC End Date: 27 November 2013 > >IETF Telechat Date: N/A > >Summary: The document is well written, but there are some minor >editorial nits that the authors may want to consider addressing before >publication. > >Major Issues: None > >Minor Issues: None > >Editorial nits: > >Abstract: >----------- > >Q_A_1: > >The first sentence says: > > "There is a requirement for service providers to be able to extend the > reach of pseudowires (PW) across multiple Packet Switched Network > domains." > >I would suggest to replace that with the sentence you are using later in >the Introduction: > > "RFC 5254 describes the service provider requirements for extending > the reach of pseudowires across multiple Packet Switched Network > (PSN) domains." > >...assuming, of course, that you are referring to the requirements in >5254 :) > > > MB> Agreed. I¹ll make that change. > >Section 1: >------------ > >Q_1_1: > >In the text, and in Figure 1, you use "CE" and "PE" terminology, but they >are nowhere extended (e.g. on first occurance). In addition, "CE" is not >defined in the > document, and it is unclear whether the definition exists in some other >document. These are well known terms for L2VPNs, but I agree they should be expanded on first use, regardless. The terminology section states that the terminology from RFC5659 is used. In addition, RFC5659 references RFC3916 and RFC > >Q_1_2: > >Should MPLS be extended on first occurance? MB> It¹s a well known term, but I will expand. > >Q_1_3: > >Should there be a reference to MPLS? MB> I don¹t think so. MPLS is well known and isn¹t even referenced from RFC5659 and RFC3916 (the MS-PW and PW architectures). > >Q_1_4: > >There is text saying "Attachment Identifier (AII)" and later in the >document (section 3.2) "Attachment Identifier (AI)". Please make sure >that both "AII" and > "AI" are correctly extended (e.g. on first occurance). MB> Agreed. AII should read ŒAttachment Individual Identifier¹. I¹ll double check these throughout. > > >Section 2: >------------ > >Q_2_1: > >I suggest to say "This document describes..." rather than "In this >document we describe...". MB> Agreed > > >Q_2_2: > >Should "LDP" and/or "TLV" be extended on first occurance? MB> I will expand LDP, but ŒTLV¹ is so well known that it is used in most RFCs without expansion. > >Section 4: >------------ > >Q_4_1: > >Should there be a reference for "Target Attachment Individual Identifier >(TAII)"? MB> this is the =same as for SAII (RFC5003). I¹ll add a cross reference where it is first used. > >Q_4_2: > >I would suggest to not use roman numbers in the bullet list in 4.2.3. It >will become unclear if you need to reference (in a document, or >elsewhere) a specific > bullet in the list. MB> Why is this any worse than any other method e.g. a,b,cŠ or 1,2,3...? Wouldn¹t you just say Section 4.2.3, Bullet (ii) ? > >Section 5.1: >-------------- > >Q_5_1: > >I think it would be useful to have a reference, and perhaps an example, >or what is meant by "PSN mechanisms". MB> I can add an example of this e.g. MPLS Fast Reroute. > >Q_5_2: > >See Q_4_2 regarding usage of roman numbers. > > >Section 6: >------------ > >Q_6_1: > >There is a sentence saying: > > "However, note that the length MUST be set to 14." > >As the sentence contains a MUST, I would suggest to make the sentence >more stronger, and remove "note". Perhaps simply something like: > > "The length value MUST be set to 14." MB> OK > >Section 7: >------------ > >Q_7_1: > >The text indicates that the existing protocols may have security issues, >but that they are not affected by this document. When I read it, it >sounds like you are not very sure whether > there are security issues, but you still know that they are not affected >:) > >I would suggest to re-word the second sentence to something like: > > "The extensions defined in this document do not affect the security >issues associated with those protocols." MB> Agreed, but perhaps ¹security considerations¹ rather than ¹security issues¹ would be more accurate. > > >Section 8: >------------ > >Q_8_1: > >In section 8.1, s/"IANA needs to"/"IANA is requested to" MB> OK > >Q_8_2: > >In section 8.2, s/"The IANA is requested to"/"IANA is requested to" MB> OK > > >Section 10: >-------------- > >Q_10_1: > >I would suggest to move the paragraph to the beginning of section 11. >Something like: > > "11. Acknowledgements > > The editors gratefully acknowledge the following additional co- > authors of this document: Mustapha Aissaoui, Nabil Bitar, Mike >Loomis, David McDysan, > Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff > Sugimoto. > > The editors also gratefully acknowledge the input of the following > people: Mike Duckett, Paul Doolan, Prayson Pate, Ping Pan, Vasile > Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada." MB> The intent was to explicitly and clearly call out people who contributed text but were too numerous to list at the top of the draft. I¹d therefore rather keep these in a separate section. > > >Regards, > >Christer > > > > > > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
