Subject: RE: WGLC ent-analysis-03: DSTM

From: "Bound, Jim" <[email-masked]>
Date: Mon, 8 Aug 2005 08:01:46 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: Friday, August 05, 2005 3:47 PM
> To: [email-masked]
> 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
> 
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Aug 2005 11:58:22 -0700

Jim:

I don't think Pekka was saying that Dual-Stack as described in RFCs  
1933 and 2765 is not important to operators. I think that he was  
saying that extending that to include an Experimental protocol that  
has specific algorithms attached to it that haven't been agreed to  
seems an odd recommendation from a working group document.

I think you need to take a little less strident attitude. Your  
commentary re DSTM sounds a little like "this is my protocol and you  
don't get to comment on it". If you can't find a way to accept  
Pekka's commentary, we may need to make this no longer be a working  
group draft, and advise the IESG to ensure that any RFC Editor path  
submission of it be published with a note stating that it was not  
agreed to by the relevant working group.

Lets find common ground here, guys.

Fred