Tim,
At 04:03 PM 03/08/2005, Tim Chown wrote:
On Tue, Mar 08, 2005 at 04:29:22PM +0100, Mohsen Souissi wrote:
> ==> Maybe it should be stated clearly whether we may or may not keep > using "site-local" terminology in the multicast context while that > terminology has been deprecated in the unicast context...
This also crops up in Appendix B in the change section at the end - it says "Deprecated the site-local" where really "unicast" should be inserted.
Agreed.
Appendix B will need a bullet point for the deprecation of compatibles.
See later comment about compatibles.
In 2.5.5. the reference to TRAN should obviously be removed, since TRAN no longer includes compatibles. In terms of the wording to deprecate compatibles in the first part of 2.5.5 the wording of 2.5.7 (for the deprecation of site locals) seems appropriate (bearing in mind Alain's comments today).
It seems today we agreed to alter the first sentence of 2.5.7 to no er refer to [SLDEP] to remove the dependancy. Since we have no document describing the deprecation of compatibles, this seems OK?
I think it is useful to keep the reference to SLDEP because it provides an explanation on why Site-local were deprecated. As we discussed at the IPv6 session yesterday, it should be fine to keep the reference but make it informational. This document does not depend on it.
I will send out proposed text about deprecation of IPv4 compatible addresses to the list in a separate email (maybe not today). I think it will remove the reference to TRAN. The decision to deprecate Ipv6 compatible addresses made at yesterdays IPv6 session will, of course, need to be confirmed on the mailing list.
At what point will we modify addr-arch to include the ULAs? It may be too early to include ULAs in 2.5.7, unles the 'probabilistic' unique draft discussed today is finalised very soo? A further update will be required for the centrally assigned ULAs?
Good question. I don't think it is necessary to add ULAs to the Address Architecture because they don't require any special handling (in the way site-local did). They are another flavor of unicast addresses that don't need any special handling that would have to be called out in Section 2.4.
The bit in 2.7 that says
"link-local and site-local multicast scopes span the same
topological regions as the corresponding unicast scopes."
might be reworded.
I looked at the text and propose changing the text about multicast scopes to:
......
link-local multicast scope spans the same topological region as the corresponding unicast scope.
admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration.
site-local scope is intended to span a single site.
......
This is slightly different than was proposed at yesterday's w.g. session, but I think it is clearer and correct.
Also in 2.7 "address whose scop" should be "scope" (twice).
The name of the field in the multicast address is "scop". The text you cite says "addresses whose scop field" where field should make it clear that it is refering to the field. Would it help if scop was put in quotes (e.g., "scop")? Other suggestions?
Thanks, Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
