Subject: Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard

From: Benoit Claise <[email-masked]>
Date: Sat, 14 Oct 2017 08:55:11 +0200

Dear all,

Based on the feedback received, the authors produced version 7.
I would like to highlight those two changes (the only two changes btw).
In the abstract:

    This document obsoletesRFC 8049 <https://tools.ietf.org/html/rfc8049>  to replace the unimplementable
    module in that RFC with a new module with the same name that is not
    backward compatible.  The changes are a series of small fixes to the
    YANG module, and some clarifications to the text.

In section 1:

        The YANG module described in [RFC8049 <https://tools.ietf.org/html/rfc8049>] cannot be implemented because
        of issues around the use of XPATH.  This document obsoletes [RFC8049 <https://tools.ietf.org/html/rfc8049>]
        by creating a new module with the same name that is not backward
        compatible (in the sense described in YANG 1.1 [RFC7950 <https://tools.ietf.org/html/rfc7950>]).  The
        changes (listed in full inSection 1.4
    <https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-07#section-1.4>) are small in scope, but
        include fixes to the module to make it possible to implement.

Changes are highlighted here: 
https://tools.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-07.txt
Since RFC8049 is not implementable and therefore not implemented, 
keeping the same YANG module name seems about right.
I'll collect feedback for a week. Note that this draft is on the IESG 
telechat on Oct 26th.

Regards, Benoit
> The IESG has received a request from an individual submitter to consider the
> following document: - 'YANG Data Model for L3VPN Service Delivery'
>    <draft-wu-l3sm-rfc8049bis-04.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
> [email-masked] mailing lists by 2017-10-11. Exceptionally, comments may be
> sent to [email-masked] 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)
>
>
>
> .
>

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 17 Oct 2017 09:49:41 -0700

Hi -

On 10/13/2017 11:55 PM, Benoit Claise wrote:
...
> Since RFC8049 is not implementable and therefore not implemented,

That's rather a leap of faith.  The fact that spec is badly broken
and probably should not have been published in the first place isn't
of itself going to stop someone from using it as the basis for an
implementation of *something*.  RFC 1065 is a great example of something
quite unimplementable as specified (its usage of ASN.1 MACRO
notation is gobbledygook) yet nonetheless saw rather wide deployment.
If there is a need for something, folks are pretty good at DWIM.

It may well be true that there are no implementations of this module,
but the rationale given is most unconvincing, particularly given the
importance of module name/content stability in stitching this stuff 
together.

> keeping the same YANG module name seems about right.

This group seems to be rather attached to module names, and
in ways at odds with the on-the-wire significance of those names.
Seems like some thought needs to be given to configuration management.

Randy

---

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Oct 2017 12:46:28 +0200

Hi Randy,
> implementation of *something*. 
Quoting Jan Lindblad, as YANG doctor:
"The 8049 YANG model had broken XPATH expressions, so a compliant 
implementation was impossible."
> RFC 1065 is a great example of something
See the NETMOD discussion 
https://www.ietf.org/mail-archive/web/netmod/current/msg19108.html
Keeping the same YANG module has the advantage than the link between the 
old and the new YANG modules will be maintained.
And the "import" (as opposed to "import by revision") will take into 
account the new correct module.

Regards, Benoit

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Oct 2017 13:24:29 -0700

Hi -

> implementation was impossible."

The infeasibility of "compliant" implementation does not preclude
good-faith implementations of *something* using that module name.
We've seen that happen with other "broken" RFCs in the SNMP world, and
I see no reason why things will be any different in the YANG world.

If the WG is truly confident that no one had any intention of
implementing RFC 8049 (how else could it have been published without
the error being discovered?) and it has seen no uptake since
publication, then I agree it's a non-issue, though one might
wonder why the work was undertaken in the first place.

Randy

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 Oct 2017 22:18:26 +0100

You make a good point Randy, but I wonder where it takes us.

As you note, it has always been the case that people could make implementations that claim to be conformant to a spec, but which are not. Whether the divergences are deliberate (to make vendor-specific variants, or to fix specification bugs) or accidental (implementation bugs) doesn't change the fact. The same is true of whether the variance is done in good or bad faith.

We cannot (even using Warren's Internet Police badge) stop any of that from happening.

What we can do is keep our specification heritage clean. That means that if an implementation is truly conformant to the specification it claims to conform to, then there must be no "on the wire" confusion with an implementation that is truly conformant to another of our specifications.

That argument would go your way if it was possible to have a functional implementation of 8049. But sadly it isn't. Any implementation claiming conformance with 8049 (whether in good faith or not) is not actually conformant.

Adrian

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: 19 October 2017 21:24
> To: IETF Mailing List
> Subject: Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for
> L3VPN Service Delivery) to Proposed Standard
> 
> Hi -
>

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Oct 2017 15:53:32 -0700

Hi -

> We cannot (even using Warren's Internet Police badge) stop any of that from happening.

Full agreement.

> What we can do is keep our specification heritage clean.

Also agree, but this is what leads me to a slightly different
conclusion, to wit that the YANG rules for revising modules
should be followed if the module name is retained, rather than
simply re-using the module name as though the broken version
had never been published.  TLDR: If keeping the module name the
same is so important, then we should follow the rules for
updating modules.

> That means that if an implementation is truly conformant to the specification it claims to conform to, then there must be no "on the wire" confusion with an implementation that is truly conformant to another of our specifications.
> 
...

The rules for revision of modules are a matter of *schema* configuration
management sanity, and maintaining a potentially usable schema doesn't
depend on whether a specific subset of the schema has been implemented
in the wild, but it *does* depend on the rules for updating modules
being followed.  (The same problem would appear if we re-used a
standards-track MIB module name, ignoring the SMI update rules, even if
the previous version had never been implemented.)  This case sets a
really bad precedent.

Randy