RE: WGLC ent-analysis-03: DSTM

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

Fred,

It is not a strident attitude.  DSTM was work in the IETF for minimum
two years, has been deployed in test networks, and the response was the
authors response not Jim's response.

I think we need applicability around it for sure.

Please don't threaten me or the authors work because of a quick email
that I stated would have more serious follow up.  That is inappropriate
and I would like an apology for your assumption that was my intention?
I think you jumped the gun on the response.  We are not going to remove
DSTM at this time, first we would like to attempt applicability
statements.

Thanks for your input,
/jim 

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Tuesday, August 09, 2005 2:58 PM
> To: Bound, Jim
> Cc: Pekka Savola; v6ops@ops.ietf.org
> Subject: Re: WGLC ent-analysis-03: DSTM
> 
> 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
> 
> 
> On Aug 8, 2005, at 5:01 AM, Bound, Jim wrote:
> 
> > 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
> >>
> >>
> >
>