Subject: RE: last minute review of draft-ietf-ipv6-addr-arch-v4-03.txt

From: "Gray, Eric" <[email-masked]>
Date: Mon, 16 May 2005 15:11:05 -0400

Fair enough.

--> -----Original Message-----
--> From: Brian Haberman [mailto:[email-masked]]
--> Sent: Monday, May 16, 2005 3:08 PM
--> To: Gray, Eric
--> Cc: [email-masked]; 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-masked]
--> > --> [mailto:[email-masked]]On Behalf Of
--> > --> Brian Haberman
--> > --> Sent: Monday, May 16, 2005 2:28 PM
--> > --> To: Thomas Narten
--> > --> Cc: Margaret Wasserman; [email-masked]
--> > --> 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------