Erik,
I'll let Brian respond to the editorial comments, but to
quickly answer a few of your questions:
> Will the unicast prefix based addresses ever need to use the
link-local
> prefix?
Need? No, since it could only ever be used for link-local multicast
groups,
and for that scope they don't buy you anything.
> If not it might make sense to explicitly ban that where it talks about
> scope
> in section 3.
Doesn't matter to me. Technically it doesn't hurt anything to allow
them.
Whether it would be operationally clearer to allow or disallow them,
I don't know.
> The last paragraph in section 3 is about lifetimes.
> I don't understand what the intended effect is of the statement
> since I don't know what the lifetime is of a multicast address.
See RFC 2908.
> Is the intent that e.g. if the prefixes are advertised with a 1 day
valid
> lifetime, that an implementation MUST NOT use multicast addresses
derived
> from those prefixes in SDP advertisements that end beyond 1 day ahead?
Yes.
> If the intent is to really be that strict the document definitely
needs
> to be a lot more specific on this point. But I don't see a need to be
> that strict - all these multicast addresses are temporary - is there
> any real danger is for some applications "temporary" spans unicast
> prefix renumbering events?
Yes.
The operational danger is confusion and failure to diagnose problems
in a timely fashion. (Same as would happen today in IPv4 if people
started using others' AS numbers in their multicast groups.)
The performance danger is possible collisions (specifically when
the group ID is IANA assigned or algorithmically generated)
between the old prefix owner and the new prefix owner.
-Dave
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
