You don't seem to understand my point. Formal compliance is
irrelevant. The IETF isn't in the business of compliance,
conformance, or commenting on commercial products. What is
out there as running code is history and words in RFCs
will not change it.
Brian
On 2007-06-22 16:23, Hemant Singh (shemant) wrote:
Hi Brian,
IETF can only make recommendations to implementers, they cannot force
implementers to implement anything. However, IETF is the authority on
whether an implementation is compliant with an IETF specification. By
making our proposed change to 2462bis, we are saying that old
implementations are no longer compliant with the new 2462bis I-D. If an
old implementation wishes to comply with the new 2462bis, then the
software needs to be upgraded (by eliminating the "grandfathering"
clause). This provides incentive for software upgrades to prevent the
security problem found in our I-D.
Hemant
-----Original Message-----
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 10:09 AM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; [email protected]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changes suggested to 2462bis-08
Hemant,
Your logic escapes me. Old implementations are *old* and will continue
to do whatever their code does.
No words in 2462bis or 2462ter or anywhere can change that. I think your
proposal is a no-op.
Brian
On 2007-06-22 15:05, Hemant Singh (shemant) wrote:
Hi Tatuya,
Thanks for the quick review of section 5 in our new I-D. Your reading
of section 5 is correct - we have proposed both new and old
implementations to always perform DAD for any unicast address. You are
also correct that the gross change we have proposed over 2462bis is
that old implementations MUST also not skip DAD. We stress about old
implementations because if older implementations that are already
deployed continue to be deployed for say, the next 5-10 years, that's
not good. A software upgrade to older implementation is certainly
possible.
We have given a solid reason for our case - it's presented in Section
2, bullet 4 of our I-D. Please see if our reasoning is solid enough to
convince IETF.
Thanks.
Hemant
-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 10:40 PM
To: Hemant Singh (shemant)
Cc: [email protected]; [EMAIL PROTECTED]; Wes Beebee (wbeebee);
Ralph Droms (rdroms)
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changes suggested to 2462bis-08
At Thu, 21 Jun 2007 12:31:58 -0400,
"Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
Please see section 5 of our I-D for a proposed change to 2462bis-08 -
we hear this I-D is in Editor's queue and any changes to it must be
given ASAP.
(with the document editor hat of 2462bis on)
>From a quick look at Section 5 (and that section only), the key point
of
the proposed change is:
skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do
it (but existing ones still performing the optimization will not be
accused of non-conformance)
to
skipping DAD is completely prohibited, and all new/old
implementations MUST always perform DAD for any address.
Is that correct?
If so, I suspect it's too controversial to merge in 2462bis at this
stage. This part was indeed a result of very heated discussions, and
even though (I believe) we all knew that simply prohibiting it without
exception was a cleaner resolution, we failed to reach a clear
consensus on it; hence the current text as a sort of compromise.
If your new draft could now perfectly convince those who opposed to
prohibiting the DAD optimization before 2462bis goes to the AUTH48
state, I, for one, would be happy to include it to the final version
of 2462bis. But I cannot be that optimistic.
In any event, I don't think changing the phrase matters much; we
already clearly state new implementations MUST NOT skip DAD, so the
change only affects existing implementations. I suspect a certain
amount of existing implementations that skip DAD as specified in
RFC2462 will still keep the current behavior whatever the new 2462bis
RFC specifies. But they'll eventually be replaced with new
implementations, which, if conforming to 2462bis, won't perform DAD
skipping.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba
Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
