Re: [Last-Call] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,

The use of the common module is provided early in the document. Section 1 includes the following:

   This document uses the common Virtual Private Network (VPN) YANG
   module defined in [RFC9181].

The description text is not "divergent" nor conflicting with what is in RFC9181. This text is provided for the reader's convenience. This is better compared to simply adding dry pointers to RFC9181.

It is the responsibility of each document making use of 9181 to find the appropriate description balance and also to ensure that it does not conflict with 9181. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <daedulus@xxxxxxxxxxxxx>
> Envoyé : jeudi 12 mai 2022 18:08
> À : last-call@xxxxxxxx
> Cc : adrian@xxxxxxxxxxxx; opsawg@xxxxxxxx; opsawg-chairs@xxxxxxxx;
> draft-ietf-opsawg-l2nm@xxxxxxxx
> Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG
> Network Data Model for Layer 2 VPNs) to Proposed Standard
> 
> This I-D imports and uses a number of YANG grouping from RFC9181,
> ietf-vpn-common. This fact gets a mention in section 5 but you
> would not know this from the descriptive section, section 7, where
> imports and native YANG are seamlessly merged.
> 
> This I-D contains text on the meaning of the nodes, their usage
> and such like regardless of where they are defined.  Looking at
> RFC9181 it is rather short, or very short, on such text (e.g. in
> vpn-profile-cfg, vpn-description).  It would seem then that each
> document that imports
> RFC9181 will have to incorporate its own, potentially divergent,
> text on the meaning of the nodes and their usage while if ietf-
> vpn-common gets updated, the ripples may spread.
> 
> This seems unfortunate.
> 
> Tom Petch
> 
> On 29/04/2022 15:40, The IESG wrote:
> >
> > The IESG has received a request from the Operations and
> Management
> > Area Working Group WG (opsawg) to consider the following
> document: -
> > 'A YANG Network Data Model for Layer 2 VPNs'
> >    <draft-ietf-opsawg-l2nm-15.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final comments on this action. Please send substantive comments
> to the
> > last-call@xxxxxxxx mailing lists by 2022-05-13. Exceptionally,
> > comments may be sent to iesg@xxxxxxxx instead. In either case,
> please
> > retain the beginning of the Subject line to allow automated
> sorting.
> >
> > Abstract
> >
> >
> >     This document defines an L2VPN Network YANG Model (L2NM)
> which can be
> >     used to manage the provisioning of Layer 2 Virtual Private
> Network
> >     services within a network (e.g., service provider network).
> The L2NM
> >     complements the Layer 2 Service Model (L2SM) by providing a
> network-
> >     centric view of the service that is internal to a service
> provider.
> >     The L2NM is particularly meant to be used by a network
> controller to
> >     derive the configuration information that will be sent to
> relevant
> >     network devices.
> >
> >     Also, this document defines a YANG module to manage Ethernet
> segments
> >     and the initial versions of two IANA-maintained modules that
> defines
> >     a set of identities of BGP Layer 2 encapsulation types and
> pseudowire
> >     types.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list
> > IETF-Announce@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > .
> >

_________________________________________________________________________________________________________________________

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.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux