Fair enough. --> -----Original Message----- --> From: Brian Haberman [mailto:[EMAIL PROTECTED] --> Sent: Monday, May 16, 2005 3:08 PM --> To: Gray, Eric --> Cc: [email protected]; Margaret Wasserman; Thomas Narten --> Subject: Re: last minute review of --> draft-ietf-ipv6-addr-arch-v4-03.txt --> --> --> --> 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; [email protected] --> > --> 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 -->
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
