Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-l3sm-l3nm-11: (with COMMENT)

[[e-mail]]

Hi Lars, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert via Datatracker [mailto:[e-mail]]
> Envoyé : lundi 20 septembre 2021 14:39
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Lars Eggert's No Objection on draft-ietf-opsawg-l3sm-l3nm-11:
> (with COMMENT)
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-opsawg-l3sm-l3nm-11: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> It would be useful to summarize this document's relationship to RFC8299
> in the abstract.

[[Med]] Sure. Made this change to the github copy: 

OLD:
   This document defines an L3VPN Network YANG Model (L3NM) that can be
   used for the provisioning of Layer 3 Virtual Private Network (VPN)
   services within a service provider network.  The model provides a
   network-centric view of L3VPN services.

NEW:
   As a complement to the Layer 3 Virtual Private Network Service YANG
   data Model (L3SM), used for communication between customers and
   service providers, this document defines an L3VPN Network YANG Model
   (L3NM) that can be used for the provisioning of Layer 3 Virtual
   Private Network (VPN) services within a service provider network.
   The model provides a network-centric view of L3VPN services.

> 
> ------------------------------------------------------------------------
> -------
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via https://github.com/larseggert/ietf-
> reviewtool), so there will likely be some false positives. There is no
> need to let me know what you did with these suggestions.

[[Med]] Considered most of the proposals below. We kept "key chain" to align with the usage in RFC8177. 

All the changes can be seen at: https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/I-D-L3NM/draft-ietf-opsawg-l3sm-l3nm.txt 


> 
> Section 7.6.3. , paragraph 43, nit:
> > icates which BFD flavor is used to setup the session (e.g., classic
> BFD [RFC
> >                                    ^^^^^
> The verb "set up" is spelled as two words. The noun "setup" is spelled
> as one.
> 
> Section 7.7. , paragraph 1, nit:
> > y applicable if both RP redundancy and and delivery through optimal
> path are
> >                                    ^^^^^^^
> Possible typo: you repeated a word.
> 
> Section 8. , paragraph 8, nit:
> >  VPLS and, VXLAN. Other values may defined, if needed."; leaf type {
> type ide
> >                                    ^^^^^^^
> The modal verb "may" requires the verb's base form.
> 
> Section 8. , paragraph 32, nit:
> > cription "Reference to the TCP-AO key chain."; reference "RFC 8177:
> YANG Key
> >                                   ^^^^^^^^^
> This word is normally spelled as one.
> 
> Section 8. , paragraph 32, nit:
> > description "Reference to the MD5 key chain."; reference "RFC 8177:
> YANG Key
> >                                   ^^^^^^^^^
> This word is normally spelled as one.
> 
> Section 8. , paragraph 32, nit:
> > f; description "Customer-supplied key chain."; } } } } } container
> service {
> >                                   ^^^^^^^^^
> This word is normally spelled as one.
> 
> Section 8. , paragraph 32, nit:
> > cast static source/group associated to to IGMP session"; leaf group-
> addr { ty
> >                                     ^^^^^
> Possible typo: you repeated a word.
> 
> Document references draft-ietf-opsawg-vpn-common-09, but -10 is the
> latest available revision.
> 
> Obsolete reference to RFC4447, obsoleted by RFC8077 (this may be on
> purpose).
> 
> These URLs point to tools.ietf.org, which is being deprecated:
>  * http://tools.ietf.org/wg/opsawg/
> 
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.