Subject: Re: [Gen-art] Gen-ART review of draft-ietf-pwe3-dynamic-ms-pw-19

From: Jari Arkko <[email-masked]>
Date: Mon, 6 Jan 2014 04:45:33 -0800

Thanks for your review, Christer. I see that a new version has been posted with at least some of these edits in - thank you Matthew for that.

I have placed a no-obj position on this document for the upcoming IESG telechat.

Jari

On Nov 27, 2013, at 3:24 AM, Christer Holmberg <[email-masked]> wrote:

> Hi Matthew,
> 
> Your suggested ways to address my issues look good. I assumed that some of the terms were well known, but raised the issue just in case :)
> 
> The cases where you have a different opinion (e.g. usage of roman numbers) are very minor editorial ones, so no reason spending time arguing about that :)
> 
> Regards,
> 
> Christer
> 
> -----Original Message-----
> From: Bocci, Matthew (Matthew) [mailto:[email-masked]] 
> Sent: 27. marraskuuta 2013 12:33
> To: Christer Holmberg; [email-masked]
> Cc: [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-pwe3-dynamic-ms-pw-19
> 
> Christer
> 
> Thank you for your review and comments. Please see below.
> 
> Matthew
> 
> On 24/11/2013 15:36, "Christer Holmberg" <[email-masked]>
> 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,S
>> SL+ 
>> redir.aspx?C=vCr1L8PWQUqCZeSAn6cKI_Abm6K8vNAI1hJJwcnXe8VAikdG2PcMrstLsz
>> aJe
>> Ao7bR8W3uA2uu0.&URL=http%3a%2f%2fwiki.tools.ietf.org%2farea%2fgen%2ftra
>> c%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 
> MB> 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-masked]
> https://www.ietf.org/mailman/listinfo/gen-art