Re: Please Review: documents on IESG Agenda for May 26, 2005 Telechat

["Nick 'Sharkey' Moore" <nick.moore@eng.monash.edu.au>]

Hi Jari,

	some quick responses inline:

> Technical:
> 
> >   * Optimistic DAD SHOULD NOT be used to configure addresses unless the
> >        probability of collision is exceedingly small.
> 
> I find it very hard to implement this. More guidance would be
> needed. Did you mean "... SHOULD NOT when addresses have
> been configured manually"?

I agree.  It is, however, the will of the WG, expressed repeatedly, 
that somewhere in there is the instruction that OptiDAD should not
be used thus.  I am at a loss to work out how to make everyone happy
on this.

> >   * (modifies 5.5) A host MAY choose to configure a new address as an
> >        Optimistic Address.  A host which does not know the SLLAO of its
> >        router SHOULD NOT configure a new address as Optimistic.  A
> >        router SHOULD NOT configure an Optimistic Address.
> 
> There's probably an easy explanation to this, but I don't understand
> why we need to prevent optimistic dad when the link layer address
> of the router is not known. Presumably an RS/RA is in progress
> at the same time (and the RS is sent from the unspecified address).
> Can you explain this to me?

The assumption is that a router which does not include its SLLAO in
a broadcast RA is unlikely to do so in another broadcast RA ... which
is all it can reply to our RA-from-:: with.  Therefore, we SHOULD give
up and fall back to standard behaviour.

> >   This memo introduces a new address state, 'Optimistic', that is used
> >   to mark an address which is available for use but which has not
> >   completed DAD.  Protocols that do not understand this state should
> >   treat it equivalently to 'Deprecated', to indicate that the address
> >   is available for use but should not be used if another suitable
> >   address is available. 
> 
> I'm having some trouble understanding the word "protocols" above.

Yeah, it's a tricky one.  

Perhaps an example: Source address selection uses the address states
to decide which source address to tack onto an outgoing packet.  It
should treat Optimistic equivalently to Deprecated.  There may be
others.  Would it clarify things to say "protocols, such as Source
Address Selection [REF]," or similar?

> >   Optimistic Duplicate Address Detection is an interoperable
> >   modification of the existing IPv6 Neighbor Discovery (RFC2461) and
> 
> I'd be surprised if this was not interoperable, but I think you
> mean s/interoperable/backwards compatible/

Previous DAD optimizations haven't even been interoperable.
I'm happy to change that, though, because it is indeed backwards
compatible.

I know the references [SEND] and [MIPV6] are out of date now, I'll get
that fixed before publication.  Regretfully, last minute changes to
the References and Acknowledgements sections appear to have been lost
in the post.

Last-minute changes to References and Acknowledgements somehow got
lost in the post ... these are non-normative so I'm hoping to change
them once the IESG has decided.

The reference to [KOODLI] is a very very early very very expired version
of FMIP, and the mechanism has changed utterly since.  FMIP is a
moving target.  My plan is to remove this long expired draft from the
references, and mention their journal paper in 'Acknowledgements'
instead.  [SOTO] will be removed similarly, by arrangement with the
authors ... Appendix A replaces it.

Thanks for your feedback,

-----Nick
-- 
Nick Moore, Resarch Fellow        | <nick.moore@eng.monash.edu.au>
Monash University CTIE	          | <http://www.ctie.monash.edu.au/ipv6/>
Australian Telecommunications CRC | <http://www.telecommunications.crc.org.au/>