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
