At Fri, 10 Oct 2008 15:38:28 -0400, Thomas Narten <[EMAIL PROTECTED]> wrote:
> > We might end up regarding no reaction from implementors as a > > "consensus", which is fine for me, but I'd at least request an > > explicit wg last call with a note that this document will invalidate > > existing implementations. > > Invalidate is a strong word. I think we all agree that the issue that > has been raised can lead to to a security issue. I would assume that > implementations that suffer from this "feature" will want to fix their > code. I don't think we should be too worried about whether a spec > change to acheive this invalidates existing implementations! (But the > WG will decide that.) [snip] > IMO, "invalidates" is too strong. I think "clarifies" or "updates" is > just fine. Invalidates suggests that we are making a change from > something that was originally done a certain way intentionally. I > don't think the current definition was done intentionally. It clearly > has a bug in it that we should have caught earlier. I don't see what's wrong with 'invalidate', but I don't insist on a specific wording. I'm fine as long as the new document clearly warns that a RFC4861-compliant implementation may need to be modified due to that document. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
