--> -----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? --> --> 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 --> -------------------------------------------------------------------- --> IETF IPv6 working group mailing list --> ipv6@ietf.org --> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --> -------------------------------------------------------------------- --> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
