> - Revised sections 2.4 and 2.5.6 to simplify and clarify how
> different address types are identified. This was done to insure
> that implementations do not build in any knowledge about global
> unicast format prefixes. Changes include:
> o Removed Format Prefix (FP) terminology
> o Revised list of address types only includes exceptions to
> global unicast and a singe entry that identifies everything
> else as Global Unicast.
I apologise. I hadn't noticed this change before and I think it is very
confusing. I think the detail you have dropped from the table at the
beginning of 2.4 and replaced by
Global unicast (everything else)
was useful. Hiding this detail in pointers and references in the text is
a mistake in terms of document clarity.
I also think that abolishing the term "format prefix" is obfuscation. The fact
is that the leading bits of an address *are* a format prefix and implementors
*will* look at those bits before processing an address. Why obscure that fact?
The goal of ensuring that global unicast addresses are treated opaquely except
by the routing system is a good one of course. However, I think this was not the
best way to achieve it, or rather you have gone too far.
(Also, there are options that multi6 might adopt that would change things so
that hosts would look inside global unicast addresses. This would cause us
to re-invent the format prefix PDQ.)
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
