Subject: Re: [bess] [Technical Errata Reported] RFC4659 (4087)

From: "George, Wes" <[email-masked]>
Date: Thu, 13 Nov 2014 23:37:55 -0500

I realize that this sort of switched WGs due to the reorg of routing area,
but how long should an erratum sit without being acknowledged, whether it
is accepted or rejected?

Thanks,
Wes George

On 8/18/14, 12:12 PM, "RFC Errata System" <[email-masked]>
wrote:

>The following errata report has been submitted for RFC4659,
>"BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=4659&eid=4087
>
>--------------------------------------
>Type: Technical
>Reported by: Wesley George <[email-masked]>
>
>Section: GLOBAL
>
>Original Text
>-------------
>No "updates" metadata reference to update RFC4364
>
>Corrected Text
>--------------
>This document updates RFC4364 (and associated metadata links)
>
>Notes
>-----
>RFC4659 provides an extension to the standard defined in RFC4364 to add
>IPv6 support to a standard that was originally IPv4-only. This metadata
>link will make it clearer for implementers that both standards are
>necessary for a full implementation.
>
>Instructions:
>-------------
>This erratum is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party (IESG)
>can log in to change the status and edit the report, if necessary.
>
>--------------------------------------
>RFC4659 (draft-ietf-l3vpn-bgp-ipv6-07)
>--------------------------------------
>Title               : BGP-MPLS IP Virtual Private Network (VPN) Extension
>for IPv6 VPN
>Publication Date    : September 2006
>Author(s)           : J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur
>Category            : PROPOSED STANDARD
>Source              : Layer 3 Virtual Private Networks INT
>Area                : Internet
>Stream              : IETF
>Verifying Party     : IESG
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 14 Nov 2014 04:18:06 -0500

On 11/14/14, 12:11 AM, "[email-masked]" <[email-masked]>
wrote:

>The underlying claim of this errata is that the specifications for IPv6
>support in IP VPN should officially UPDATE the specifications for IPv4
>IP VPNs (RFC4364), so as to convey the idea that "both standards are
>  necessary for a full implementation" of RFC4364.
>
>The claim can have its merits, but I'm not sure that any IETF or WG
>consensus has ever validated this idea.

I disagree. RFC6540/BCP177 is a consensus BCP discussing this very idea.
While it is technically guidance to implementers, rather than IETF, its
principal message is that IPv6 is necessary in new implementations, and
thus would lead to the conclusion that for a full implementation of this
technology, IPv6 is a requirement.
But let's be clear here, IETF isn't the protocol police. Metadata links
between two standards to show the relationship between them are not likely
to dictate a decision to implement or not implement the updating standard,
any more than BCP177 will force someone to implement IPv6. I think that
the nuanced inference that you are making as to why "updates" is used or
not used is going to be lost on all but those deeply involved in IETF
standards minutiae. An implementer will be working on behalf of one or
more customers who will specify exactly which standards must be
implemented (or more accurately, what features are necessary) to meet
their requirements. Metadata in this case is to help implementers find the
links between documents when they build upon one another and make the act
of implementing IETF standards mildly more user-friendly. 4659 has 4364 as
a normative reference, I am simply suggesting that there should be a
forward reference to 4659 from 4364 to identify that the protocol was
later extended with new features that they should consider implementing.

Wes George

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Nov 2014 05:03:43 -0000

Wes.
Mia culpa.
I am happy to hear from authors of 4659 and from the WG if they have opinions.

Personally, I hate metadata errata because I have to look up how to process
them.

But that is hardly an excuse.
My main excuse is that errata processing always seems less important than
fighting fires.

On my list.
Adrian

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of George, Wes
> Sent: 14 November 2014 04:38
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; martin.vigoureux@alcatel-
> lucent.com; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [bess] [Technical Errata Reported] RFC4659 (4087)
> 
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary
> information, which is privileged, confidential, or subject to copyright
belonging to
> Time Warner Cable. This E-mail is intended solely for the use of the
individual or
> entity to which it is addressed. If you are not the intended recipient of this
E-mail,
> you are hereby notified that any dissemination, distribution, copying, or
action
> taken in relation to the contents of and attachments to this E-mail is
strictly
> prohibited and may be unlawful. If you have received this E-mail in error,
please
> notify the sender immediately and permanently delete the original and any copy
> of this E-mail and any printout.
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 05:11:53 +0000

Everyone,

Here is my very own interpretation, possibly wrong given that I may not 
have the full history.

The claim can have its merits, but I'm not sure that any IETF or WG 
consensus has ever validated this idea. I suspect not, and if so, this 
can't be handled as a simple metadata fix on RFC4659.

What would seem wise to me is to first see if BESS as a working group, 
support the idea of making v6 support (RFC4659) mandatory for a spec to 
claim conformance with RFC4364.

-Thomas

>> of this E-mail and any printout.

_________________________________________________________________________________________________________________________

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: Eric C Rosen <[email-masked]>
Date: Fri, 14 Nov 2014 12:36:13 -0500

> IETF isn't the protocol police.

Agreed.  But the IPv6 police seem a bit overenthusiastic these days.
("These days" meaning for the last 20 years or so.)

> Metadata in this case is to help implementers find the links between
> documents when they build upon one another and make the act of
> implementing IETF standards mildly more user-friendly. 4659 has 4364
> as a normative reference, I am simply suggesting that there should be
> a forward reference to 4659 from 4364 to identify that the protocol
> was later extended with new features that they should consider
> implementing.

This just isn't the meaning of "Updates".

> I think that the nuanced inference that you are making as to why
> "updates" is used or not used is going to be lost on all but those
> deeply involved in IETF standards minutiae.

Agreed.  Of course, the same could be said of all the meta-data, 
including the classification as "standards track", "experimental", etc. 
  Nevertheless, the terms have been given a certain meaning with regard 
to IETF process, and we can't just decide that we're going to use them 
differently.

The only real impact of accepting this erratum would be to give fuel to 
non-productive arguments like:

- "Hey, your alleged implementation of 4364 isn't compliant to 4364, 
because it doesn't implement 4659."

- "But it was compliant last week!"

- "No, it hasn't been compliant since BCP177 was published".

- "Then BCP177 should have updated 4364"

So I would suggest rejecting this erratum on the grounds that any 
positive effect is more than outweighed by the time wasted having 
non-productive arguments about it.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 14 Nov 2014 18:27:33 -0500

>to IETF process, and we can't just decide that we're going to use them

WG] I am not trying to ad hoc redefine the term. However, searching for
"RFC updates" produces a lot of irrelevant results, so quite honestly I
have no idea what to feed a search engine to find the right RFC or BCP
that normatively defines the term "updates" as far as metadata is
concerned and what that means in IETF process terms for the relationship
between the documents, so I can't really respond to your assertion
intelligently. Citation, please?

>non-productive arguments about it.

WG] Well, the same argument could happen with nearly any standard that is
updated by subsequent standards on or after the day that the updating
draft becomes a standard. This is because "updates" (along with
obsolete/historical/replace) is how we evolve our standards, and
implementers have to evaluate whether they need to update their
implementation to keep up with those changes, usually with feedback from
the people who buy their implementations, since they are the ones who
determine whether a given implementation is "standards compliant" as
shorthand for "meets my needs for features and interoperability". The
reason I filed an erratum is that I believe that the lack of the update
metadata linkage was an oversight, not that I am trying to retroactively
backdoor a change to the standard and consensus. If anyone has the history
and can show that the WG made a conscious decision around this, I'll stand
corrected, and will update draft-ietf-mpls-ipv6-only-gap accordingly to
reflect the conflict between the two documents (4364 is still in full
effect as a standalone standard but explicitly doesn't support IPv6, while
4659 does support IPv6 but doesn't actually change 4364 to harmonize the
standard and reflect that IPv6 support is possible).

Also: When did IETF start optimizing to avoid wasting time on
non-productive arguments? ;-)

Wes George

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 18 Nov 2014 06:10:38 +0000

Hi Wes and all,

Based on my (possibly naive or outdated) understanding of “update", I don’t see RFC4659 as updating RFC4364. 
From my recollection of the work to produce RFC4659 at the time, there was no intention for the WG to influence whether IPv6 was going to be mandatory in implementation of RFC4364. It was considered that one may implement RFC4364 for IPv4, and if one wanted to support IPv6 support then they’d also implement RFC4659.
If some other document wants to take a stab at defining what IPv6 feature is mandatory in what environment, fine by me. But I don’t believe that was the intention of the WG or RFC4659.

So unless someone produces a definition for “updates” that change my understanding, I vote for rejecting the errata.

Cheers

Francois

> On 14 Nov 2014, at 13:27, George, Wes <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Nov 2014 11:34:10 +0100

Well I agree with Francois & Eric.

To me RFC4659 is an "amendment" to RFC4364 not an "update" or "errata"

I vote to reject.

Cheers,
R.

On Tue, Nov 18, 2014 at 7:10 AM, Francois Le Faucheur (flefauch) <
[email-masked]> wrote:

> From my recollection of the work to produce RFC4659 at the time, there was
> no intention for the WG to influence whether IPv6 was going to be mandatory
> in implementation of RFC4364. It was considered that one may implement
> RFC4364 for IPv4, and if one wanted to support IPv6 support then they’d
> also implement RFC4659.
> If some other document wants to take a stab at defining what IPv6 feature
> is mandatory in what environment, fine by me. But I don’t believe that was
> the intention of the WG or RFC4659.
>
> So unless someone produces a definition for “updates” that change my
> understanding, I vote for rejecting the errata.
>
> Cheers
>
> Francois
>
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>