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
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
