Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt
"Adrian Farrel" <adrian@olddog.co.uk> Sun, 20 August 2017 10:46 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828531321C7; Sun, 20 Aug 2017 03:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 uLISvlbVtXpM; Sun, 20 Aug 2017 03:46:11 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272401321C4; Sun, 20 Aug 2017 03:46:11 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7KAk8fg027931; Sun, 20 Aug 2017 11:46:08 +0100
Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7KAk74v027910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2017 11:46:08 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: l3sm@ietf.org, draft-wu-l3sm-rfc8049bis@ietf.org
References: <008901d31994$6466cfb0$2d346f10$@olddog.co.uk> <00bd01d31999$c4b540e0$4e1fc2a0$@olddog.co.uk>
In-Reply-To: <00bd01d31999$c4b540e0$4e1fc2a0$@olddog.co.uk>
Date: Sun, 20 Aug 2017 11:46:06 +0100
Message-ID: <00be01d319a1$877ecea0$967c6be0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHyy00TydwpJdquGNbctnHmZJKmKQHiH7ijoj6YI3A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23270.006
X-TM-AS-Result: No--29.418-10.0-31-10
X-imss-scan-details: No--29.418-10.0-31-10
X-TMASE-MatchedRID: 9vvqFUF7IWkTfAqiYFP7BuBwaWMnkCdnQhvApXvqnLHSYAzZ6KmqWoLp YTL2NoySfgzfmSZxplKWmTv5yKHu779UMb7EnVvodAg4yd14qAQpWss5kPUFdDqI/Q1zONHSDJt pS9qt+hgSoyW4TWnnTGQ0sEEkRja/T925Dbv5kLzKl4yJoI+fG7d2noO4P7rAIhbNtFcav8IURx p1HxwnBufMP2XotpTdv7/5pfRSD0lSOtL8ZmjYSlu4M/xm4KZe0nXvwjW2mSWtj24Xqh0yXJwla GGOz9d3rTz842tjykWox+CzFfsqJHdWNVeH9NKPr3X9gdfSLWUXRHoL/W4Y6snjz6P1k0RM1fce 4C9pfzLs/ZPBkyr70NOo6RbUpoAppZL+a31yqs1IRA38P/dwbkolfE5GSrD5E+5bAfeaWupVDQZ v5pRYWzIkYUj5XXPlEm+eZImK+if7W7/9wscjdXC8PJ2EFS7ITJDl9FKHbrlL6WruVTM+eTB9cc de3hbUrEYstNfdK7UKFvDkZCKpiuBX8Ypq0C8lwCZxkTHxccmi4UDSgktqMTKlFjeCy5EtZysJ2 BLmj5iqO0lX0ZAFJq3TEPs1VppFiq265D4ITu9RKfej56hSbGEF8bGZ0cKCydovWuL+KVfbNQh8 5GhqIhFbcWj6ErewHmGY/o4z88lNfs8n85Te8v7E6GNqs6ceseWplitmp0j6C0ePs7A07QKmARN 5PTKc
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/mNbBj0JKqqa-JDeyurhO7BVAlgI>
Subject: Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Aug 2017 10:46:15 -0000
And, of course, I also found "proposes". Sorry for the series of emails. Adrian 6.1 OLD This model also proposes some features for options that are more advanced, such as support for extranet VPNs (Section 6.2.4), site diversity (Section 6.6), and QoS (Section 6.12.2). NEW This model also defines some features for options that are more advanced, such as support for extranet VPNs (Section 6.2.4), site diversity (Section 6.6), and QoS (Section 6.12.2). END 6.1 OLD For example, this model proposes different options for IP address assignments; if those options do not fulfill all requirements, new options can be added through augmentation. NEW For example, this model uses different options for IP address assignments; if those options do not fulfil all requirements, new options can be added through augmentation. END 6.3.2.2.1 OLD The current model proposes five ways to perform IP address allocation: NEW This model defines five ways to perform IP address allocation: END 6.6 OLD The current model proposes parameters and constraints that can influence the meshing of the site-network-access. NEW This model defines parameters and constraints that can influence the meshing of the site-network-access. END 6.6.4 OLD The current model proposes multiple constraint-types: NEW This model defines multiple constraint-types: END 6.10 OLD The model proposes three types of common management options: NEW This model defines three types of common management options: END 6.10 OLD In the co-managed case, the model proposes some options to define the management address family (IPv4 or IPv6) and the associated management address. NEW In the co-managed case, this model defines options to define the management address family (IPv4 or IPv6) and the associated management address. END 6.11.6 OLD The model also proposes an option to create an OSPF sham link between two sites sharing the same area and having a backdoor link. NEW This model also defines an option to create an OSPF sham link between two sites sharing the same area and having a backdoor link. END 6.12.2 OLD The model proposes to define QoS parameters in an abstracted way: NEW This model defines QoS parameters in an abstracted way: END 10 OLD The data model proposes some security parameters than can be extended via augmentation as part of the customer service request; those parameters are described in Section 6.9. NEW This data model defines some security parameters than can be extended via augmentation as part of the customer service request; those parameters are described in Section 6.9. END > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 20 August 2017 10:51 > To: l3sm@ietf.org; draft-wu-l3sm-rfc8049bis@ietf.org > Subject: Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt > > Apologies for immediately updating this. I found another set of nits. > > In several places you use "proposed" to describe this work. But since it will be > an RFC we don't need to be so timid. > > 6.2.1 > OLD > Our proposed model supports any-to-any > NEW > This model supports any-to-any > END > > 6.2.2 > OLD > The proposed model provides cloud access configuration > NEW > The model defined in this document provides cloud access configuration > END > > 6.2.3 > OLD > The proposed model supports bidirectional > NEW > This model supports bidirectional > END > > 6.2.3 > OLD > Some containers proposed in the model > NEW > Some containers in the model > END > > 6.6.5 > OLD > Some infeasible access placement scenarios could be created via the > proposed configuration framework. > NEW > Some infeasible access placement scenarios could be created via the > configuration framework. > END > > 6.12.2.2 as already noted > > 6.13.1 > OLD > In the proposed model, LDP or BGP can be used > NEW > In the model, LDP or BGP can be used > END > > Adrian > > > -----Original Message----- > > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: 20 August 2017 10:12 > > To: l3sm@ietf.org; draft-wu-l3sm-rfc8049bis@ietf.org > > Subject: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt > > > > Author, All, > > > > I have done my document shepherd review of this document as part of the > > publication process. My comments are basically nits and I suggest you fix them > > at the same time as addressing the latest comments from David Ball. Then I > will > > do the document write-up and send the draft to the AD for publication. > > > > Thanks, > > Adrian > > > > === > > > > Many thanks for Section 1.4 that made this review much easier. > > > > --- > > > > idnits reports some issues that you should handle: > > > > ** There are 132 instances of too long lines in the document, the longest > > one being 70 characters in excess of 72. > > > > It would be really nice if you fixed these. If you don't then the RFC > > Editor will introduce line wraps and you might not like how they do it. > > > > > > == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses > > in the document. If these are example addresses, they should be changed. > > > > This is a bogus warning, you can ignore it. > > > > > > == Line 486 has weird spacing: '...--rw id str...' > > == Line 488 has weird spacing: '...--rw id str...' > > == Line 490 has weird spacing: '...--rw id str...' > > == Line 492 has weird spacing: '...--rw id str...' > > == Line 566 has weird spacing: '...roup-id str...' > > == (20 more instances...) > > > > These are bogus warnings, you can ignore them. > > > > > > == Missing Reference: 'VPN2' is mentioned on line 1839, but not defined > > == Missing Reference: 'VPN3' is mentioned on line 1848, but not defined > > > > This is the figure in 6.5.2.2. I suggest that you use curved brackets > > as '(VPN2)' > > > > > > == Unused Reference: 'RFC6020' is defined on line 8310, but no explicit > > reference was found in the text > > > > I think you can simply remove this reference. > > > > > > ** Downref: Normative reference to an Informational RFC: RFC 4026 > > > > You can move this reference to be Informative consistent with the > > reference to RFC 4110. > > > > --- > > > > Section 1 > > > > OLD > > If approved, this document obsoletes [RFC8049]. The changes are a > > series of small fixes to the YANG module, and some clarifications to > > the text. > > > > The following changes were made: > > > > o First change > > > > o ... > > > > o Last change > > NEW > > If approved, this document obsoletes [RFC8049]. The changes are a > > series of small fixes to the YANG module, and some clarifications to > > the text. The changes are listed in Section 1.4. > > END > > > > --- > > > > Section 5 > > > > OLD > > The model is > > intended to be used in the way that the network operator's system is > > the server and the customer's system is the client. > > NEW > > The model is > > intended to be used in a mode where the network operator's system is > > the server and the customer's system is the client. > > END > > > > --- > > > > Section 6.3 > > > > OLD > > A particular location or a set of locations must be > > associated with each site. > > NEW > > Each site is associated with one or more location. > > END > > > > --- > > > > Section 6.12.2.2 > > > > OLD > > o direction: used to specify the direction which qos profile is > > applied to. Our proposed model supports "Site-to-WAN" direction, > > "WAN-to-Site"direction and "both" direction. By default, "both" > > direction is used. > > NEW > > o direction: used to specify the direction to which the qos profile > > is applied. This model supports three direction settings: > > "Site-to-WAN", "WAN-to-Site", and "both". By default, the "both" > > direction value is used. > > END > > > > --- > > > > Section 11 > > > > OLD > > This document adds a new YANG module name in the "YANG Module Names" > > registry [RFC7950]: > > > > Name: ietf-l3vpn-svc > > Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc > > Prefix: l3vpn-svc > > Reference: RFC 8049 > > NEW > > IANA has recorded a YANG module name in the "YANG Module Names" > > registry [RFC7950] as follows: > > > > Name: ietf-l3vpn-svc > > Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc > > Prefix: l3vpn-svc > > Reference: RFC 8049 > > > > IANA is requested to update this registry to reference this document > > on publication as an RFC. > > END > > > > _______________________________________________ > > L3sm mailing list > > L3sm@ietf.org > > https://www.ietf.org/mailman/listinfo/l3sm > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm
- [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bi… Adrian Farrel
- Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc80… Adrian Farrel
- Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc80… Adrian Farrel
- Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc80… Qin Wu
- Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc80… Qin Wu