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