YANG Data Model for L3VPN Service Delivery
draft-wu-l3sm-rfc8049bis-11

[Ballot comment]
I have sympathy for both sides of this discussion, but, after significant thought, I'm balloting Yes - I think that the conversation has moved onto more steering / guiding principles, and is no longer really about this document.

We run a constant battle between doing what is "right", and being slaves to process - while this document does not comply with RFC7950, I believe that:
A: it is the "right thing" to do from a practical point
B: it follows the spirit of 7950 (at least, my interpretation thereof)
C: this is a special case

This document / discussion has moved into the keeping the IETF relevant area, existential discussions, etc. My position is intended (at least partially) reflect this.

Note again that I have sympathy for both sides of this discussion, that this was not taken lightly, and that this is an (IMO) exceptional case.

[Ballot comment]
Thanks for addressing my discuss points on backward compatibility.
I still remain concerned on the wisdom of retaining the same
name for the module, hence my abstain ballot.

[Ballot discuss]
I agree with Alvaro's Discuss, I think it is a bad operational precedent for IETF to obsolete a published Yang RFC with a non-backward compatible update; reusing a module name and creating a new module (with the same name) that is not backward compatible. I don't think it is an acceptable guideline to rationalize that non-backward compatibility is ok as only a small interest group.

[Ballot discuss]
[Given that this document is returning to the IESG, I’m updating my DISCUSS (after IETF 100 and to (hopefully) clarify.]

The basis of this DISCUSS is that this document defines a non-backwards-compatible update to the module in rfc8049, which is not in compliance with the YANG module update process specified in rfc7950 (YANG 1.1).

My interpretation of the discussions in the netmod WG (on the list and during the in-person meeting at IETF 100) is that the WG recognizes that this document presents a case to change the process — but so far it has only agreed on there being a problem, and not on any path forward [A].  There is at least one proposal [B] on the table, but no clear and formal intention from the WG on whether that is in fact the solution, part of it, or anything else.

It would be enough for me to clear this DISCUSS if the netmod WG reached (at least initial) consensus on a path forward.  Other solutions require following rfc7950: either by changing the module name, or by keeping the name and following the specification on how to update a module. [I realize that the latter may not be possible.]

It seems to me that tooling and implementation/deployment considerations around having the same module name are the leading reasons towards looking for alternate solutions and not complying with rfc7950 in this case.  Given the very few dependents on this module (just one!) [C], I think it could be palatable to everyone to change the module name and move on with the updated process separately.



I am also holding this DISCUSS because I don’t think it is a good precedent for the IESG to approve a document that doesn’t follow a standard procedure — regardless of the reasons.  I believe that if the IESG approves this document (without a proper Update to the procedures in rfc7950, or at least a WG-agreed plan to do so) then it will have to consider breaking (or at least bending) the rules for any other module — and even for any other document that doesn’t want to comply with what is standardized already…. Note that I’m not suggesting that the IESG will have to break/bend the rules for everyone, but that it will have to at least consider other requests.


In summary… To be clear, I believe YANG is an important technology for the IETF and the Internet and the last thing I want to do is stand in the way of getting more modules our faster.  However, the process is in place for a reason and breaking it (without a viable alternative) is not the right way forward.  This DISCUSS is clearly for the IESG to consider, as the authors seem to just be caught in the middle.  Instead of making an example of this document, I strongly suggest that the name be changed so the document can be published without compromising the standards process — the update to the rfc7950 process can then be considered separately.



[A] https://mailarchive.ietf.org/arch/msg/netmod/IOMNpqPqhGKxR1MEUB7tQmv3KiA/?qid=185ce790ada5150129831ec488ebad81

[B] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update

[C] https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-l3vpn-svc@2017-10-11.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both

[Ballot discuss]
[Given that this document is returning to the IESG, I’m updating my DISCUSS (after IETF 100 and to (hopefully) clarify.]

The basis of this DISCUSS is that this document defines a non-backwards-compatible update to the module in rfc8049, which is not in compliance with the YANG module update process specified in rfc7950 (YANG 1.1).

My interpretation of the discussions in the netmod WG (on the list and during the in-person meeting at IETF 100) is that the WG recognizes that this document presents a case to change the process — but so far it has only agreed on there being a problem, and not on any path forward [A].  There is at least one proposal [B] on the table, but no clear and formal intention from the WG on whether that is in fact the solution, part of it, or anything else.

It would be enough for me to clear this DISCUSS if the netmod WG reached (at least initial) consensus on a path forward.  Other solutions require following rfc7950: either by changing the module name, or by keeping the name and following the specification on how to update a module. [I realize that the latter may not be possible.]

It seems to me that tooling and implementation/deployment considerations around having the same module name are the leading reasons towards looking for alternate solutions and not complying with rfc7950 in this case.  Given the very few dependents on this module (just one!) [C], I think it could be palatable to everyone to change the module name and move on with the updated process separately.



I am also holding this DISCUSS because I don’t think it is a good precedent for the IESG to approve a document that doesn’t follow a standard procedure — regardless of the reasons.  I believe that if the IESG approves this document (without a proper Update to the procedures in rfc7950, or at least a WG-agreed plan to do so) then it will have to consider breaking (or at least bending) the rules for any other module — and even for any other document that doesn’t want to comply with what is standardized already…. Note that I’m not suggesting that the IESG will have to break/bend the rules for everyone, but that it will have to at least consider other requests.


In summary… To be clear, I believe YANG is an important technology for the IETF and the Internet and the last thing I want to do is stand in the way of getting more modules our faster.  However, the process is in place for a reason and breaking it (without a viable alternative) is not the right way forward.  This DISCUSS is clearly for the IESG to consider, as the authors seem to just be caught in the middle.  Instead of making an example of this document, I strongly suggest that the name be changed so the document can be published without compromising the standards process — the update to the rfc7950 process can then be considered separately.



[A] https://mailarchive.ietf.org/arch/msg/netmod/IOMNpqPqhGKxR1MEUB7tQmv3KiA/?qid=185ce790ada5150129831ec488ebad81
[B] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update
[C] https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-l3vpn-svc@2017-10-11.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both

[Ballot comment]
Section 6.11.1 says it's showing a snippet for a "dual stack" setup; however, it appears to contain only IPv4 information rather than both IPv4 and IPv6 information. Has some portion of this snippet been inadvertently omitted from this version?

------------------------------------------------------------

Some of the new sections of the YANG model are indented in a way that is inconsistent with the rest of the model (e.g., they use deeper indentation than the surrounding model text), making them more difficult to read. I suggest combing through the new changes to make sure they're consistent with regards to indentation and line wrapping.

------------------------------------------------------------

          leaf rate-limit {
            type uint8;
            units percent;
            description
            "To be used if the class must be rate-limited.
            Expressed as percentage of the service bandwidth.";
          }

Using a uint8 here for percentage seems to provide pretty coarse-grained control. Was the use of a floating point value considered?

(I have the same question for 'guaranteed-bw-percent')

[Ballot comment]
-1.2: The document contains lower case versions of 2119 keywords.  If those are correct, please use the updated boilerplate from 8174.

- There are a number of lines that are too long in the YANG tree diagrams. (Check IDNits for details.)

[Ballot discuss]
The Introduction says:

  The YANG module described in [RFC8049] cannot be implemented because
  of issues around the use of XPATH.  This document obsoletes [RFC8049]
  by creating a new module with the same name that is not backward
  compatible (in the sense described in YANG 1.1 [RFC7950]).  The
  changes (listed in full in Section 1.4) are small in scope, but
  include fixes to the module to make it possible to implement.

As the text above says, the model in this document is not compliant with what rfc7950 (The YANG 1.1 Data Modeling Language) specifies in Section 11 (Updating a Module), which starts by saying:

  As experience is gained with a module, it may be desirable to revise
  that module.  However, changes to published modules are not allowed
  if they have any potential to cause interoperability problems between
  a client using an original specification and a server using an
  updated specification.

It seems clear that experience after the original module (rfc8049) was published has lead to the conclusion that an implementation is impossible — as this fact was not discovered before publication.  I believe that the possibility of implementation (or not) of the module in rfc8049 is irrelevant as the specification in rfc7950 talks about updates without any qualification.

The solution seems straight forward to me: follow rfc7950, either by changing the module name, or by keeping the name and following the specification on how to update a module.



I am concerned that the discussions related to the RtgDir review [1] in the netmod [2][3] and ietf@ietf [4] lists have not yet resulted in an updated draft which complies with rfc7950.  Even if any relevant WGs (this document is AD-sponsored) or the ietf@ietf list reached consensus on moving forward with the document as is, it would still not be following what a Standards Track document specifies (rfc7950, in this case).  IOW, documents that don’t conform to what is clearly specified in a Standards Track, community consensus RFC, should not be approved for publication (without the proper Updates to that RFC, of course).

I am then Balloting DISCUSS for the authors to update the document according to the module update specification in rfc7950, or for the discussions on the lists to reach (a different) consensus [*] and then consider the next steps.


[1] https://datatracker.ietf.org/doc/review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16/
[2] https://mailarchive.ietf.org/arch/msg/netmod/-VC7QhHzTyY0P8sL1m4QRg20cv8/?qid=373bf84b373edd7be9e51621c294189a
[3] https://mailarchive.ietf.org/arch/msg/netmod/xDIT_6R0cw_UT97scDYPArTbCYU/?qid=373bf84b373edd7be9e51621c294189a
[4] https://mailarchive.ietf.org/arch/msg/ietf/f4xmJk651EYzIlGi2bgDxAWQkWU/?qid=9c0f779d3f35b9787d796586750fcf36

[*] I know that the conversation on versioning is still ongoing.

[Ballot discuss]
The Introduction says:

  The YANG module described in [RFC8049] cannot be implemented because
  of issues around the use of XPATH.  This document obsoletes [RFC8049]
  by creating a new module with the same name that is not backward
  compatible (in the sense described in YANG 1.1 [RFC7950]).  The
  changes (listed in full in Section 1.4) are small in scope, but
  include fixes to the module to make it possible to implement.

As the text above says, the model in this document is not compliant with what rfc7950 (The YANG 1.1 Data Modeling Language) specifies in Section 11 (Updating a Module), which starts by saying:

  As experience is gained with a module, it may be desirable to revise
  that module.  However, changes to published modules are not allowed
  if they have any potential to cause interoperability problems between
  a client using an original specification and a server using an
  updated specification.

It seems clear that experience after the original module (rfc8049) was published has lead to the conclusion that an implementation is impossible — as this fact was not discovered before publication.  I believe that the possibility of implementation (or not) of the module in rfc8049 is irrelevant as the specification in rfc7950 talks about updates without any qualification.

The solution seems straight forward to me: follow rfc7950, either by changing the module name, or by keeping the name and following the specification on how to update a module.



I am concerned that the discussions related to the RtgDir review [1] in the netmod [2][3] and ietf@ietf [4] lists have not yet resulted in an updated draft which complies with rfc7950.  Even if any relevant WGs (this document is AD-sponsored) or the ietf@ietf list reached consensus on moving forward with the document as is, it would still not be following what a Standards Track document specifies (rfc7950, in this case).  IOW, documents that don’t conform to what is clearly specified in a Standards Track, community consensus RFC, should not be approved for publication (without the proper Updates to that RFC, of course).

I am then Balloting DISCUSS for the authors to update the document according to the module update specification in rfc7950, or for the discussions on the lists to reach (a different) consensus [*] and then consider the next steps.


[1] https://datatracker.ietf.org/doc/review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16/

[2] https://mailarchive.ietf.org/arch/msg/netmod/-VC7QhHzTyY0P8sL1m4QRg20cv8/?qid=373bf84b373edd7be9e51621c294189a

[3] https://mailarchive.ietf.org/arch/msg/netmod/xDIT_6R0cw_UT97scDYPArTbCYU/?qid=373bf84b373edd7be9e51621c294189a

[4] https://mailarchive.ietf.org/arch/msg/ietf/f4xmJk651EYzIlGi2bgDxAWQkWU/?qid=9c0f779d3f35b9787d796586750fcf36

[*] I know that the conversation on versioning is still ongoing.

[Ballot discuss]
The Introduction says:

  The YANG module described in [RFC8049] cannot be implemented because
  of issues around the use of XPATH.  This document obsoletes [RFC8049]
  by creating a new module with the same name that is not backward
  compatible (in the sense described in YANG 1.1 [RFC7950]).  The
  changes (listed in full in Section 1.4) are small in scope, but
  include fixes to the module to make it possible to implement.

As the text above says, the model in this document is not compliant with what rfc7950 (The YANG 1.1 Data Modeling Language) specifies in Section 11 (Updating a Module), which starts by saying:

  As experience is gained with a module, it may be desirable to revise
  that module.  However, changes to published modules are not allowed
  if they have any potential to cause interoperability problems between
  a client using an original specification and a server using an
  updated specification.

It seems clear that experience after the original module (rfc8049) was published has lead to the conclusion that an implementation is impossible — as this fact was not discovered before publication.  I believe that the possibility of implementation (or not) of the module in rfc8049 is irrelevant as the specification in rfc7950 talks about updates without any qualification.

The solution seems straight forward to me: follow rfc7950, either by changing the module name, or by keeping the name and following the specification on how to update a module.



I am concerned that the discussions related to the RtgDir review [1] in the netmod [2][3] and ietf@ietf [4] lists have not resulted in an updated draft which complies with rfc7950.  Even if any relevant WGs (this document is AD-sponsored) or the ietf@ietf list reached consensus on moving forward with the document as is, it would still not be following what a Standards Track document specifies (rfc7950, in this case).  IOW, documents that don’t conform to what is clearly specified in a Standards Track, community consensus RFC, should not be approved for publication (without the proper Updates to that RFC, of course).

I am then Balloting DISCUSS for the authors to update the document according to the module update specification in rfc7950, or for the discussions on the lists to reach (a different) consensus [*] and then consider the next steps.


[1] https://datatracker.ietf.org/doc/review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16/

[2] https://mailarchive.ietf.org/arch/msg/netmod/-VC7QhHzTyY0P8sL1m4QRg20cv8/?qid=373bf84b373edd7be9e51621c294189a

[3] https://mailarchive.ietf.org/arch/msg/netmod/xDIT_6R0cw_UT97scDYPArTbCYU/?qid=373bf84b373edd7be9e51621c294189a

[4] https://mailarchive.ietf.org/arch/msg/ietf/f4xmJk651EYzIlGi2bgDxAWQkWU/?qid=9c0f779d3f35b9787d796586750fcf36

[*] I know that the conversation on versioning is still ongoing.

[Ballot discuss]
The Introduction says:

  The YANG module described in [RFC8049] cannot be implemented because
  of issues around the use of XPATH.  This document obsoletes [RFC8049]
  by creating a new module with the same name that is not backward
  compatible (in the sense described in YANG 1.1 [RFC7950]).  The
  changes (listed in full in Section 1.4) are small in scope, but
  include fixes to the module to make it possible to implement.

As the text above says, the model in this document is not compliant with what rfc7950 (The YANG 1.1 Data Modeling Language) specifies in Section 11 (Updating a Module), which starts by saying:

  As experience is gained with a module, it may be desirable to revise
  that module.  However, changes to published modules are not allowed
  if they have any potential to cause interoperability problems between
  a client using an original specification and a server using an
  updated specification.

It seems clear to me that experience after the original module (rfc8049) was published has lead to the conclusion that an implementation is impossible — as this fact was not discovered before publication.  I believe that the possibility of implementation (or not) of the module in rfc8049 is irrelevant as the specification in rfc7950 talks about updates without any qualification.

The solution seems straight forward to me: follow rfc7950, either by changing the module name, or by keeping the name and following the specification on how to update a module.



I am concerned that the discussions related to the RtgDir review [1] in the netmod [2][3] and ietf@ietf [4] lists have not resulted in an updated draft which complies with rfc7950.  Even if any relevant WGs (this document is AD-sponsored) or the ietf@ietf list reached consensus on moving forward with the document as is, it would still not be following what a Standards Track document specifies (rfc7950, in this case).  IOW, documents that don’t conform to what is clearly specified in a Standards Track, community consensus RFC, should not be approved for publication (without the proper Updates to that RFC, of course).

I am then Balloting DISCUSS for the authors to update the document according to the module update specification in rfc7950, or for the discussions on the lists to reach (a different) consensus [*] and then consider the next steps.


[1] https://datatracker.ietf.org/doc/review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16/

[2] https://mailarchive.ietf.org/arch/msg/netmod/-VC7QhHzTyY0P8sL1m4QRg20cv8/?qid=373bf84b373edd7be9e51621c294189a

[3] https://mailarchive.ietf.org/arch/msg/netmod/xDIT_6R0cw_UT97scDYPArTbCYU/?qid=373bf84b373edd7be9e51621c294189a

[4] https://mailarchive.ietf.org/arch/msg/ietf/f4xmJk651EYzIlGi2bgDxAWQkWU/?qid=9c0f779d3f35b9787d796586750fcf36

[*] I know that the conversation on versioning is still ongoing.

[Ballot comment]
I mostly skimmed this document focusing on the changes, so I may have missed something.  In looking at Section 6.1.4, are there privacy considerations needed for the identifiers?  This might not have been a consideration at the original time of publication.

Thanks for addressing the SecDir review:
https://mailarchive.ietf.org/arch/msg/secdir/Ay09keR4Qi8q_3fM5dPKMsBByek

[Ballot discuss]
* The usage of the term mask with reference to the "mask" leaf node in all the places in this document seems to be incorrect. There are two issues with this wrong usage. IPv4 subnet masks are 32 bits in length and cannot be represented with an uint8. IPv6 does not have the same concept of subnet masks as IPv4 at all. So, I think the easiest way to fix this would be to replace the instances of mask with "prefix-length" instead which can be represented with an uint8 and works for both IPv6 and IPv4 (CIDR).

* There is an off-by-one error in the definition of the prefix lengths for IPv6 addresses. Currently this is defined as

    leaf mask {
      type uint8 {
      range "0..127";
      }
      ...

  but prefix lengths of 128 bits are perfectly legal are common especially in DHCPv6 assigned addresses. So the range must be "0..128"

[Ballot discuss]
* The usage of the term mask with reference to the "mask" leaf node in all the places in this document seems to be incorrect. There are two issues with this wrong usage. IPv4 subnet masks are 32 bits in length and cannot be represented with an uint8. IPv6 does not have the same concept of subnet masks as IPv4 at all. So, I think the easiest way to fix this would be to replace the instances of mask with "prefix-length" instead which can be represented with an uint8 and works for both IPv6 and IPv4 (CIDR).

* There is an off-by-one error in the definition of the prefix lengths for IPv6 addresses. Currently this is defined as

    leaf mask {
      type uint8 {
      range "0..127";
      }

  but prefix lengths of 128 bits are perfectly legal are common especially in DHCPv6 assigned addresses. So the range must be "0..128"

[Ballot discuss]
* The usage of the term mask with reference to the "mask" leaf node in all the places in this document seems to be incorrect. There are two issues with this wrong usage. IPv4 subnet masks are 32 bits in length and cannot be represented with an uint8. IPv6 does not have the same concept of subnet masks as IPv4 at all. So, I think the easiest way to fix this would be to replace the instances of mask with "prefix-length" instead which can be represented with an uint8 and works for both IPv6 and IPv4 (CIDR).

* There is an off-by-one error in the definition of the prefix lengths for IPv6 addresses. Currently this is defined as

    leaf mask {
      type uint8 {
      range "0..127";
    }

  but prefix lengths of 128 bits are perfectly legal are common especially in DHCPv6 assigned addresses. So the range must be "0..128"

[Ballot comment]
* When the address-allocation-type is provider-dhcp-relay or provider-dhcp for IPv6 how is the default gateway information communicated as required by the following text in Section 6.3.2.2.1.? 

"  In the dynamic addressing mechanism, the SP is expected to provide at
  least the IP address, mask, and default gateway information."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-wu-l3sm-rfc8049bis-04. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry Page, the existing entry for:

yang:ietf-l3vpn-svc

will have its reference changed to [ RFC-to-be ].

Second, in the YANG Module Names registry on the YANG Parameters page located at:

https://www.iana.org/assignments/yang-parameters/

The existing entry for:

ietf-l3vpn-svc

will have its reference changed to [ RFC-to-be ].

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-11):

From: The IESG
To: IETF-Announce
CC: bclaise@cisco.com, adrian@olddog.co.uk, draft-wu-l3sm-rfc8049bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for L3VPN Service Delivery) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'YANG Data Model for L3VPN Service Delivery'
  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
ietf@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model that can be used for
  communication between customers and network operators and to deliver
  a Layer 3 provider-provisioned VPN service.  This document is limited
  to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
  model is intended to be instantiated at the management system to
  deliver the overall service.  It is not a configuration model to be
  used directly on network elements.  This model provides an abstracted
  view of the Layer 3 IP VPN service configuration components.  It will
  be up to the management system to take this model as input and use
  specific configuration models to configure the different network
  elements to deliver the service.  How the configuration of network
  elements is done is out of scope for this document.

  If approved, this document obsoletes RFC 8049.  The changes are a
  series of small fixes to the YANG module, and some clarifications to
  the text.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ballot/

No IPR declarations have been submitted directly on this I-D.

Working Group Summary
  RFC 8049 was the product of the L3SM working group, but that WG has been closed.
  No other WG covers this topic.
  However, the L3SM list remains open: changes and revisions were publicised and discussed there

The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3022: Traditional IP Network Address Translator (Traditional NAT) (Informational - IETF stream)