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