Subject: RE: POLL: Consensus for moving forward with Teredo?

From: <[email-masked]>
Date: Mon, 3 May 2004 13:17:15 +0300

Hi,

I vote for a).

In my opinion, useful mechanisms (that have already been widely implemented) must get an RFC status. It is not a good thing from the IETF point of view, if widely deployed and used mechanisms can not be published as an RFC.

As many people have communicated already, there are also other mechanisms needing a frozen specification, such as ISATAP.

So, let's start specification work (instead of continuing analysis and creating issues forvever).

	-Juha W.-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Brian E Carpenter
Sent: 02 May, 2004 10:59
To: [email-masked]
Subject: Re: POLL: Consensus for moving forward with Teredo?

I can't see any grounds not to proceed with Teredo, though I would
suggest considering a dedicated, very focussed WG, to get it done
more quickly and without de-focussing this WG. (But only if the
IESG is willing to move quickly.) Hence a).

I don't think we should complicate life by mixing this with the
issue of automatic tunnel broker discovery. That is new thinking
brought in by Jordi's draft, and let's keep it separate.

     Brian

JORDI PALET MARTINEZ wrote:
> Jim,
> 
> I fully agree with this view, and moreover, if we allow the auto-discovery of the TB, then even more clearly, the TB will be applicable to unman and other scenarios.
> 
> I wonder if Teredo could take advantage of the auto-discovery idea (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), making sure that if required both the 6to4, TB/TS/TSP, ISATAP and the Teredo relays, can coexist automatically in the same box. This could easily simplify the deployment and be an important multiplicative factor.
> 
> So, I will suggest a new option "a.bis)": The idea is to make a very quick move on defining a solution for the auto-discovery, and include this in a revised Teredo version (same with ISATAP, TSP, etc.).
> 
> Note that I will not like to delay the "go forward" of a) option for a long time, but I'm convinced that if Christian and some other people related to other transition mechanism (TB/TS, may be ISATAP) that need to discover end-point work together.
> 
> If we have inputs on the auto-discovery solution, I'm sure that a small team of "hard workers" could make it even before the next IETF. This is a small delay, but I believe the result could be worthy.
> 
> Christian, Pekka what do you think ? (I've not read the latest versions of Teredo, so I'm not sure if what I'm saying is actually meaningful, but I understand that the server/relay need to be pre-configured, so can we make it auto-discovered ?, indeed we didn't included Teredo in our I-D, but may be an option for the next revision).
> 
> Regards,
> Jordi
> 
> ----- Original Message ----- 
> From: "Bound, Jim" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, April 30, 2004 10:38 PM
> Subject: RE: POLL: Consensus for moving forward with Teredo?
> 
> 
> We must work on Teredo, ISATAP, DSTM, and Tunnel Broker.  All are being
> deployed all will exist.  So I vote for (a) but I think Tunnel Broker is
> also a choice for UMAN and if asked in the market tell them try both and
> see what you like best each have different properties.  And I hope there
> are more good and innovative transition mechanisms invented the more the
> better.  We will build many types of IPv6 networks I am sure we do not
> have all the tools for transition done and all of the above will be used
> and are useful for deployment.
> 
> /jim
> 
> 
>>-- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola 
>><[email-masked]> wrote/a ecrit:
>>
>>
>>>Hi,
>>>
>>>(co-chair hat on)
>>>
>>>As identified in the scenarios analysis at IETF59 and in 
>>>draft-savola-v6ops-tunneling-01.txt, there appears to a need which 
>>>cannot be filled by another mechanism for Teredo at least 
>>
>>in one major 
>>
>>>Unmanaged scenario.
>>>
>>>Is there rough consensus to move forward with Teredo? 
>>
>>(i.e., to adopt 
>>
>>>it as WG document in this WG or elsewhere, for Proposed Standard.)
>>>
>>>The main issue raised has been to call for a more extensive 
>>
>>analysis 
>>
>>>for the deployment implications of native, 6to4, and 
>>
>>Teredo.  There is 
>>
>>>already discussion of this in the Unmanaged Analysis 
>>
>>document.  There 
>>
>>>seemed to be very little energy or interest in the WG to drive this 
>>>much further.
>>>
>>>The options regarrding Teredo at this stage seem to be:
>>>
>>> a) Go forward with Teredo, hone the deployment implications in the 
>>>    unmanaged analysis in parallel (if and as appropriate),
>>>
>>> b) Conclude that there is no sufficiently strong need for 
>>
>>Teredo, and 
>>
>>>    not support its advancement (for PS) at this stage, or
>>>
>>> c) Decide that we need to analyze the scenarios or deployment more 
>>>    before being able to make a decision.  
>>>
>>>    If so, please state where you believe more analysis is needed.. 
>>>    and volunteer if possible :)
>>>
>>>If you have an opinion, please state it within a week, 
>>
>>i.e., by next 
>>
>>>Friday, 7th May.
>>>
>>>Thanks!
>>>
>>>(co-chair hat off)
>>>
>>
>>
>>
>>------------------------------------------
>>Marc Blanchet
>>Hexago
>>tel: +1-418-266-5533x225
>>------------------------------------------
>>http://www.freenet6.net: IPv6 connectivity
>>------------------------------------------
>>
>>
>>
> 
> 
> 
> 
> 
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> 
>

---

From: Jonne Soininen <[email-masked]>
Date: 03 May 2004 18:46:15 +0300

Hello,

(chair hat off)
I support option a) for the reasons provided already basically by other
people. 

However, my main point is that teredo is a mechanism that has been there
for quite some time and has shown some stability and running code. 

I also agree with Brian that maybe v6ops is not the right place to do
the actual protocol work, but a separate WG would be a better fit.

I also agree that there are other mechanisms already on the table that
would merit the same treatment.

Cheers,

Jonne.
(chair hat on)