Works well enough for me. Thank you again for considering my input. -Peter On 5/10/18, 8:14 AM, "Leeyoung" <leeyoung@xxxxxxxxxx> 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:peter@xxxxxxxxxx] 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" <leeyoung@xxxxxxxxxx> wrote: 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:peter@xxxxxxxxxx] > Sent: mercoledì 2 maggio 2018 07:21 > To: gen-art@xxxxxxxx > Cc: draft-ietf-teas-actn-framework.all@xxxxxxxx; ietf@xxxxxxxx; > 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>. > > 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. 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". |
