Re: Request to Publish ISATAP

[itojun@iijlab.net]

>If the working group wants to refuse the publication of ISATAP, it
>should do so on technical grounds, because the mechanism would be
>somehow dangerous, not because it does not fit in the plan. The "does
>not fit" comment would rather belong to some kind of application
>statement. And, there is indeed always the possibility to have a
>standard track RFC obsolete a previous experiment.

	(chair hat off)

	sorry for doing it in this late stage (from Fred's view),
	i see a couple of major technical problem with ISATAP-08 document.

	in 5.1, the document proposes a different handling of link-layer
	address option in ND from the normal ND.  also in 5.2, the document
	proposes special handling of router discovery.  ND and router discovery
	have to be link-layer independent, and if we wish to make any changes
	to ND/autoconf, we must update RFC2461/2462, in link-layer independent
	manner.

	in 5.1, paragraph 2, what does "enhanced address resolution" mean?
	is it documented in ISATAP document?  if so, where?

	it is proposed that router discovery mechanism (near 5.2, find "PRL"
	for Potential Router List) would use DNS for discovering ISATAP router.
	it creates circular dependency between link layer (ISATAP) and DNS.
	the use of DNS must be dropped from the router discovery mechanism.

	ISATAP router is a choke point wrt scalability of the mechanism
	(for instance, link speed of ISATAP router would be the bottleneck for
	all of the nodes in an ISATAP-based site).
	we might be able to achieve some level of load-balancing using
	coordinated advertisement of ISATAP router via PRL announcement,
	however, it is not enough.

	i can't really parse section 7 paragraph 2.  what does it mean?
>   Appendix B proposes a specification for managing the IEEE OUI
>   assigned to IANA for EUI-64 interface identifier construction.  This
>   specification is made freely available to IANA for any purpose they
>   may find useful.

	(and to re-itereate)
	ISATAP does not supersede automatic tunnelling in RFC2893.  automatic
	tunnelling does not limit itself to the use within a site (::/96 route
	won't be there from RFC2772, but anyways, RFC2893 does not limit the
	domain of usage like ISATAP).  there's no equivalent to ISATAP router
	in auto tunnel.  ISATAP and automatic tunnelling are different
	mechanism, therefore the Plea to AD was technically incorrect.
	(mech-v2-01 obsoletes automatic tunnelling for different reason - lack
	of implementation/scaling/usage)

itojun