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

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 06 Nov 2004 12:21:15 +0900

Hello,

>>>>> On Sat, 25 Sep 2004 08:16:39 +1000, 
>>>>> "Nick 'Sharkey' Moore" <[email-masked]> said:

> 	well, it's bad timing on the Last Call, unfortunately,
> because I'm off on vacation for five weeks starting today!
> Rhonda and I will be backpacking around in Scotland, Ireland
> and Italy, so I won't be reading email much if at all in this
> time.  I'm looking forward to the break!

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.

> 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).
	
> 	Would that be okay, Jinmei?  Does anyone else hold strong
> 	opinions on this?

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.

Is there any reason for keeping this wording?  If not, I'd simply
remove it not to confuse the reader.

Perhaps this is just a minor nitpicking, so I won't insist on this
point, whether to removed or leave it, though.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 9 Nov 2004 14:23:04 +1100

> sleeping in my mail box since then.  I hope my silence was not a major

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?

> 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