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 protected]> wrote: > > On 11/14/14, 12:36 PM, "Eric C Rosen" <[email protected]> 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. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
