Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt

On 2004-11-06, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> 
> I'm very sorry for delaying the response...I could not have time to
> respond before you left for vacation, and have kept this thread
> sleeping in my mail box since then.  I hope my silence was not a major
> showstoppper.

G'day Jinmei, no worries, I just hope I can remember what on
earth I was talking about!  I'd better check my list archive:

On 2004-09-25, Nick 'Sharkey' Moore wrote:
>>
>>      So far, it's mostly editorial issues, which I suppose
>> can be fixed post-LC, [...] There have been a couple of bigger
>> issues raised [...]
>>
>> 1: Interoperability with SEND
>>
>>       The draft points out rather uselessly:
>>
>>               Further work will be required to integrate Optimistic
>>               DAD with Secure Neighbor Discovery [SEND].
>>
>>       ... but now SEND is complete.  It would be good to address
>>       any SEND issues in OptiDAD.  I think all that is required is
>>       for someone who understands SEND better than I do to think
>>       it through and give it a big rubber stamp so I can change the
>>       text to:
>>
>>               Optimistic DAD is interoperable with Secure Neighbour
>>               Discovery [SEND] because ...
>>
>>       The question is, fundamentally, "does SEND require sending
>>       any signals during address configuration which would
>>       disadvantage a collidee".  If someone expert in SEND could
>>       answer this question, I'll change the text!

This stands ... please, are there any SEND experts with a half
an hour to check this out for me?  OptiDAD has hardly changed
in several revisions, so there's unlikely to be nasty surprises,
but ...

Actually, let me rephrase that: as I understand it, OptiDAD is
compatible with SEND.  Can anyone here demonstrate otherwise?

>> 2: Unsolicited NAs
>>
>>       OptiDAD does not disallow the unsolicited NAs mentioned in
>>       RFC 2461 7.2.6.  It no longer mentions sending them either.
>>
>>       The only text which does mention them in passing is 4.2,
>>       which explains:
>>
>>               In the course of establishing connections, the ON may
>>               send NAs either spontaneously or in response to received
>>               NSs.  Since these NAs will have O=0, they will not
>>               override existing NC entries, although they may result
>>               in a colliding entry being changed to state STALE.
>>
>>       ... note that that's not MAY, it's just may.  This is in a
>>       section explaining the behaviour (4. Protocol Operation),
>>       not the section listing the rules of OptiDAD (3. Modifications
>>       to RFC-mandated behaviour).  It's meant to be explaining
>>       why sending NA O=0 is mostly harmless.
>>
>>       Perhaps this would be clearer if I changed 'may send' to
>>       'might have sent' (and corresponding tense changes throughout).
>
> 
> Hmm, I simply don't understand why we cannot remove "spontaneously".
> In fact, no existing RFCs or this particular document describes such a
> behavior, right?  So, IMO, leaving it here would just confuse the
> reader about in which case the "spontaneous" NA can happen.

In light of a long, relaxing holiday I've decided I don't care
much about it either, so here's some proposed replacement text:

NEW>          In the course of establishing connections, the ON might
NEW>          have sent NAs in response to received NSs.  Since NAs
NEW>          sent from Optimistic Addresses have O=0, they will not
NEW>          have overridden existing NC entries, although they may have
NEW>          resulted in a colliding entry being changed to state STALE.

I think we'll both be happy with that, yes?

Hope you're all having fun in DC!

-----sharks

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------