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.
My suggestion is that we work this issue through the IAB's Ad-hoc IPv6
group since they are already focusing on registry clean-up. This can be
another sub-bullet on that work list. I think trying to document to IANA
that they need to overall a registry in this spec will be too confusing.
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 --------------------------------------------------------------------
