On May 16, 2005, at 14:50, Gray, Eric wrote:
--> -----Original Message-----
--> From: [EMAIL PROTECTED]
--> [mailto:[EMAIL PROTECTED] Behalf Of
--> Brian Haberman
--> Sent: Monday, May 16, 2005 2:28 PM
--> To: Thomas Narten
--> Cc: Margaret Wasserman; ipv6@ietf.org
--> Subject: Re: last minute review of
--> draft-ietf-ipv6-addr-arch-v4-03.txt
-->
--> Hi Thomas,
-->
--> On May 12, 2005, at 12:50, Thomas Narten wrote:
-->
--> > I know this is late, but better late than never...
--> >
--> > Overall, the document is good, but I think that the document would
--> > benefit from slight tweaking w.r.t. to multicast. I.e., I assume that
--> > an "addressing architecture" should be complete and at a minimum offer
--> > pointers to the relevant pieces. I don't think it quite does that in
--> > the case of multicast.
--> >
--> >> 2.7 Multicast Addresses
--> >
--> > This section only mentions the T flag, and not the P flag. That doesnt
--> > seem right, since the P flag is clearly in use now and not "0". Was
--> > there a concern about a possible normative reference? I don't think
--> > there needs to be. Suggestion:
--> >
--> > Old:
--> >> +-+-+-+-+
--> >> flgs is a set of 4 flags: |0|0|0|T|
--> >> +-+-+-+-+
--> >
--> > New:
--> >
--> > +-+-+-+-+
--> > flgs is a set of 4 flags: |0|0|P|T|
--> > +-+-+-+-+
--> >
--> > and then add something like:
--> >
--> > The definition and use of the P bit can be found in [RFC 3307].
--> >
--> > and make the reference informative.
-->
--> Bob and I discussed this and he will be putting text together that
--> clarifies the bits with informative references to RFC 3306 (not 3307)
--> and RFC 3956.
-->
--> >
--> > Also, there are no IANA considerations for multicast addresses. But,
--> > if you look at the IANA web page
--> > (http://www.iana.org/assignments/ipv6-multicast-addresses), it says:
--> >
--> >> IPv6 multicast addresses are defined in "IP Version 6 Addressing
--> >> Architecture" [RFC2373]. This defines fixed scope and variable scope
--> >> multicast addresses.
--> >
--> > But, this document doesn't use the terminology "fixed" or "variable"
--> > scope. So things seem out of alignment. Does this document need to
--> > straighten things out?
--> >
--> > Or, maybe it's the case that RFC 3307 is (now) the definitive
--> > document? (IANA doesn't seem to have picked up anything from
--> > there...). But 3307 document doesn't seem to use the "fixed/variable"
--> > terminoligy either.
--> >
--> > So, it's not immediately clear to me what is needed to get the IANA
--> > page cleaned up, but since it _might_ involve tweaking text in this
--> > document, I think it would be good to understand what needs to be
--> > done before approving this document.
--> >
--> > It's also not immediately clear to me that this document and rfc 3307
--> > are completely aligned, e.g., in terms of consistent terminology. And
--> > this document doesn't seem to reference 3307, which seems incomplete.
-->
--> This is a bigger problem than should be handled in an addressing
--> architecture document.
Wouldn't it make sense for this document to at least mention that there is a synchronization error in terminology used by IANA with respect to terminology used in this document?
Personally, I don't think so. The addressing architecture actually points
at RFC 2375 which doesn't say anything about the allocation rules
for IANA. RFC 3307 does put forth the rules. So, the cleanup needs
to ensure that 3307 is the definitive reference for the registry. It seems
to be an in-direct approach to say something about 3307 in the new
addressing architecture.
As for the terminology, the text in the new addressing architecture is the correct text (in my view). The IANA pages will be updated to reflect that once it is published.
Additionally, the ad-hoc committee can do this without being dependent on the approval/publication of a document. We can point IANA to 3307 and say it is the guidelines for all multicast addresses and then work with them to ensure the webpages are correct.
Regards, Brian
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
