Re: comments on draft-ietf-ipv6-addr-arch-v4-00.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

> 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: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On
> > Behalf Of itojun@iijlab.net
> > Sent: Monday, December 15, 2003 2:27 AM
> > To: hinden@iprg.nokia.com; deering@cisco.com
> > Cc: ipv6@ietf.org
> > 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
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------