Re: [bess] [Technical Errata Reported] RFC4659 (4087) / IPv6 mandatory for an RFC4364 implem ?

["George, Wes" <[e-mail]>]

On 11/14/14, 12:36 PM, "Eric C Rosen" <[e-mail]> wrote:


>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.

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?

>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.

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


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.