RE: WGLC ent-analysis-03: DSTM

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

We are not removing DSTM from this spec all the authors know for a fact
it is important to operators.  If you want further applicability
statements we can do that and there is other work in progress.

Thanks for you input,
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Friday, August 05, 2005 3:47 PM
> To: v6ops@ops.ietf.org
> Subject: WGLC ent-analysis-03: DSTM
> 
> Hi,
> 
> (I'll put two most separable & possibly most discussable items in 
> separate mails.)
> 
> In 8.1:
> 
>   Later in the transition process, after the enterprise has
>   transitioned to a predominately IPv6 infrastructure, the architect
>   should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
>   in the case of early deployment of IPv6-dominant networks DSTM can
>   be used too.
> 
> and in 8.4:
> 
> DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
> enterprise transition or deployment of IPv6-dominant network links
> is desired. DSTM is to being submitted as an IETF Experimental RFC.
> 
> ==> as it is, DSTM is a way too overloaded a mechanism to be 
> referred to
> without more disclaimers or description.  As it is, different 
> people use
> "DSTM" to mean at least the following things:
>   a) v4-in-v6 tunnels
>   b) automatically set-up v4-in-v6 tunnels
>   c) automatic set up of v4-in-v6 tunnels when the host
>      doesn't have v4 address and an app wants to create a v4 socket
>   d) automatic monitoring and tear-down of said v4-over-v6 tunnel
>      when the host detects it no longer needs the address/connectivity
>   e) plus a number of extensions for even more colorful setups.
> 
> a) doesn't require DSTM; b) can be achieved using a tunnel broker; c)
> does not require IETF interoperability (a local implementation choice
> when/how to launch the v4-in-v6 activation).  d) could also 
> be considered in
> the same category (there are no bits in the wire or anything requiring
> interoperability AFAICS on when the host removes the tunnel), 
> though I'm
> skeptical whether even providing that would be a good 
> engineering choice.
> 
> My point is that I'm having hard time figuring out:
>   1) what the document means when it's recommending DSTM, and
>   2) based on my analysis above, I do not believe that DSTM 
> (in the way that
>      I think it's being referred to) is even needed.
> 
> Therefore my suggestion is to remove references to DSTM 
> (preferable) or
> greatly clarify the assumptions and the requirements on why it should
> be necessary. (On the other hand, if the DSTM spec only described the
> algorithms for doing c) and d) above in my list, I would have 
> a lot fewer
> concerns -- but as it is, I believe a reference would confuse 
> more than
> help.)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>