Subject: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Aug 2017 10:12:03 +0100

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Aug 2017 10:50:33 +0100

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:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 20 August 2017 10:12
> To: [email-masked]; [email-masked]
> Subject: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt
> 
> Author, All,
> 
> _______________________________________________
> L3sm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3sm

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Aug 2017 11:46:06 +0100

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

> Sent: 20 August 2017 10:51
> Subject: Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 21 Aug 2017 06:44:32 +0000

Thank Adrian to provide this valuable shepherd review on this document.
Your proposed changes looks reasonable. We will take care of your comment together
with additional ones from David Ball.

I will send a separate email to address David Ball's comments.

-Qin
-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2017年8月20日 17:12
收件人: [email-masked]; [email-masked]
主题: 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

===

---

---

Section 1

OLD

   o  First change

   o  ...

   o  Last change
NEW

---

Section 5

OLD
   The model is

---

Section 6.3

OLD

---

Section 6.12.2.2

OLD

---

Section 11

OLD

           Name: ietf-l3vpn-svc

           Name: ietf-l3vpn-svc

---

From: Qin Wu <[email-masked]>
Date: Mon, 21 Aug 2017 06:45:47 +0000

Still Reasonable changes, :-),thanks Adrian.

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2017年8月20日 18:46
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Shepherd review of draft-wu-l3sm-rfc8049bis-02.txt

Adrian

6.1
OLD

6.1
OLD
   For

6.3.2.2.1
OLD

6.6
OLD

6.6.4
OLD

6.10
OLD

6.10
OLD

6.11.6
OLD

6.12.2
OLD

10
OLD

> In several places you use "proposed" to describe this work. But since 
> it will
be
>    Our proposed model supports any-to-any NEW
>   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
>   Some containers proposed in the model NEW
>   In the proposed model, LDP or BGP can be used NEW
>   In the model, LDP or BGP can be used END
> 
> Adrian
> 
> > 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
> >      in the document.  If these are example addresses, they should 
> > be
changed.