> Kill NSAPs they are dead and gone. I don't see how we can de-reserve the prefix. It might be time to ask the IESG to reclassify RFC 1888 as Historic.
Brian (now off-line until Jan. 5) "Bound, Jim" wrote: > > I support this nice concise report. Esp. that multicast is well defined > and I agree. IPv4 Mapped "on the wire" should not be permitted ok as API > for 3493. Kill NSAPs they are dead and gone. ACK on compatible address > too. > > Thanks > /jim > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of [EMAIL PROTECTED] > > Sent: Monday, December 15, 2003 2:27 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: comments on draft-ietf-ipv6-addr-arch-v4-00.txt > > > > > > as an IAB i was asked to comment on > > draft-ietf-ipv6-addr-arch-v4-00.txt, > > so here it is. happy holidays. > > > > itojun > > > > > > MAJOR > > ===== > > "scope" > > the use of word/concept "scope" needs more care. moreover the > > terminology is not consistent (such as "link-scope" and > > "local scope"). > > (maybe this is because there is a separate draft for > > scoped address > > architecture, but anyways, first-time readers will get > > confused). > > > > multicast scope is well documented in 2.7. the problem > > is in the way > > unicast scope is documented. > > > > here are use of unicast "scope" in the document (maybe > > i missed some of > > those): > > 2.1: link-scope > > 2.4: of any scope > > 2.5.1: over a broader scope > > local scope interface identifier > > universal scope interface identifier > > universal scope (multiple occurrences) > > local scope (multiple occurrences) > > 2.5.3: link-local scope > > > > solution: there has to be a section describing what the > > unicast "scope" > > is, in very early part of the document. it can be very > > simple as there > > are only two scopes - link-local and global. > > use terminology such as "link-local scope" or "global scope" > > consistently. > > > > another solution: refer to scoped address architecture document. > > however, it will create dependency to scoped address > > architecture > > document which is not very desirable. > > > > it seems that the document tries to use "universal > > scope" to refer > > the scope of global unicast address, however, it is a > > bit confusing. > > maybe it is better to use "global scope" - in fact, ff0e::/16 is > > called "global scope", not "universal scope". > > > > textual representation > > 2.2 (1) has to state how many digits are permitted as "x" > > (one component between colon). my personal preference is that > > "x" has to be 1 to 4 digits (5 digits or more is invalid). > > > > remove "::13.1.68.3" from example for (3), as we no longer have > > IPv4 compatible address (not to confuse readers). > > > > IPv4 mapped address > > if I remember correctly > > draft-itojun-v6ops-v4mapped-harmful-02.txt > > (IPv4 mapped address on-wire is harmful) got enough > > consensus. please > > document that IPv4 mapped address is not permitted on > > wire, in 2.5.5. > > > > i know this is not a document to discuss on-wire stuff, however, > > there's no better place to document it. > > > > IPv4 compatible address > > 2.5.5 states that "The IPv6 transition mechanisms > > [TRAN] include..." > > for IPv4 compatible address. however, [TRAN] (RFC2893) > > no longer > > includes automatic tunnel. > > > > solution: mark IPv4 compatible as historic, just like > > site-local. > > > > EUI64 > > the last paragraph in 2.5.1 is incorrect: it states > > that "Interface IDs > > are required to be 64 bits long and to be constructed > > in Modified > > EUI-64 format". however, after "and" (EUI64 portion) > > is not true. > > (it is not required to construct interface ID based on > > EUI64 format, > > moreover, EUI64 method is applicable only to interfaces > > of certain > > media types) > > > > > > MINOR > > ===== > > NSAP address > > 2.5 and 2.5.4 talks about "encoded NSAP address" which is not of > > interest for many of the readers. i'd suggest removing it. > > there could be other places where encoded NSAP address > > is mentioned. > > > > (is it used in practice? it'll be interesting to see the > > implementation report when the document advances to DS) > > > > security consideration > > it may be worthwhile to state that noone should use addresses as > > authenticator - AH (or ESP) has to be used instead. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [EMAIL PROTECTED] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
