RE: approach to moving forward w/ mechanisms [RE: Review requested: draft-huitema-v6ops-teredo-02.txt]

["Tony Hain" <alh-ietf@tndh.net>]

Unfortunately the drill appears to be fluid based on the mood of a few
people. According to the IETF chair when he was Ops AD, technologies that
will see widespread deployment and need to be interoperable should be on the
standards track. The recent discussion about Experimental is an effort at a
political side step for the IESG. This appears to take them out of the line
of fire rather than accepting the reality that the IESG can't decide what
people will be allowed to deploy. No matter how much they want to dictate to
the market, there will be technologies shipped and deployed without their
blessing. The longer they take to allow any progress, the more likely it is
that the technology developers will declare the IETF irrelevant and just
start shipping code leaving the consumer to decide. Without interoperability
as a basis, the technology selection will become a battle of marketing
departments. 

We have a set of transition technologies that address the needs of various
existing deployed environments. There are minor overlaps, but the core of
each approach is not discussed in competing proposals. Refusing to publish
them all is an attempt to dictate which environments are acceptable and
which are not. Clearly that was not done for IPv4, or the environments
undesirable to some would not exist. Since they do, someone saw a clear need
for it and our job is to migrate the protocol version in that environment.
Forcing network managers to change deployment models is explicitly out of
scope. Two years ago we stopped work so we could explain the complexity of
real networks to the IESG, and now with those documents in hand we still
can't move ...

The bottom line is that we need automated, brokered, and manually configured
tunnels that work with and without IPv4 nat in the path. We also need
stateful & stateless translators at various points in the stack, mechanisms
for handling IPv4 in IPv6-only networks, as well as the basic transition
mechanism of parallel IPv6 & IPv4 packet streams. All of these approaches
MUST be on the standards track, or there is no point in bothering with the
IETF since that energy should be focused on marketing sooner rather than
later.

Tony


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of Bound, Jim
> Sent: Monday, June 21, 2004 11:58 AM
> To: Pekka Savola
> Cc: v6ops@ops.ietf.org; huitema@microsoft.com
> Subject: RE: approach to moving forward w/ mechanisms [RE: Review
> requested: draft-huitema-v6ops-teredo-02.txt]
> 
> True.  My issue is did we agree on Proposed Standard?
> 
> On the other topic then lets move forward with ISATAP and DSTM.   Both
> should be on the IETF 59 agenda too.  I will commit to presenting where
> we are with DSTM and updated draft is coming now.  DSTM authors were
> under the impression our only option was Experimental.  If Teredo can go
> to PS DSTm may want to ask the WG the same question.  It appears the
> drill has changed.
> 
> Thanks
> /jim
> 
> > -----Original Message-----
> > From: Pekka Savola [mailto:pekkas@netcore.fi]
> > Sent: Monday, June 21, 2004 2:38 PM
> > To: Bound, Jim
> > Cc: v6ops@ops.ietf.org; huitema@microsoft.com
> > Subject: approach to moving forward w/ mechanisms [RE: Review
> > requested: draft-huitema-v6ops-teredo-02.txt]
> >
> > On Mon, 21 Jun 2004, Bound, Jim wrote:
> > > If we accept this we need to move on all mechanisms not
> > just Teredo.
> > > I support moving forward on all of them.  PS is still unclear to me
> > > and I thought we were going to suggest Experimental RFC?
> >
> > ("If we accept this" -- accept what?  There has already been
> > consensus for Teredo, so I'm not sure what acceptance you're
> > referring to.)
> >
> > This is really a more generic topic, so changing the subject.
> >
> > The intent all along has been to move on (or work on) the
> > mechanisms with clearly required mainstream scenarios, based
> > on the analysis, etc. -- you know the drill. In other words,
> > there has always been resistance to just moving forward with
> > everything that has been proposed or might be proposed.
> >
> > Now, at IETF59 there was consensus for policy that the
> > authors of those proposed mechanisms, even if there was no
> > consensus or clear need for them, *could* publish them as
> > Experimental or Informational through RFC editor if they so
> > wished (including a very strong note that it is not an IETF
> > activity, etc.).  This only applied to the
> > *implemented* protocols, as far as they have been
> > implemented. I.e., a way to document an implemented protocol
> > for interoperability.
> >
> > The question how to move forward with the required
> > mechanisms, for which there has been consensus, (currently,
> > this list includes Teredo and so-called BGP-tunnel), is
> > separate from that.  That work could be done as invididual
> > submissions through ADs, through a new WG-to-be-formed, or
> > through v6ops.  The category could be PS or maybe
> > experimental.  These issues have not become clear yet, unfortunately.
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
> >