Subject: [BEHAVE] Re: ICE deployment data before LC for RFC

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 19 Jul 2007 14:14:21 -0700

My apology for the duplicate postings. 
Having initiated this ample discussion about how to proceed with ICE-17,
it seems the following have emerged:

ICE-17 is an excellent document (bravo authors and contributors) and can
hardly get better at present.

The technical points discussed cannot change this fact either way.

Ironically, the defense of ICE-17 on procedural grounds makes even less
sense, since the culprit is not ICE-17, but the fact that present IETF
procedures do not make a clear enough distinction that everyone can
understand between I-D categories, such as:

* Concept memos; see the torrent in the P2PSIP WG
* Protocol standard agreements, such as for SIP
* Technology solutions such as ICE-17 or hole punching for NAT traversal
* I-Ds to support a business model (excuse me; I will not go there...)

Sorry to repeat: Process and consensus in meetings have nothing to do
with how good a technology may be. Only measurements and proof will do.

How does the IETF support the proof for a technology? (Yes, I have seen
all those quotes). Please remember that proving a technology also costs
money.
This is the reason why I trust more technologies coming out of funded
R&D, especially from University research. Vendors of technology may be
less likely to share such information.

Question: Is a standards organization the best place to develop and
promote new technology such as for NAT traversal? (all those p2p
companies and Skype did not think so...) Also, be prepared, SBC
traversal may come next.

In conclusion, there is nothing wrong with the ICE-17 paper IMHO, but
rather the IETF processes are either not satisfactory or not well
understood by folks like me who avoid reading process documents longer
than one web page :-) 

I have taken therefore the liberty to copy <[email-masked]> as Adam Roach
has suggested.

Thanks, 
Henry Sinnreich

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Jul 2007 13:30:33 -0500

On 7/19/07 1:08 PM, David Barrett wrote:
>> -----Original Message-----
>> From: Adam Roach [mailto:[email-masked]]
>> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC
>>
>> To be clear: to get this kind of experience (especially as it pertains
>> to interoperability), you need to have a stable (i.e., frozen)
>> specification. Internet Drafts simply don't provide an appropriate basis
>> for the kinds of proof that you and others are demanding.
>>     
>
> It seems premature to freeze the specification before we've proven that what
> specified actually works.  Indeed, the most successful real-world projects
> I've participated in worked in the exact opposite manner.
>   

In that case, you're arguing with the IETF standards process, and have 
decided to beat on ICE as a proxy whipping boy for reasons that have no 
technical basis in ICE itself. The current process surrounding RFC 
publication is detailed in RFC 2026. Section 4.1 details the process 
you're misunderstanding. It's short. You should read it.

If you're up to it, RFC 3774 and RFC 3844 also provide some useful 
background on the work that has been done in this area recently.

Concerns about IETF RFC publication process in general -- and that's 
what you're arguing about here, not ICE itself -- are best addressed to 
the IETF-general mailing list and/or the IESG itself (as the conclusion 
of the problem WG was that issues surrounding the standards process were 
to be handed back to the IESG).

/a