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

Alissa Cooper <alissa@cooperw.in> Thu, 24 May 2018 13:17 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD7126CB6; Thu, 24 May 2018 06:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Ttjvgac/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nEhKqa9j
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV0kp05gr7e7; Thu, 24 May 2018 06:17:44 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0075D12DA4A; Thu, 24 May 2018 06:17:43 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4AFBB21D0C; Thu, 24 May 2018 09:17:43 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 24 May 2018 09:17:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=FatvajROwHMip9IFkEEiCRTs0q3bbyikEL3onkZ5B4M=; b=Ttjvgac/ 7+oSVNhdnJ3d1HCkYH3qSYKEDyGuC1FcnbNGZI0Az9bB60eKzcjMgPKWGBe4NoFN NxcAaTEwZDvyE0yWV/sjmY5TqmACYrlRSqs/v3YwLqeNo+g08Mm8Sl83OakXXD09 f9/plH8fyik4qCSG7jMfxNtZxpSBMudMj/VWfWFsk3NqtSaX82PKAMS06wP9psPm sNYFqa2ah728D3cqtZaZ6UEfox2FY0WY4Ka1vigcC8ULwoiU7cNc3TjhNOalWRhg Zet5UkyhZkhNiPxgAXkhLW7I3Gqavk0AwKLHyW6AdaN+wZRu2WE/5ir/T0LyjPN3 eVFKxS3fDVa8HQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=FatvajROwHMip9IFkEEiCRTs0q3bb yikEL3onkZ5B4M=; b=nEhKqa9jyujoGBF6MGbrxVZaR6zmJ4M+tQo9M+F+UJM2J Bw+V91dbqxPWNflgtfphr7amAHzc8MwYAujc3DCBfD7CUJcuz+NdXB3vdDb+Df0V AnZjPyMyGIiLZQ+TomNeFPFzEkGOwipje8JapHYBUKxeShCNF8fPW2cynJh+q566 6cias8zwL8jf+uIqfvqrQsRh3/PKlNj0Usfis62Tlx8Pm/FEOktVvpu5U4skOHeX tGP2XFYLve2KaUxqMjj/kw1d8vMRUbcfQhP/9WWO3cwXDWL4EEuWkQHKIvt+1Lfb 280TAHOSVIWs24IMidF0xUQzAYbBJJHsfkY8ZdEfA==
X-ME-Proxy: <xmx:drsGWymBIO_Q2IonwhoZe04I6KTFpbjQ3ZJ9R92dH1o8eMRXcSV2aw>
X-ME-Proxy: <xmx:drsGWwtQDw9xRhKYQlfxTO4ljbIoPjskDmL7vaY9yIBlVmPh0Pza2A>
X-ME-Proxy: <xmx:drsGW9l3JIp31vVxuG0Zl-9SeD72Bf1QJ_V36ewc2jCoKiJgVIVcKA>
X-ME-Proxy: <xmx:drsGWzsHE63GqYtlXVvhvOrxQ7isc8rKddrg9yVAOMAYsTSkYdJB3w>
X-ME-Proxy: <xmx:drsGW7fWKwHmarkcsJdn7NYqFiW0Q4HAjTNutS_R5Lye5NE1Xns-fg>
X-ME-Proxy: <xmx:d7sGW_xrjm1OGiUNmQJfmkzB4aAX9oEtumv_InGN1A3MFGRp1Vgzyg>
X-ME-Sender: <xms:drsGW3g10RK35KahixqYi3NJGJmRBzajlVgH2wj7T7m1vBmmcWhTdw>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id A9EBDE4F68; Thu, 24 May 2018 09:17:41 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0B536837-C1F4-442C-B92A-FAB9F852C75F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <F5E794C6-1AB3-4DE1-9EC0-DD59359EB435@akayla.com>
Date: Thu, 24 May 2018 09:17:40 -0400
Cc: Leeyoung <leeyoung@huawei.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-teas-actn-framework.all@ietf.org" <draft-ietf-teas-actn-framework.all@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Message-Id: <53AB9DCB-B949-4AF7-AB77-E1A8B4DD1B13@cooperw.in>
References: <152523847796.10768.14445109392931041172@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E173CFE8978@sjceml521-mbx.china.huawei.com> <8F317B6F-9540-47EE-AD20-FF613FA26A71@akayla.com> <7AEB3D6833318045B4AE71C2C87E8E173CFED618@sjceml521-mbx.china.huawei.com> <F5E794C6-1AB3-4DE1-9EC0-DD59359EB435@akayla.com>
To: Peter Yee <peter@akayla.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2SUAvNu7TzVmOPxfXa8-OPuaaVY>
Subject: Re: [Teas] [Gen-art] Genart last call review of draft-ietf-teas-actn-framework-13
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 13:17:49 -0000

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 <peter@akayla.com>; wrote:
> 
> Works well enough for me.  Thank you again for considering my input.
>  
>                                 -Peter
>  
> On 5/10/18, 8:14 AM, "Leeyoung" <leeyoung@huawei.com <mailto:leeyoung@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:peter@akayla.com] 
> Sent: Thursday, May 10, 2018 4:40 AM
> To: Leeyoung <leeyoung@huawei.com>;; gen-art@ietf.org
> Cc: draft-ietf-teas-actn-framework.all@ietf.org; ietf@ietf.org; teas@ietf.org; Daniele Ceccarelli <daniele.ceccarelli@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" <leeyoung@huawei.com <mailto:leeyoung@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:peter@akayla.com <mailto:peter@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.all@ietf.org <mailto:draft-ietf-teas-actn-framework.all@ietf.org>; ietf@ietf.org <mailto:ietf@ietf.org>; 
> > teas@ietf.org <mailto:teas@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