I have some comments and questions on the related drafts.
> draft-ietf-ipngwg-uni-based-mcast-02.txt
It would be quite useful to outline a bit more of
the problem that needs solving in the introduction.
It would also be useful to have a comparision with IPv4
(either in the introduction or later in the document).
Questions I'd like to see answered is whether there are
approaches and protocols used for IPv4 multicast address allocation that is
effectively replaced by the techniques in the draft i.e. whether the
WGs believe that some mechanisms and protocols that do not need to
be carried forward to IPv6.
The first part of section 3 should presumably refer to and use the picture
from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373.
The description of the fields in section 3 should at a minimum describe
the group ID field by having a reference to draft-ietf-malloc-ipv6-guide-03.txt
I wonder if it also makes sense to carry some information from that document
into this one; e.g. the fact that the high-order bit of the group ID must be
zero for these types of addresses.
Will the unicast prefix based addresses ever need to use the link-local prefix?
If not it might make sense to explicitly ban that where it talks about scope
in section 3.
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.
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?
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?
> draft-ietf-malloc-ipv6-guide-03.txt
The name of the reference [NEW ARCH] confused me - I was sure it
was addr-arch-v3. How about "UNICAST PREFIX" or [3] instead?
Section 3 - bullet on SSM. This says that there is a 96 bit multicast
prefix but the other drafts says it must be zero. Why not explicitly say zero
here as well? Otherwise folks can be lead to believe they can create non-zero
middle bits for SSM addresses.
(If this change is done the second bullet would need to be rewritten since
it refers to SSM.)
Section 5 on randomness says:
The group ID portion of the address is set using either a pseudo-
random 32-bit number or a 32-bit number created using the guidelines
in [RFC 1750]. Possible approaches to creating a pseudo-random
number include using an MD5 message-digest [RFC 1321] or portions of
an NTP [RFC 1305] timestamp.
I think the second sentence should be dropped since it could easily be
read as taking the MD5 digest of a constrant string, or
the current year+month (high-order bits of timestamp), are good enough as
random numbers.
Thus the paragraph on high-order but set to '1' imply that the
high-order bit should always be the same as the T flag in the address?
If so it would make sense to explicitly state that.
If not I'd like to understand the relationship between the two better.
IANA considerations section seem to be incorrect on the last range.
The intent as I understand it is not allow private use but that
the range is reserved for use that conforms to this specification (i.e.
random group IDs).
Also, the IANA considerations seem to be missing the request that IANA
establish a new registry for permanent group IDs (range 0x40000000-0x7fffffff)
which is different than the existing registry for IPv6 multicast addresses.
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
