Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-09.txt

From: tom petch <[email-masked]>
Date: Mon, 1 Nov 2021 12:48:07 +0000

From: OPSAWG <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 20 October 2021 09:49
Hi all,

After discussing with Adrian, we are publishing this version that addresses a recent comment from Julian. For more context, please refer to
https://github.com/IETF-OPSAWG-WG/lxnm/issues/350.

<tp>
Some stray thoughts

some lines are 90 characters long

802.1ah is referenced but not in I-D References
802.3ah ditto
802.1ag Amendment 5 looks like a separate document warranting a separate reference
802.1p is referenced implicitly
802.1Q likewise

What is the difference between
identity bgp-l2encaps-type
  Base BGP L2 encapsulation type
     and
identity iana-pw-types
 Base BGP L2 encapsulation type

ccm-priority-type
what is high what low?

Local Maintenance End Point (MEP)
This is not the expansion used by the ITU-T

leaf split-horizon-filtering
what does true mean?

leaf ccm-interval
no units

leaf ccm-holdtime 
no units

leaf duplicate-ip-detection-interval
no units

leaf duplicate-ip-detection-interval
no units

Tom Petch

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce <[email-masked]> De la part de internet-
> [email-masked]
> Envoyé : mercredi 20 octobre 2021 10:34
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-opsawg-l2nm-09.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
>         Title           : A Layer 2 VPN Network YANG Model
>         Authors         : Samier Barguil
>                           Oscar Gonzalez de Dios
>                           Mohamed Boucadair
>                           Luis Angel Munoz
>       Filename        : draft-ietf-opsawg-l2nm-09.txt
>       Pages           : 155
>       Date            : 2021-10-20
>
> Abstract:
>    This document defines an L2VPN Network YANG Model (L2NM) that can be
>    used to manage the provisioning of Layer 2 Virtual Private Network
>    (VPN) 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
>    providers.  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, the document defines the initial versions of two IANA-
>    maintained modules that defines a set of identities of BGP Layer 2
>    encapsulation types and pseudowire types.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-09
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Nov 2021 12:56:34 -0000

Useful comments, thanks Tom.

Authors, please run idnits and fix issues. Also address Tom's comments.

I'll be doing my shepherd review this week. Hopefully you can post a new
revision when the gates open next Monday.

Cheers,
Adrian

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: 01 November 2021 12:48
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-opsawg-l2nm-09.txt

From: OPSAWG <[email-masked]> on behalf of
[email-masked] <[email-masked]>
Sent: 20 October 2021 09:49
Hi all,

After discussing with Adrian, we are publishing this version that addresses
a recent comment from Julian. For more context, please refer to
https://github.com/IETF-OPSAWG-WG/lxnm/issues/350.

<tp>
Some stray thoughts

802.1ah is referenced but not in I-D References
802.3ah ditto
802.1ag Amendment 5 looks like a separate document warranting a separate
reference
802.1p is referenced implicitly
802.1Q likewise

ccm-priority-type
what is high what low?

leaf ccm-interval
no units

leaf ccm-holdtime 
no units

Tom Petch

Cheers,
Med

> ftp://ftp.ietf.org/internet-drafts/

____________________________________________________________________________
_____________________________________________

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.

=

---

From: <[email-masked]>
Date: Tue, 2 Nov 2021 09:30:04 +0000

Hi Tom, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> De : tom petch <[email-masked]>
> Envoyé : lundi 1 novembre 2021 13:48
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]
> Cc : [email-masked]
> Objet : Re: I-D Action: draft-ietf-opsawg-l2nm-09.txt
> 
> After discussing with Adrian, we are publishing this version that
> addresses a recent comment from Julian. For more context, please refer to

[Med] Will check and fix as appropriate.

> 802.1ah is referenced but not in I-D References
[Med] Indeed. Fixed. 

 802.3ah 
[Med] Fixed.

ditto 802.1ag

[Med] This one is already referenced as IEEE-802-1ag.

> Amendment 5 looks like a separate document warranting a separate reference
> 802.1p is referenced implicitly 802.1Q likewise

[Med] As you know 802.1p is not a separate standard. Referenced 802.1Q in the text instead. 

>  Base BGP L2 encapsulation type

[Med] This is a typo. This should be "Base Pseudowire L2 encapsulation type"

> what is high what low?

[Med] Added the following to the description:

"A larger value indicates a higher priority."

> This is not the expansion used by the ITU-T

[Med] Updated to "Maintenance Entity Group End Point (MEP)".

> leaf split-horizon-filtering

[Med] Made this change: 

OLD:
          "Controls split-horizon filtering. 

           In order to achieve split-horizon filtering, every
           Broadcast, unknown unicast, or multicast (BUM)
           packet originating from a non-DF PE is encapsulated
           with an MPLS label that identifies the origin ES.";

NEW:
          "Controls split-horizon filtering. It is enabled 
           when set to 'true'.

           In order to achieve split-horizon filtering, every
           Broadcast, unknown unicast, or multicast (BUM)
           packet originating from a non-DF PE is encapsulated
           with an MPLS label that identifies the origin ES."; 

> no units

[Med] Added "milliseconds". Thanks. 

> no units

[Med] Added "milliseconds". 

> leaf duplicate-ip-detection-interval

[Med] updated to indicate "seconds". 

> > De : I-D-Announce <[email-masked]> De la part de
> > internet- [email-masked] Envoyé : mercredi 20 octobre 2021 10:34 À :
> > [email-masked] Cc : [email-masked] Objet : I-D Action:
> > draft-ietf-opsawg-l2nm-09.txt
> >
> >
> > This draft is a work item of the Operations and Management Area
> > Working Group WG of the IETF.
> >

---

From: tom petch <[email-masked]>
Date: Wed, 3 Nov 2021 16:39:00 +0000

From: [email-masked] <[email-masked]>
Sent: 02 November 2021 09:30

Hi Tom,

Med

As you may have surmised, I am working my way through the I-D but do not have a view yet of how long it will take so would not suggest waiting but rather, if you let me know what your deadline is for preparing a new version, as Adrian suggests, then I will send you my comments so far at that time.

In addition to my previous remarks, I note that two import in 8.3 lack YANG reference clauses.

Tom Petch 

Please see inline.

Cheers,
Med

[Med] Indeed. Fixed.

 802.3ah
[Med] Fixed.

ditto 802.1ag

[Med] Made this change:

OLD:

NEW:

> > and pseudowire types.

---

From: <[email-masked]>
Date: Thu, 4 Nov 2021 06:39:37 +0000

Hi Tom, 

Thank you for the notice.

The plan is to submit a new version when the submission reopens next week. As you know, we are waiting for the writeup to send the document to the IESG.

> In addition to my previous remarks, I note that two import in 8.3 lack

I guess you meant 8.4. No reference is included for these two because they are defined in this same I-D. 

Cheers,
Med

> Envoyé : mercredi 3 novembre 2021 17:39
> As you may have surmised, I am working my way through the I-D but do not
> have a view yet of how long it will take so would not suggest waiting but
> rather, if you let me know what your deadline is for preparing a new
> version, as Adrian suggests, then I will send you my comments so far at
> that time.
> 
> > addresses a recent comment from Julian. For more context, please refer
> > to https://github.com/IETF-OPSAWG-WG/lxnm/issues/350.
> >
> > <tp>
> > Some stray thoughts
> >
> > Amendment 5 looks like a separate document warranting a separate
> > reference 802.1p is referenced implicitly 802.1Q likewise
>

---

From: tom petch <[email-masked]>
Date: Thu, 4 Nov 2021 12:29:44 +0000

From: [email-masked] <[email-masked]>
Sent: 04 November 2021 06:39

Hi Tom,

<tp>

Yes, 8.4 but once this is a YANG module, then where it came from, I-D, RFC whatever is absent so import must have a reference.

Tom Petch

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 4 Nov 2021 12:49:23 +0000

Re-,

> Yes, 8.4 but once this is a YANG module, then where it came from, I-D, RFC
> whatever is absent so import must have a reference.

That's fair. Will be added. Thanks.

Cheers,
Med

> Envoyé : jeudi 4 novembre 2021 13:30
> The plan is to submit a new version when the submission reopens next week.
> As you know, we are waiting for the writeup to send the document to the
> IESG.
> 
> Yes, 8.4 but once this is a YANG module, then where it came from, I-D, RFC
> whatever is absent so import must have a reference.
> 
> Tom Petch
> 
> Cheers,
> Med

---

From: <[email-masked]>
Date: Mon, 8 Nov 2021 07:38:33 +0000

Hi Adrian, Tom, all,

The comments raised by Tom are now addressed in -10.

Two comments on idnits: 

(1) obsolete reference: 

  -- Obsolete informational reference (is this intentional?): RFC 5143
     (Obsoleted by RFC 4842)

This is on purpose as we are following what is in: https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-2.

(2) long lines:

idnits is clean when I run it prior to submission: 

==

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.
==

However, the datatracker displays the following after submission:

==
  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 132 instances of too long lines in the document, the longest
     one being 3 characters in excess of 72.
==

Will see how to fix this. 

Cheers,
Med

> De : Adrian Farrel <[email-masked]>
> Envoyé : lundi 1 novembre 2021 13:57
> À : 'tom petch' <[email-masked]>; BOUCADAIR Mohamed INNOV/NET
> <[email-masked]>; [email-masked]
> Objet : RE: I-D Action: draft-ietf-opsawg-l2nm-09.txt
> 
> 802.1ah is referenced but not in I-D References 802.3ah ditto 802.1ag
> 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.
> 
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: tom petch <[email-masked]>
Date: Mon, 8 Nov 2021 12:51:27 +0000

From: [email-masked] <[email-masked]>
Sent: 08 November 2021 07:38
Hi Adrian, Tom, all,

<tp A fresh comment on -09 which also applies to -10.
In Figure 12 I see 
             |           +--rw saii?                      uint32
             |           +--rw remote-targets* [taii]
             |           |  +--rw taii         uint32
             |           |  +--rw peer-addr    inet:ip-address
 while in Figure 13 I see
             |           +--rw saii?                      uint32
             |           +--rw remote-target* [peer-addr taii]
             |           |  +--rw peer-addr    inet:ip-address
             |           |  +--rw taii         uint32

i.e. a change of identifier for the list, a change in keys, a change in leaf order.  The YANG suggests that Figure 13 is wrong.  More fundamentally, YANG tree diagrams are an aid to understanding and reviewing especially with a module as big as this.  If they cannot be trusted, then what can?

Tom Petch  

Two comments on idnits:

(1) obsolete reference:

(2) long lines:

==

     No issues found here.
==

==

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 8 Nov 2021 14:19:01 +0000

Hi Tom, 

I confirm that Figure 12 is correct. 

What is authoritative is the YANG module. We provided the reader with instructions to generate the full tree:

   The full tree diagram of the module can be generated using the
   "pyang" tool [PYANG].  

It is much more easier to include the full tree and update it once when the module is touched but having a tree spanning dozens of pages is not usable. This is why we are using subtrees:

   That tree is not included here because it is
   too long (Section 3.3 of [RFC8340]).  Instead, subtrees are provided
   for the reader's convenience.

However, this approach has some cons as we need to check manually many many figures. We are doing our best to maintain up-to-date subtrees ... but bugs happen. 

Thank you for helping identifying some of those. 

Cheers,
Med

> Envoyé : lundi 8 novembre 2021 13:51
> [email-masked]; [email-masked]
> i.e. a change of identifier for the list, a change in keys, a change in
> leaf order.  The YANG suggests that Figure 13 is wrong.  More
> fundamentally, YANG tree diagrams are an aid to understanding and
> reviewing especially with a module as big as this.  If they cannot be
> trusted, then what can?
> 
> Tom Petch
> 
> 
> Two comments on idnits:
> 
> (1) obsolete reference:
> 
> This is on purpose as we are following what is in:
> https://www.iana.org/assignments/pwe3-parameters/pwe3-
> parameters.xhtml#pwe3-parameters-2.
> 
> (2) long lines:
> 
> > De : Adrian Farrel <[email-masked]> Envoyé : lundi 1 novembre
> > 2021 13:57 À : 'tom petch' <[email-masked]>; BOUCADAIR Mohamed
> > INNOV/NET <[email-masked]>; [email-masked] Objet : RE:
> > I-D Action: draft-ietf-opsawg-l2nm-09.txt
> >
> > I'll be doing my shepherd review this week. Hopefully you can post a
> > new revision when the gates open next Monday.
> >
> > Cheers,
> > Adrian
> >
> > ______________________________________________________________________
> > ____
> > __
> > 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
> > 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.
> __________________________________________________________________________

---

From: tom petch <[email-masked]>
Date: Thu, 18 Nov 2021 10:54:16 +0000

From: [email-masked] <[email-masked]>
Sent: 08 November 2021 14:19

Hi Tom,

<tp>
It looks like Figure 15 is out of line with the YANG in both -09 and -10

Figure 15 has 
    leaf translate
  leaf cvlan-id
  leaf mode
where in the YANG it would appear to be
    leaf translate
  leaf cvlan-id
  leaf direction

tom petch

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 19 Nov 2021 08:48:22 +0000

Hi Tom, 

Thank you for checking. Will fix as appropriate. 

Thank you. 

Cheers,
Med

> Envoyé : jeudi 18 novembre 2021 11:54
> It is much more easier to include the full tree and update it once when
> the module is touched but having a tree spanning dozens of pages is not
> usable. This is why we are using subtrees:
> 
> However, this approach has some cons as we need to check manually many
> many figures. We are doing our best to maintain up-to-date subtrees ...
> but bugs happen.
> 
> > i.e. a change of identifier for the list, a change in keys, a change
> > in leaf order.  The YANG suggests that Figure 13 is wrong.  More
> > ----------------------------------------------------------------------
> > --
> > ----
> >
> >      No issues found here.
> > ==
> >
> > ----------------------------------------------------------------------
> > --
> > ----
> >
> > > addresses a recent comment from Julian. For more context, please
> > > refer to https://github.com/IETF-OPSAWG-WG/lxnm/issues/350.
> > >
> > > <tp>
> > > Some stray thoughts
> > >
> > > 802.1ah is referenced but not in I-D References 802.3ah ditto
> > > 802.1ag Amendment 5 looks like a separate document warranting a
> > > separate reference 802.1p is referenced implicitly 802.1Q likewise
> > >
> > > leaf duplicate-ip-detection-interval no units
> > >
> > > leaf duplicate-ip-detection-interval no units
> > >
> > >
> > > Tom Petch
> > >
> > > Cheers,
> > > Med
> > >

---

From: tom petch <[email-masked]>
Date: Fri, 19 Nov 2021 12:21:56 +0000

From: [email-masked] <[email-masked]>
Sent: 19 November 2021 08:48
Hi Tom,

<tp>

Some additional editorial comments on -11

s.8.2
 Appendix C lists the initial values included in the
   "iana-bgp-l2-encaps" YANG module.
That is not what I see

s.8.4
    list y-1731 {
      description         "List for y-1731.";
but a list of what?

      leaf cos {
        type uint32;
any constraint on this rather large number?

        container global-parameters-profiles {
          list global-parameters-profile {
            uses route-distinguisher;
            uses vpn-route-targets;
            uses global-parameters-profile;
seems an oxymoron; either the list is global-parameters-profile or the
grouping is  but as the list is also RD and RT that seems a
contradiction.  Also while YANG can cope with the same identifier in
different namespaces, humans might not:-(

            leaf ne-id {
              description   "Indicates the node's IP address.";
 seems to contradict
       p.25   'ne-id':  Includes a unique identifier of the network
element where
                 the VPN node is deployed.

                    case l2tp {
..            leaf router-id {
              description
                "A 32-bit number in the dotted-quad format that is
                 used to uniquely identify a node within an
                 autonomous system (AS). ";
the concept of an AS seems alien in a VPN as is to some extent a node
rather the reference seems to be to PE.  RFC4667 has 'establishes the
unique identity of each PE' for router-id.

                          leaf push {
                            type empty;
                            description
                              "Standard tag Push.
                               The number of 802.1Q tags to push on the
                               front of the frame.";
I am puzzled how empty can be a number

                         leaf cvlan-id {
                           description
                             "VLAN identifier.";
                        leaf cvlan-id {
                          description
                            "Push/Translate vlan tags";
seems inconsistent

                      leaf flow-control {
                        type string;
                         description
                          "Indicates whtehr flow control is
??

s.11.1
              IEEE, "802.1ag - 2007 - IEEE Standard for Local and
The IEEE website tells me that this is superseded but I cannot see what
by

Tom Petch

> >>> > De : OPSAWG <[email-masked]> De la part de internet-
> >>> > [email-masked] Envoyé : mardi 16 novembre 2021 17:38 À :
> >>> >
> >>> >
> >>> >     Filename        : draft-ietf-opsawg-l2nm-11.txt
>

Thank you.

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 19 Nov 2021 12:51:53 +0000

Tom,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 19 novembre 2021 13:22
> Objet : Re: I-D Action: draft-ietf-opsawg-l2nm-11.txt
> 

[Med] Can you please be more explicit? Thanks. 

>       description         "List for y-1731.";

[Med] Updated to "List of configured Y-1731 instances".

> any constraint on this rather large number?

[Med] We don't have any. Please note that the value can be passed via L2SM (RFC8466) which has that range. 

>             uses global-parameters-profile; seems an oxymoron; either the
> list is global-parameters-profile or the grouping is  but as the list is
> also RD and RT that seems a contradiction.  Also while YANG can cope with
> the same identifier in different namespaces, humans might not:-(
> 

[Med] Not sure to get the point. Do you prefer if we use a distinct name for the grouping? 

>                  the VPN node is deployed.

[Med] Right. This was fixed as part of Adrian's review. We have now: 

                "An identifier of the network element where
                 the VPN node is deployed. This identifier
                 uniquely identifies the network element within
                 an administrative domain."

>                  autonomous system (AS). "; the concept of an AS seems
> alien in a VPN as is to some extent a node rather the reference seems to
> be to PE.  RFC4667 has 'establishes the unique identity of each PE' for
> router-id.
> 

[Med] As I remember, we were referring to RFC3931..which points to rfc2072#section-8.1. We are using AS in a more general context. Do you have any particular change that would like to see? Thanks. 

>                                front of the frame."; I am puzzled how
> empty can be a number

[Med] Good catch. The tag to push is indicate din the cvlan-id. Deleted the sentence. 

> 
>                          leaf cvlan-id {
>                            description
>                              "VLAN identifier.";
>                         leaf cvlan-id {
>                           description
>                             "Push/Translate vlan tags"; seems inconsistent

[Med] We need this id for push or translate operations. Changed to "Push (or Translate)"

> 
>                       leaf flow-control {
>                         type string;
>                          description
>                           "Indicates whtehr flow control is ??
> 
> 

[Med] 

> s.11.1
>               IEEE, "802.1ag - 2007 - IEEE Standard for Local and The IEEE
> website tells me that this is superseded but I cannot see what by

[Med] Same here. 

Thank you

---

From: tom petch <[email-masked]>
Date: Mon, 22 Nov 2021 10:25:28 +0000

From: [email-masked] <[email-masked]>
Sent: 19 November 2021 12:51

Tom,

Please see inline.

Cheers,
Med

<tp>
The title of Appendix C is 'Initial PW Types'; s.8.2 contradicts that.

<tp>
good

<tp>
sigh

<tp>
Yes on two counts.  One is that the fact that YANG allows the same identifier to appear in multiple places with a different meaning does not make that a good idea.; YANG can cope, humans may not. Second, having X made up of RD and RT and ... X looks odd, wrong even, for all values of X.  Either the container is X or the grouping is X, but not both.  If the container name is right, then the grouping name is wrong.   I note that the description of the grouping is container for per-service parameters. Well it is not a container but perhaps per service is more accurate than global.

good

> be to PE.  RFC4667 has 'establishes the unique identity of each PE' for

[Med] As I remember, we were referring to RFC3931..which points to rfc2072#section-8.1. We are using AS in a more general context. Do you have any particular change that would like to see? 

<tp>
The reference clauses are to RFC4667 which references RFC4664 which reference RFC4026.  I do not see Autonomous System here, perhaps provide network is the nearest although that may not be quite right.

<tp>
Well, the leaf is cvlan-id which is a VLAN Identifier which is what appears in the other description so I think something similar should appear here.

[Med]

[Med] Same here.

Thank you

Tom Petch

> Tom Petch

_____________________________________________________________

---

From: <[email-masked]>
Date: Mon, 22 Nov 2021 12:04:44 +0000

Hi Tom, 

Thanks for the follow-up.

Please see inline. 

Cheers,
Med

> Envoyé : lundi 22 novembre 2021 11:25

[Med] Ah, I see. We don't have this issue anymore in -12.

> >             uses global-parameters-profile; seems an oxymoron; either
> > the list is global-parameters-profile or the grouping is  but as the
> > list is also RD and RT that seems a contradiction.  Also while YANG
> > can cope with the same identifier in different namespaces, humans
> > might not:-(
> 
> Yes on two counts.

[Med] This is now fixed in -12. Thanks. 

  One is that the fact that YANG allows the same
> identifier to appear in multiple places with a different meaning does not
> make that a good idea.; YANG can cope, humans may not. Second, having X
> made up of RD and RT and ... X looks odd, wrong even, for all values of X.
> Either the container is X or the grouping is X, but not both.  If the
> container name is right, then the grouping name is wrong.   I note that
> the description of the grouping is container for per-service parameters.
> Well it is not a container but perhaps per service is more accurate than
> global.
> 
> >             leaf ne-id {
> > alien in a VPN as is to some extent a node rather the reference seems
> > to be to PE.  RFC4667 has 'establishes the unique identity of each PE'
> > for router-id.
> 
> [Med] As I remember, we were referring to RFC3931..which points to
> rfc2072#section-8.1. We are using AS in a more general context. Do you
> have any particular change that would like to see?
> 
> <tp>
> The reference clauses are to RFC4667

[Med] Yes, I know. What I meant is that we point to Section 4.2 of RFC4667. That section points to Section 5.4.3 of RFC3931, which in turn points to Section 8.1 of RFC2072 for router-id. This is why we are using rt-types:router-id as a type. 

 which references RFC4664 which
> reference RFC4026.  I do not see Autonomous System here, perhaps provide
> network is the nearest although that may not be quite right.

[Med] Will think about this further. Thanks.

> Well, the leaf is cvlan-id which is a VLAN Identifier which is what
> appears in the other description so I think something similar should
> appear here.

[Med] I think the changes in -12 fix this.

> >               IEEE, "802.1ag - 2007 - IEEE Standard for Local and The
> > IEEE website tells me that this is superseded but I cannot see what by
> 
> [Med] Same here.
> 
> Thank you
> 
> Tom Petch