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