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

From: "Gray, Eric" <[email-masked]>
Date: Mon, 16 May 2005 14:50:51 -0400

--> -----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?

-->
--> 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
--> [email-masked]
--> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--> --------------------------------------------------------------------
--> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Mon, 16 May 2005 15:07:57 -0400

> --> > there needs to be. Suggestion:

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 16:02:10 -0400

Hi Brian.

> 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

I'm still trying to convince myself that this is the case.

addr-arch has the T  bit to distinguish between:

>              T = 0 indicates a permanently-assigned ("well-known")
>              multicast address, assigned by the Internet Assigned Number
>              Authority (IANA).
> 
>              T = 1 indicates a non-permanently-assigned ("transient")

But, RFC 3307 (which has the IANA considerations for mcast addresses)
doesn't use the latter terminology. It uses:

>       -  The range 0x80000000 to 0xFFFFFFFF is reserved for use by
>          dynamic multicast address allocation mechanisms, see Section
>          4.3.

I.e., "dynamic". This may be a minor point, but in looking through the
various documents, this use of different terms didn't help me figure
out what was going on...

Which terminology is preferred? Is it the text in RFC 3307, or the
text in addr-arch? 

> with them to ensure the webpages are correct.

I think this works as long as what we are asking IANA to do is
consistent with the existing documents, as the ad-hoc shouldn't be
filling in the gaps on its own. Or, if it needs to, then a document
would presumably need to be produced and pushed through the system.

I hope we don't need another (separate) document.

Also, one thing I notice (not sure how to fix or whether to fix) is
that RFC 3307 talks about  "group IDs", which seem to be 4-byte
quantities (per 3307):

> 4.2  Permanent IPv6 Multicast Group Identifiers
> 
>    Permanent group IDs allow for a global identifier of a particular
>    service (e.g. Network Time Protocol (NTP) being assigned the group ID
>    0x40404040).  The use of permanent group IDs differs from permanent
>    multicast addresses in that a permanent group ID offers a global
>    identifier for a service being offered by numerous servers.
> 
>    As an example, consider the NTP example group ID of 0x40404040.  An
>    NTP client would be able to access multiple servers and multiple
>    scopes.  That is, the NTP client will know that the group ID
>    0x40404040 identifies an NTP multicast stream regardless of the upper
>    96 bits of the multicast address.
> 
>    Permanent group IDs are allocated on an Expert Review basis, in the
>    range 0x40000000 to 0x7FFFFFFF.  These permanent group IDs are meant
>    to be used in IPv6 multicast addresses, defined in [UNIMCAST].

But, addr-arch talks about  "group IDs" differently:

>    |   8    |  4 |  4 |                  112 bits                   |
>    +------ -+----+----+---------------------------------------------+
>    |11111111|flgs|scop|                  group ID                   |
>    +--------+----+----+---------------------------------------------+

i.e., they are 112-bits long. And there is  no mention of the RFC
3307-style Group IDs for which IANA has created a registry.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 16:18:05 -0400

> respect to terminology used in this document?

I agree that if there is a synchronization issue between IANA and our
docs, and our docs are correct, there is no need to mention that in
addr-arch. We can straighten things out via email. But before
approving addr-arch, I think we should be reasonably confident there
is nothing else in that document we want to tweak in order get the
pages the way we want them.

Somewhat related, I think it would be helpful to add something like the
following to the IANA considerations for addr arch (which is
effectively empty at the moment w.r.t. to allocation issues):

    IANA considerations for the management of global unicast address
    space can be found in [RFC 3513] and are not updated by this
    document.

    IANA considerations for the management of IPv6 multicast address
    space can be found in [RFC 3307] and are not updated by this
    document.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Mon, 16 May 2005 16:26:39 -0400

Hi Thomas,

> various documents, this use of different terms didn't help me figure

As I mentioned, Bob will be updating the addressing arch to incorporate
text to clarify the R & P bits.  We will ensure that the language is 
consistent.

With the use of "dynamic" or "transient" in the IANA section, the text
from Section 4.3 in 3307 says:

    Dynamic IPv6 multicast addresses can be allocated by an allocation
    server or by an end-host.  Regardless of the allocation mechanism,
    all dynamically allocated IPv6 multicast addresses MUST have the T
    bit set to 1.

This was done to tie together the terminology from the IPv6 architecture
with the multicast address allocation language in the MALLOC work.
So, it really tries to manage two sets of definitions.

> Which terminology is preferred? Is it the text in RFC 3307, or the

Depends on whether you want to talk IPv6 or MALLOC. :)
Seriously, 3307 does suffer from the fact it straddles two worlds
that defined separate terminology for the same behavior.

> I hope we don't need another (separate) document.

As do I.  My opinion is that we will need to spend some time
explaining the existing docs rather than writing yet another one.

> 3307-style Group IDs for which IANA has created a registry.

RFC 3306 explains this difference.  So, the additional reference
to 3306 for the P bit will help with this.

Regards,
Brian

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 16:34:02 -0400

> text to clarify the R & P bits.  We will ensure that the language is 

Sounds good. I guess the thing to do now is see what the proposed
text says.

Thanks,
Thomas

---

From: Bob Hinden <[email-masked]>
Date: Mon, 16 May 2005 16:49:56 -0700

Thomas,

>     space can be found in [RFC 3307] and are not updated by this

This raises the question I have had for a while, is when doing updates to 
existing standard what to put in the IANA section.  It seems to me it 
should be what changes should be made to the IANA registries, not a 
complete copy.  This is very different from the technical content of the 
document.  [I am starting to wonder if IANA considerations really belong in 
RFCs, but lets not go there today :-) ]

Instead of what you suggested, I think something like the following would 
be better:

    No other IANA IPv6 address registries need to be changed based on
    this document.

A few reasons for this include the references to 3513 and 3307 doesn't 
capture the complete history of the current IANA registries and this 
document will obsolete 3513 and this might make the note confusing.

Thanks,
Bob

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 May 2005 20:57:29 -0400

Bob,

> complete copy.  This is very different from the technical content of the 

Yep. And I don't have a one-size-fits all answer. I've seen some
documents just repeat the old section, but as you note that reads
funny if IANA has already done the work.

And since this document is obsoleting RFC 3513, it seems odd to point
back to it for definitive text.

I'm not sure the IESG has thought in a lot of detail about the
significance of obsoleting a document that contains an IANA
considerations section.

But, having said that, when trying to find the IANA considerations
related to a name space, it can be rather interesting sometimes just
trying to track down the pointers. So, I prefer seeing at least some
pointers to other documents than nothing at all.

My wording was an attempt to provide at least the start of a
reference, while still making it clear that this document isn't
changing any of the rules that are already in place.

>     No other IANA IPv6 address registries need to be changed based on

For me, having a reference to other documents is really the purpose of
adding something to this section. The above doesn't really add much
beyond complete silence.

> document will obsolete 3513 and this might make the note confusing.

Another possibility is to include some (but perhaps not  the entire
table) from RFC 3513, but point out that the new text is being
included for completeness and doesn't establish any new policy. That
might be a better the referring to an obsoleted document.

What I was trying to achieve was a balance between repeating all the
history (which is sometimes a bit convoluted) with at least a pointer
on where to get started for the details. But maybe we shouldn't even
go here... :-(

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 May 2005 10:14:16 -0700

Thomas,

>pointers to other documents than nothing at all.

I agree with what you are saying.  The problem here is that even RFC3513 
isn't consistent with what is on the IANA page 
(http://www.iana.org/assignments/ipv6-address-space).  It was, of course, 
changed the RFC3879,  RFC-carpenter-obsolete-1888-01.txt, and 
RFC-huston-ip6-iana-registry-05.txt.  Some of the history for each entry 
can be deduced from the references on the IANA page, but I agree it is not 
the complete history.  It would be nice if the IANA kept a publicly 
accessible log of each change.  That might helpful in the future.

>changing any of the rules that are already in place.

I understand.

>adding something to this section. The above doesn't really add much

It does at least say nothing else was changed :-)

>might be a better the referring to an obsoleted document.

As noted above, the format was changed in 
RFC-huston-ip6-iana-registry-05.txt so that might well cause more 
confusion.  We wouldn't want the IANA to change it back to the old 
format.  :-(
>on where to get started for the details. But maybe we shouldn't even

I agree, there isn't any simple solution.  I am starting to think it best 
to not say anything else about the history here short of trying to capture 
the whole history.  What do you think?

Bob