Subject: RE: Request to Publish ISATAP

From: "Christian Huitema" <[email-masked]>
Date: Mon, 23 Dec 2002 17:42:11 -0800

Margaret, Itojun, 

I am a bit puzzled by some elements of your response.

> The v6ops chairs do believe that the publication of this

> document would represent an end-run for two reasons:

>     (1) It is proposed that ISATAP would obsolete a portion

>           of RFC 2893.  The v6ops WG is currently updating

>           RFC 2893, and it will be our decision whether or

>           not to remove the automatic tunneling mechanism.

>           ISATAP does not, and should not, obsolete that

>           mechanism.

I re-read the ISATAP draft, and I am at a loss with this comment. The
draft cites 2893 as it goes on using the 2893 nomenclature, but I don't
see where it actually proposes to obsolete either 2893, or mechanisms
defined in 2893. In any case, the proposition was for an experimental
publication; experiments come and go, and certainly do not obsolete
standard track recommendations.

>     (2) The v6ops WG is currently undergoing a process

>           to enumerate and analyze the expected scenarios

>           for IPv4 -> IPv4/IPv6 transition, with the

>           goal of producing a single, coordinated set

>           of transition mechanisms, each of which will

>           include appropriate applicability information.

>           The publication of a transition mechanism via

>           another track, before its applicability is

>           analyzed, would undermine this effort.

I think that there ought to be a different bar for experimental and
standard tracks presentation. The standard track document is something
we recommend, a solution that we believe is well engineered. An
experimental RFC does not convey an endorsement; it is more a license
to, well, experiment. Judging an experimental RFC by how it fits with
the overall grand plan of the working group defeats the whole concept of
experimental RFC, which may well precisely be to experiment outside of
this consensus.

This does not mean that we should just say yes. It should just mean that
the bar should be different. Not, "does it fit with our plans?" But
rather, "If this experiment was conducted, would it hurt the Internet?"
For example, it would be quite reasonable, even necessary, to refuse
publication of a protocol if its security holes would endanger its
users, or even worse other Internet users. It would also be necessary
and reasonable to refuse publication of a protocol that would cause or
aggravate network congestion.

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. 

> The v6ops chairs will be expressing this opinion to the IESG

> in one week.  We wanted the WG to be aware of this situation,

> and we would welcome your feedback regarding our position.

I would very much like this position to be reconsidered.

-- Christian Huitema

---

From: [email-masked]
Date: Tue, 24 Dec 2002 10:49:06 +0900

>standard track recommendations.

	to correct your understandings -
	please see the last part of the previous email Margaret have sent.
	(the part where an email from Fred is quoted verbatim)

	- Fred asked to publish it as a standard-track document
	- he suggested that ISATAP obsoletes automatic tunnelling in RFC2893
	  (::10.2.2.2).  the chairs does not agree with it and there's no
	  consensus in the wg seen from the chairs

itojun

From: Fred Templin <[email-masked]>
To: [email-masked], [email-masked], [email-masked],
   [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
   [email-masked], [email-masked]
Subject: Plea to ADs to sponsor isatap-07 for standards track		<----
Date: Fri, 13 Dec 2002 21:32:48 -0800 (PST)
(snip)
In the spirit of Harald Alvestrand's 11/19/02 message to v6ops
entitled "On NGTRANS, transition mechanisms and consortia", I am
issuing a plea to the ADs to sponsor this document for standards
track based on the obvious merit that it obsoletes the automatic	<----
tunneling mechanisms specified in RFC 2893.				<----

---

From: [email-masked]
Date: Tue, 24 Dec 2002 11:50:06 +0900

>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

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Dec 2002 05:51:19 -0800 (PST)

Itojun,

Let me first say, it should be clear to all that I am struggling
with process details. But, how can *anyone* be expected to get
things exactly right when the NGTRANS closing has come upon us
so quickly and the closing procedures have been so nebulous?
The new charter seems restrictive to the point of requiring
authors to leap high buildings just to get their documents
recognized - even though some (like ISATAP) have been out in
the public discussion for over *two years* now.

The chairs have asked for transition scenario documents, and
one has been written, presented and revised for ISATAP. I am
certain that ISATAP can provide useful benefit to some of the
other operational areas as well, and additional scenario documents
could be written. But again, how high does an author need to jump
to get on your radar screen?? If this document can't go standards
track right now, let's at least get it through as experimental
so we can prove to the community in due course that further
progression is warranted.

Now to your questions: 

--- [email-masked] wrote:
> 	address option in ND from the normal ND.

This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph
on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the
normative text that allows what ISATAP is doing is plain for all to see.

>       also in 5.2, the document

Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1,
we have the following text:

   However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., NBMA links)
   alternative protocols or mechanisms to implement those services will
   be specified (in the appropriate document covering the operation of
   IP over a particular link type).

Clearly, no updates to RFC2461 are necessary since ISATAP is exactly
such "the appropriate document..." as described above.

> 	is it documented in ISATAP document?  if so, where?

This refers to the text exactly one sentence earlier, which says:

   ISATAP hosts SHOULD enhance the static address resolution computation
   with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA)

So, "simple address resolution" = static computation with no neighbor
discovery exchange, and "enhanced address resolution" = static computation
plus a unicast NS/NA exchange. How clear do we need to be?
 
> 	the use of DNS must be dropped from the router discovery mechanism.

Yes, DNS is one alternative for discovering the ISATAP router - but
not the only one. Even so, the sequence a dual-stack node can use
the following bootstrapping procedure:

  - discover IPv4 address; DNS server
  - configure the IPv4 stack
  - wait for a while for native IPv6 RAs to arrive
  - if no native v6 service:
    - discover a domain name for the ISATAP service
    - resolve the name into a list of IPv4 addresses
      by name service lookup (could be DNS, could be
      static file, ec.)

Can you explain to me a scenario in which this would *not* work?

> 	however, it is not enough.

Talk about unsubsantiated opinions! This statement would have been
like the founding architects saying: "packet switching networks can
incur congestion in some cases, so let's not even bother building them".
Clearly, there is a need for better understanding of ISATAP's scaling
properties - but, that's what experiments are for!

BTW, my belief is that the ISATAP scaling question is a non-issue.
Even if a site administrator felt the need to strategically deploy
equipment for fault tolerance, load balancing, etc. the specification
provides abundat flexibility to support this. It is left to implementors
to create robust products to satisfy the anticipated needs of customers;
the ISATAP specification has no business meddling in implementation
details.  
 
> >   specification is made freely available to IANA for any purpose they

Let me recommend that you give it 1-2 more re-reads, then skip ahead to
Appendix B. The meaning is there, and the words (while not optimal) seem
adequate to me. If you are still confused, let me assure you this text
has absolutely no operational bearing on the rest of the specification. 
 
> 	of implementation/scaling/usage)

See my above comments on process; I'm sure you can sense my frustration
in having been stuck on the outside looking in after all this time of
collaborative contribution to the community.

Fred Templin
[email-masked]

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Dec 2002 05:58:13 -0800 (PST)

Itojun,

Now to your questions: 

 

 

Fred Templin
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 Dec 2002 10:46:26 -0500

Hi Fred,

>so quickly and the closing procedures have been so nebulous?

I can certainly understand your frustration, and I think we're
all struggling with some of the process details here.  Very
few of us have been through the shutdown of a WG before, so
we are learning the process as we do it.

>the public discussion for over *two years* now.

I hope it is clear that the restrictiveness of the current
v6ops charter is intentional.  We are not chartered to publish
any new standards track transition mechanisms until we understand
the most likely deployment scenarios, and have completed the
analysis to determine what transition mechanisms are actually
needed.  The analysis is well underway for the 3GPP and
Unmanaged areas, and the Enterprise and ISP areas are making
progress on scenarios.

>could be written.

If I recall correctly, these documents were requested by the
ngtrans chairs.  I think that the ISATAP document, in particular,
will provide useful input to the Enterprise design team.  If
you think that ISATAP is applicable to the scenarios raised in
the 3GPP, Unmanaged or ISP documents, you may want to discuss
that on the v6ops list or with the authors of those documents.

>But again, how high does an author need to jump
>to get on your radar screen??

ISATAP is already on the radar screen.  We're just not ready to
publish any new mechanisms until their applicability is demonstrated
by the scenario/analysis work.

>If this document can't go standards

It is outside the scope of the v6ops WG to publish ISATAP as an
experimental RFC.  However, if you would like to do an individual
submission for publication as an experimental RFC, you should
first publish your final document, preferably with fixes to address
Itojun's issues, as an Internet-Draft.

Before you publish it, you should also make sure that it meets the
RFC editorial policies, found at:

http://www.rfc-editor.org/policy.html

Then, send mail to the RFC editor ([email-masked])
requesting that the RFC editor publish your individual submission
as an experimental RFC.

As part of their usual review process, the RFC editor will ask
the IESG if your document represents an end-run around any IETF
WGs and/or has any technical issues that should block its
publication.  At that point, our AD, Randy Bush, will probably come
to the v6ops WG chairs and ask us if we have any procedural or
technical objections to publishing the document as experimental.

At that point, Itojun and I will discuss this amongst ourselves
and with the WG, and we will return an answer to the IESG.

Let me know if you have any questions about this process.

In the meantime, the question on the table is whether ISATAP
should be published as a standards track document that
obsoletes part of RFC 2893, which we believe it should not.

Margaret

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Dec 2002 09:45:06 -0800 (PST)

Margaret,

> Let me know if you have any questions about this process.

Thanks for the clear explaination. Your note gave a detailed
roadmap for publication as experimental RFC which I'm certain
can be followed with no further process issues.
 
> obsoletes part of RFC 2893, which we believe it should not.

I respect the v6ops WG chairs' decision on this, and withdraw
the question of standards-track publication.

Fred Templin
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 Dec 2002 12:46:58 -0500

Thanks, Fred.

Margaret

---

From: [email-masked]
Date: Wed, 25 Dec 2002 08:50:08 +0900

on process details, i guess Margaret have answered.

>normative text that allows what ISATAP is doing is plain for all to see.

	i don't think RFC2461 section 7.2.2 permits modification to link-layer
	address option handling in ISATAP.  it only talks about the intended
	behavior of a node, like:
	- if dst = solicited-node multicast address, link-layer address option
	  MUST be present
	- otherwise, it SHOULD be present
	- for unicast solicitation an implementation MAY omit it

	ISATAP, on the other hand, defines a new handling rule for link-layer
	address option in the very last paragraph of 5.1.  it does not seem
	to me a permissible thing to do.

>such "the appropriate document..." as described above.

	the text right after the above-quoted part suggests me that "ND over
	NBMA is an area for further study".  it suggests me the need to define
	"ND over NBMA", in a link-layer independent manner.  the text does not
	permit you to define a new link-layer address option handling in ISATAP
	document.

	i guess IPv6 wg needs to provide "ND over NBMA" document, then ISATAP
	has to follow the ND sending/receiving rules in "ND over NBMA" document.

>plus a unicast NS/NA exchange. How clear do we need to be?

	you did not define "enhanced address resolution" in the text.  you
	should define a term whenever it is used for the first time in the
	document.  otherwise the reference "enhanced address resolution"
	becomes ambiguous to readers.
 
>Can you explain to me a scenario in which this would *not* work?

	if you assume the above scenario, the above bootstrap process should
	be documented (i.e. IPv4 DNS server must be known to the ISATAP node
	via DHCPv4 or whatever, before ISATAP router discovery process gets
	started).

	even with the above, once you discover IPv6 DNS server via DHCPv6-
	over-ISATAP or whatever, you create a circular dependency between link
	layer and DNS.  circular dependency is bad as it could put your stack
	into deadlock situation (it would like to send DNS traffic out for
	"isatap.example.com" but it can't), and worse, could be used by
	malicious party to put your stack into deadlock situation.

	therefore, i strongry recommend dropping ISATAP router discovery using
	DNS.

>properties - but, that's what experiments are for!

	but what you have asked for was a standard-track publication, not
	experimental.  and the scaling property of ISATAP i observed from
	the document has problem (even without experiment), as i stated above.

>the ISATAP specification has no business meddling in implementation
 
	i tend to disagree - if there's obvious choke point in a
	specification we need to diagnose, we need to update specification,
	suggest operational workaround, or do whatever needed, to avoid that
	choke point.

>has absolutely no operational bearing on the rest of the specification. 

	I of course read appendix B.  what i don't understand is "this
	specification is made freely available to IANA..." part.  what is
	meant by "freely"?  free of charge?  freedom of use?  free from IPR
	issues?  what kind of control IANA would like to have over the
	EUI64 creation process in ISATAP document?   i still don't understand
	what you are trying to mean.

itojun

---

From: Fred Templin <[email-masked]>
Date: Tue, 31 Dec 2002 15:09:49 -0800 (PST)

Itojun,

I will not go into the specifics of your message dated 12/24/02,
but would ask that you review and comment on the latest version
of the draft found at:

  http://www.geocities.com/osprey67/isatap-09.txt

Margaret,

In your message dated 12/23/02, you mentioned that the v6ops chairs
would be expressing their opinion to the IESG in one week. Since the
ID registrars are on vacation, I would like to humbly request that
the wg chair defer their annoucement until the above draft can be
submitted to the registrar.

Sincerely, 

Fred L. Templin
[email-masked]