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

On 2004-09-22, Brian Haberman wrote:
> All,
>      This starts a 1 week IPv6 Working Group Last Call on advancing:
>          Author(s)  : N. Moore
>          Filename : draft-ietf-ipv6-optimistic-dad-02.txt


G'day IPv6ers ...

	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!

	Draft submission will be closed by the time I get back,
and I won't be able to come to IETF Washington, so we'd better
sort it out on the mailing list!


	So far, it's mostly editorial issues, which I suppose
can be fixed post-LC, including some grammar nits and a couple
of places where I've tried to clarify myself and failed :-|
I'm happy just to make the text changes as per my replies,
if they're acceptable ...
	
	There have been a couple of bigger issues raised which
I think need to be discussed on the list.  I think they're 
fixable with minor changes too:


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!


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?


	I won't be on email much.  But if the rest of the WG can talk
these issues through a bit, and if necessary orchestrate a consensus
call or something, I'll try and get an ssh session out of an internet
cafe in Edinburgh in a week or so, and make whatever changes are
necessary.

	At this point, I just want to get it into the IESG queue
so I can move on to topics closer to my current research.

cheers,

------Nick

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