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 <pe...@akayla.com> wrote: > > Works well enough for me. Thank you again for considering my input. > > -Peter > > On 5/10/18, 8:14 AM, "Leeyoung" <leeyo...@huawei.com > <mailto:leeyo...@huawei.com>> 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:pe...@akayla.com] > Sent: Thursday, May 10, 2018 4:40 AM > To: Leeyoung <leeyo...@huawei.com>; gen-art@ietf.org > Cc: draft-ietf-teas-actn-framework....@ietf.org; i...@ietf.org; > t...@ietf.org; Daniele Ceccarelli <daniele.ceccare...@ericsson.com> > 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" <leeyo...@huawei.com > <mailto:leeyo...@huawei.com>> 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:pe...@akayla.com <mailto:pe...@akayla.com>] > > Sent: mercoledì 2 maggio 2018 07:21 > > To: gen-art@ietf.org <mailto:gen-art@ietf.org> > > Cc: draft-ietf-teas-actn-framework....@ietf.org > > <mailto:draft-ietf-teas-actn-framework....@ietf.org>; i...@ietf.org > > <mailto:i...@ietf.org>; > > t...@ietf.org <mailto:t...@ietf.org> > > 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 > 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
