Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
draft-ietf-ngtrans-isatap-24

[Ballot comment]
The draft uses the term "site" (see e.g. 6.2), but the term is not defined.

The draft is silent about routing considerations, and routing over ISATAP interfaces will be affected by lack of mcast (see 6.3).

[Ballot discuss]
The draft uses the term "site" (see e.g. 6.2), but the term is not defined.

The draft is silent about routing considerations, and routing over ISATAP interfaces will be affected by lack of mcast (see 6.3).

Date: Thu, 08 May 2003 05:59:18 -0400
To: "Fred L. Templin"
From: Margaret Wasserman
Subject: Re: Request to publish 'draft-ietf-ngtrans-isatap-13.txt' as
  EXPERIMENTAL RFC
Cc: Bob Fink , itojun@iijlab.net, dthaler@microsoft.com,
  mohitt@microsoft.com, tgleeson@cisco.com, iesg@ietf.org


Hi Fred,

We have received your request to publish ISATAP as an experimental RFC, and
Randy has asked us, as the chairs of the IPv6 Operations WG, to comment on
this action.

We are, essentially, in the same situation as we were when you requested
this action a few months back.  The IPv6 Operations WG is still working on
the scenario and analysis documents that will allow us to properly assess
the applicability of IPv6 transition mechanisms, such as ISATAP.  Until
that work is completed, the v6ops group cannot fully determine the utility
or applicability of ISATAP or any other IPv6 transition mechanisms.

It is our belief that publishing a plethora of transition mechanisms with
overlapping applicability and no clear applicability statements may
cause confusion for implementors, increase the cost of IPv6 implementations
and cause interoperability problems.  We also believe that publishing any
additional transition mechanisms in RFCs prior to the completion of the
v6ops scenario/solutions work would undermine the efforts of the v6ops WG
to create a clean model for IPv4/v6 coexistence with well-understood
recommendations. This applies to ISATAP and to all other mechanisms that
are currently awaiting publication (DSTM, Teredo, NAT64, others).

Since your last request, we have made some progress on our scenario/analysis
work.  The 3GPP work is substantially completed, and is currently in review
by the 3GPP standards body.  The 3GPP scenario/solutions work does indicate
a need for dynamic tunneling solutions, such as 6to4 and ISATAP, but the 3GPP
analysis did not identify any scenario that could best be satisfied using
ISATAP.
There were some scenarios that are well-satisfied by 6to4, and other scenarios
for which none of the currently-proposed dynamic tunneling mechanisms can meet
the scaling requirements.  Have you read the 3GPP documents, and do you agree
with this analysis?

We're still working on the scenarios portion of the enterprise and
ISP efforts.  I realize that ISATAP is most applicable in an enterprise
environment, so perhaps there will be enterprise scenarios that demonstrate
a need for ISATAP.  I would suggest that you continue working with the
enterprise team to make sure that the enterprise scenarios and analysis
work comes to a fruitful conclusion.

Although the ultimate decision lies in the hands of the IESG, we will
continue to recommend against publishing any IPv6 transition mechanisms
in RFCs until their applicability has been demonstrated by our
scenario/analysis work.  We feel that it would be a mistake to publish
any mechanism without a good understanding of its applicability and a
comprehensive technical review by the v6ops WG.  We will not be able to
conduct a meaninful review until the applicability of each mechanism is
well-understood.

After we have published standards-track RFCs for each of the mechanisms
that we find applicable to common scenarios, we will seek to publish the
remaining mechanisms in experimental RFCs, with review by the v6ops
WG and appropriate notes regarding their applicability.

We hope that you and your fellow authors will work with us within the
v6ops group to accelerate the progress on our enterprise scenario/analysis
work, and that you will help us to understand the specific applicability
of ISATAP within that environment.  This is the best approach to
accelerate publication of ISATAP.

Best Regards,
Bob Fink, Itojun Hagino and Margaret Wasserman
IPv6 Operations WG Chairs