Re: [Teas] [Gen-art] Genart last call review of draft-ietf-teas-actn-framework-13

[Alissa Cooper <[e-mail]>]

Peter, thanks for your reviews of this document. Authors, thanks for your responses. I have entered a No Objection ballot.

Alissa

> On May 10, 2018, at 11:40 AM, Peter Yee <[e-mail]> wrote:
> 
> Works well enough for me.  Thank you again for considering my input.
>  
>                                 -Peter
>  
> On 5/10/18, 8:14 AM, "Leeyoung" <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Peter,
>  
> Thanks for your further comments. It looks like the only remaining issue is the following.
>  
> PEY> Yes, I meant the ----- and ==== lines.  They were explicitly defined in Figure 9.  In Figure 10, one has to interpret the text above the figure and intuit the meaning of the line thicknesses (==== could be understood from the top part of the diagram, while ---- requires one to make (reasonable) assumptions based on the text).  If you labeled Figure 10 like you did Figure 9, I think it would make comprehension easier.
>  
> Our resolution is to add as you suggested labels to explain what ---- and ==== mean as below in Figure 10:
>  
> Where
>      
>       --- is a link
>       === is a virtual link
>  
> With that change, please review the diff file attached and let us know if all your comments are incorporated in v14 (to be published after your approval). 
>  
> Thanks & Best regards,
> Young and Daniele
>  
> From: Peter Yee [mailto:[e-mail]] 
> Sent: Thursday, May 10, 2018 4:40 AM
> To: Leeyoung <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; Daniele Ceccarelli <[e-mail]>
> Subject: Re: Genart last call review of draft-ietf-teas-actn-framework-13
>  
> Young and Daniele,
>  
> Thanks for addressing my comments.  My apologies for not responding earlier – I’m on the road at the moment.  I’ve made specific responses below prefaced by PEY>.
>  
>                                 Kind regards,
>                                 -Peter
>  
> On 5/4/18, 8:07 AM, "Leeyoung" <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Peter, <>
>  
> Thanks a lot for your thorough review and providing us with a list of good comments. 
>  
> We accepted all your comments and created a diff file for your convenience. 
>  
> Please see DC&YL>> for our response to your comments. 
>  
> Let us know if you have any further comments. Thanks.
>  
> Best regards,
> Young and Daniele
>  
> > -----Original Message-----
> > From: Peter Yee [mailto:[e-mail] <mailto:[e-mail]>]
> > Sent: mercoledì 2 maggio 2018 07:21
> > To: [e-mail] <mailto:[e-mail]>
> > Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; 
> > [e-mail] <mailto:[e-mail]>
> > Subject: Genart last call review of draft-ietf-teas-actn-framework-13
> > 
> > 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> > 
> > Document: draft-ietf-teas-actn-framework-13
> > Reviewer: Peter Yee
> > Review Date: 2018-05-01
> > IETF LC End Date: 2018-04-30
> > IESG Telechat date: 2018-05-24
> > 
> > Summary: This draft is a framework for taking an abstract look at how 
> > traffic engineered networks can be provisioned and controlled.  There 
> > are some issues with looseness in terms that make it more difficult to 
> > understand than it needs to be. [Ready with issues]
> > 
> > Major issues: None
> > 
> > Minor issues:
> > 
> > Page 12, Figure 2: Figure 1 and the preceding text say that it’s
> > Customer->Service Provider->Network Provider, but then here you have a 
> > Customer->business
> > boundary between a customer and a network provider.  I get that the 
> > model can be recursive, but I find it confusing that you’re discussing 
> > an architecture that throws out the part of the terminology of the 
> > model that was just presented two pages previously.  This is 
> > symptomatic of a problem I have with the looseness of the language in 
> > the document in which terms like (point, node) and (service provider, 
> > network provider, operator) are used interchangeably, even in 
> > contravention of how they are defined in the document.  This makes sections 2 and 3 somewhat confusing.
> > 
>  
> DC&YL>>  Good point. ACTN is actually solving network operator’s problem – as to how to control TE networks based on abstraction. 
> Since we introduced “operator” and “operations” in Introduction we’d like to change “network provider” to “network operator”. Whenever “operator” is mentioned, we meant “network operator” that own network infrastructure. 
>  
> > Page 12, Section 3.1, 1st sentence: Wait, 2.2.2 says that VNS are 
> > delivered by the service providers, not network providers.  Yes, SPs 
> > can also be customers of infrastructure-only network providers (2.2.2, 
> > para 2), but this muddles the picture.  If CNCs are Service Provider 
> > devices (functions), then I withdraw the comment, but the naming (CNC) 
> > doesn't make it obvious that these are part of an SP.  The model given in Figure 1 and Section 2 strikes again.
>  
> DC&YL>>  CNC can be a direct customer’s control function or Service provider’s portal functions. To make it clear, we would reword the last sentence in Section 3.1:
>  
> OLD
> For example, the CNC may in fact be a controller or part of a controller in the customer's domain, or the CNC functionality could also be implemented as part of a provisioning portal.
> NEW
> For example, the CNC may in fact be a controller or part of a controller in the customer's domain, or the CNC functionality could also be implemented as part of a service provider’s portal.
>  
> That said, we will change in Figure 2 from "network provider" to "network operator." MDSC is owned by the network operator.  We would also delete “business” from Figure 2. 
> We will add a sentence in Section 2.2.2 where service provider is explained for clarification:  "In some cases, service provider is also a network operator when it owns network infrastructure on which service is provided." 
>  
> PEY> Works for me.
>  
> > 
> > Nits/editorial comments:
>  
> DC&YL>> We accept all your comments; please see some actions we have taken for some comments. 
> > 
> > General:
> > 
> > Expand acronyms on initial use, particularly if the are not marked as 
> > common in the RFC Editor's list:
> > https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt>.
>  
> DC& YL>> Thanks for pointing this out: We expanded the following acronyms on initial use:
>  
> MPLS, OTN, WDM, YANG, WSON, SLA. Is there anything we might have missed?
>  
> PEY> I think that covers the ones I had initially marked during my review.  At some point, I just stopped marking them and added the general nit to the review.
>  
> > 
> > Use a comma after each "e.g." (only a couple were missing).
> > 
> > Change "multi domain" to "multidomain" (or "multi-domain").  Make a 
> > similar change for "inter domain".
>  
> DC& YL>> We would change to multi-domain/ inter-domain
> > 
> > Separate "Gbps" from the preceding number throughout the document.
> > 
> > Specific:
> > 
> > Page 4, 1st full paragraph, last sentence: make "function" plural.
> > 
> > Page 5, 2nd bullet item: append a comma after "application".
> > 
> > Page 5, Section 2.1, 1st sentence: append a blank line after this 
> > sentence to separate it from the following bullet item.
> > 
> > Page 6, 1st partial paragraph, 1st partial sentence: make the last use 
> > of "network" plural.
> > 
> > Page 6, 1st partial paragraphk, 1st full sentence: change "Network" to 
> > "network".
> > 
> > Page 6, 3rd bullet item: isn't this redundant since the 2nd bullet 
> > item essential defines it as well, especially with the reference to 
> > RFC 7926 [section 1.1.9]?
>  
> DC& YL>> Agree. Deleted. 
> > 
> > Page 7, 1st bullet item: delete two excess, blank lines above the bullet items.
> > 
> > Page 11, 1st bullet item: this is basically a description of the MDSC.  
> > You manage to make a forward reference to PNC here.  Why not just drop 
> > MDSC in there as well?
>  
> DC& YL>> OK. We added: “from the Multi-Domain Service Coordinator (MDSC)” before “to the PNC”.  
> > 
> > Page 11, last bullet item: change "South Bound" to "Southbound", as 
> > used later in the document.
> > 
> > Page 18, section 5.2.1, 1st sentence: change "information. I.e." to 
> > "information, i.e.".
> > 
> > Page 20, 1st sentence:  It might be reasonable to change "modes" to "types"
> > to match the usage in the following two bullet items.
> > 
> > Page 20, 1st bullet item: append a comma after "topology" and delete 
> > the second occurrence of "type".
> > 
> > Page 20, 2nd bullet item: append a comma after "topology".
> > 
> > Page 25, Figure 10: explain what the line thicknesses mean.  It's 
> > almost certainly not what was meant in Figure 9.
>  
> DC& YL>> Do you mean ====? If so, we actually have the following text in which to say ===== is meant virtual link. 
> As shown in Figure 10, a customer asks for end-to-end connectivity between CE A and CE B, a virtual network. The customer's CNC makes a request to Provider 1's MDSC.  The MDSC works out which network resources need to be configured and sends instructions to the appropriate PNCs.  However, the link between Q and R is a virtual link supplied by Provider 2: Provider 1 is a customer of Provider 2.
>  
> PEY> Yes, I meant the ----- and ==== lines.  They were explicitly defined in Figure 9.  In Figure 10, one has to interpret the text above the figure and intuit the meaning of the line thicknesses (==== could be understood from the top part of the diagram, while ---- requires one to make (reasonable) assumptions based on the text).  If you labeled Figure 10 like you did Figure 9, I think it would make comprehension easier.
>  
> > 
> > Page 26, 1st sentence after Table 1: what kind of provider is being 
> > discussed here, network or service?  Does it matter?  Does the 
> > separation of such in the model matter?  (See Minor Issues.)
> > 
> DC& YL>> We will change to Operator (this is Network Operator). 
> > Page 27, section 6.1, 1st paragraph, 1st sentence: append a comma 
> > after "APs".
> > 
> > Page 28, Table 4: It's not really clear to me how AP3 ends up with 40 
> > Gbps bandwidth.  It seems like you might be reusing assumptions from 
> > the previous example, but you should really set up the multi-homing 
> > example more clearly.
> > In the previous example, AP2 was in a different domain, so it's not 
> > apparent why it would have 40 Gbps in this example.
> > 
>  
> DC& YL>. This is just an example. We change to 50 Gbps. 
>  
> PEY> Yes, I understood it be an example.  I’m trying to eliminate ambiguity between the examples so that there’s less confusion when reading the document.  Your change addresses my issue just fine.
> > Page 33, section 9, 2nd paragraph: append "of whether" after "regardless".
>  
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art