On 2005-10-17, Christian Vogt wrote:
> Hi Nick, hi everybody.
> 
> First of all, I take up the cudgels for this draft.  It defines an
> optimization which is going to be a prerequisite for efficient mobility
> support.  The draft is in excellent shape, too.  Overall, very good work!

Cheers, thanks.  It's currently waiting on the IESG's final word ...

> One thing, though.  Section 3.3 of the draft says:
> 
> >> * (modifies 5.4)  As soon as the initial Neighbor Solicitation is
> >>   sent, the Optimistic Address is configured on the interface and
> >>   available for use immediately.  The address MUST be flagged as
> >>   'Optimistic'.
> 
> Requiring the initial NS to be transmitted *before* the Optimistic
> Address (OA) becomes operable can imply delays that defeat the purpose
> of ODAD.

Ah, yes.  I see what you mean.

Actually, even worse, "as soon as [it] is sent" is somewhat
ambiguous given L2 queuing, etc. 

I'm thinking that:

1) Need to clarify this clause: "* The Optimistic Address is available
for use immediately.  The address MUST be flagged as 'Optimistic'."
would probably be sufficient.

2) Need to add a point to address the MLD clauses mentioned in 2461/2.
I'd welcome your suggestions!

Note that OptiDAD presents changes to 2461/2, not 2461bis/2462bis,
because it's Standards Track and the -bis documents ain't RFCs just
yet.  This may, of course, change.

-----Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to