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

["Bound, Jim" <jim.bound@hp.com>]

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
--------------------------------------------------------------------