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 protected]> wrote: > 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 >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
