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

[Qin Wu <[e-mail]>]

Still Reasonable changes, :-),thanks Adrian.

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

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:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 20 August 2017 10:51
> To: [e-mail]; [e-mail]
> 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:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: 20 August 2017 10:12
> > To: [e-mail]; [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/l3sm
> 
> _______________________________________________
> L3sm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l3sm

_______________________________________________
L3sm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm