Hi Tom,
Thank you for the comments.
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : tom petch <daedulus@xxxxxxxxxxxxx>
> Envoyé : vendredi 13 mai 2022 11:23
> À : 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 BGP L2
>
> I find some lack of clarity with regard of the BGP Layer 2
> Encapsulation Types module.
>
> I see no description of the module in the body of the document,
> only the module itself and the IANA Considerations (S.10.2).
[Med] Hmm ... we do already have the following in Section 5:
Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps"
(Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify a
Layer 2 encapsulation type.
and then in Section 7, you can read things such as:
Remote CEs that are entitled to connect to the same VPN should fit
with the CE range ('ce-range') as discussed in Section 2.2.3 of
[RFC6624]. 'pw-encapsulation-type' is used to control the PW
encapsulation type (Section 3 of [RFC6624]). The value of the 'pw-
encapsulation-type' are taken from the IANA-maintained "iana-bgp-
l2-encaps" module (Section 8.1).
Is there anything else you think we should say?
>
> S.10.2 says ' add this note to both modules'. I only see one
> module.
[Med] This was fixed as per the genart review. Thanks for catching this as well.
>
> It gives the name of the registry but not what Group it is part of
> i.e.
> 'Border Gateway Protocol(BGP) Parameters'. Admittedly this is one
> of the better chosen Group names but it is always good practice
> IMO to specify Group name and Registry name when referencing IANA
> entries.
[Med] The note will be placed under the BGP parameters registry. I don't think adding "under BGP parameters...registry" to the note is useful.
>
> It also says that the name of the 'identity' is the lower case of
> the encapsulation name provided in the description. This is not
> what happens here, in the module, in many if not most cases. The
> identity name is based on the Description in the IANA Registry but
> heavily abbreviated. Who will decide on an acceptable
> abbreviation, meaningful, unique, for future additions?
[Med] I think this one was clarified as part of Dale's genart review. Please check the diff shared in that thread.
>
> 'Unassigned or reserved values..' worth spelling out that those
> are the values in the BGP Layer 2 Encapsulation Types registry.
[Med] Yes.
>
> And what about the Experimental Use values? They are not in the
> IANA module but why not?
[Med] If such values appear in the re
>
> 'unique revision date' well yes but the current date would seem
> more useful.
>
[Med] This wording was agreed with Rob as there was a case where IANA accidentally created two entries with the same revision date when adding two types.
> Section 8.1 describes the module as 'YANG data types defined by
> IANA'
> which seems odd. The underlying data types are defined by the IDR
> WG; perhaps 'maintained by'.
[Med] Indeed. Changed to:
"This module contains a collection of IANA-maintained YANG
data types that are used for referring to BGP Layer 2
encapsulation types. ..
>
> I note that Section 8.2 which contains the other IANA module,
> IANA-pseudowire-types, has a section title of 'IANA Encapsulation
> Types'
> which seems odd in the absence of any explanation.
>
[Med] Good catch. Changed to "IANA-Maintained Module for Pseudowire Types"
>
> 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
