[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


>>>>> On Sat, 25 Sep 2004 08:16:39 +1000, 
>>>>> "Nick 'Sharkey' Moore" <sharkey@xxxxxxxx> 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

> 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.

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