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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Jul 2007 09:59:31 -0400

There are in fact deployments of ICE, more than one, based on previous 
versions of the draft.

Most folks I talk to are waiting to IETF to finish this thing, so they 
can go upgrade their code and move to the final version. Delaying it, 
making it experiental, informational, or any other variation will serve 
no other purpose than to convince everyone that this work is not done, 
and so folks should continue to wait. If you want an industry's worth of 
feedback and data, lets go and finish this thing. That means PS.

All of that said, ICE has, probably more than most other specs that have 
ever come out of RAI, have had the benefit of:

   a. extensive technical review, comments and feedbacks, including 
commentary from implementors (including one in my own company, and 
several others from outside of it) and deployers (Tim Moore from Microsoft)

   b. design based on years of experience with NATs and NAT traversal

   c. design based on real collected data on NAT behaviors and on 
techniques used in other applications

   d. consideration on incremental deployability and applicability 
across the entire range of SIP, from p2p to enterprise to large provider 
to closed application provider and so on

   e. multiple open source implementations (two have been pointed out 
already)

   f. an active design team including security experts that helped in 
the massive redesign in -10 to simplify things

And as such, it would seem to me that, not only is there not a single 
shred of evidence that suggests this draft deserves anything less than 
PS, there is evidence only to demonstrate that it has quality far 
greater than most IETF protocols with that moniker.

Other parts of this thread have been folks suggesting alternative 
techniques that are simpler or work better. Well, I look forward to 
their drafts. So far, no one has suggested a single thing which was not 
considered and/or incorporated into ICE in some way over the last four 
years.

ICE was built for reliability - to cover lots of cases and achieve not 
just 90% effectiveness (not nearly good enough), but as effective as is 
possible within the limitations of hurting the Internet or violating 
security policies and other things we won't touch. Without a doubt you 
can design a custom protocol for any one single deployment scenario with 
some set of assumptions that works simpler with fewer messages. However, 
our objective was to design a NAT traversal solution for SIP that 
applied as broadly as SIP did. ICE has the benefit of resulting in 
simple flows in simple topologies, but the same logic produces more 
complex flows in more complex situations, but still works. That was a 
design decision we made years ago and it remains a sound one.

Comments have also been made that, "well, you thought STUN would work 
and you were wrong". This too is bogus. The limitations of STUN were 
known at the time of its publication. It was our hope that enough of a 
market would find it acceptable to be useful. Quoting from RFC 3489:

>  STUN introduces brittleness into the system in several ways:
> 
>    o  The discovery process assumes a certain classification of devices
>       based on their treatment of UDP.  There could be other types of
>       NATs that are deployed that would not fit into one of these molds.
>       Therefore, future NATs may not be properly detected by STUN.  STUN
>       clients (but not servers) would need to change to accommodate
>       that.
> 
>    o  The binding acquisition usage of STUN does not work for all NAT
>       types.  It will work for any application for full cone NATs only.
>       For restricted cone and port restricted cone NAT, it will work for
>       some applications depending on the application. Application
>       specific processing will generally be needed.  For symmetric NATs,
>       the binding acquisition will not yield a usable address.  The
>       tight dependency on the specific type of NAT makes the protocol
>       brittle.
> 
>    o  STUN assumes that the server exists on the public Internet.  If
>       the server is located in another private address realm, the user
>       may or may not be able to use its discovered address to
>       communicate with other users.  There is no way to detect such a
>       condition.
> 
>    o  The bindings allocated from the NAT need to be continuously
>       refreshed.  Since the timeouts for these bindings is very
>       implementation specific, the refresh interval cannot easily be
>       determined.  When the binding is not being actively used to
>       receive traffic, but to wait for an incoming message, the binding
>       refresh will needlessly consume network bandwidth.
> 
>    o  The use of the STUN server as an additional network element
>       introduces another point of potential security attack.  These
>       attacks are largely prevented by the security measures provided by
>       STUN, but not entirely.
> 
> 
> 
> 
> 
> 
> 
> Rosenberg, et al.           Standards Track                    [Page 40]
> 
> RFC 3489                          STUN                        March 2003
> 
> 
>    o  The use of the STUN server as an additional network element
>       introduces another point of failure.  If the client cannot locate
>       a STUN server, or if the server should be unavailable due to
>       failure, the application cannot function.
> 
>    o  The use of STUN to discover address bindings will result in an
>       increase in latency for applications.  For example, a Voice over
>       IP application will see an increase of call setup delays equal to
>       at least one RTT to the STUN server.
> 
>    o  The discovery of binding lifetimes is prone to error.  It assumes
>       that the same lifetime will exist for all bindings. This may not
>       be true if the NAT uses dynamic binding lifetimes to handle
>       overload, or if the NAT itself reboots during the discovery
>       process.
> 
>    o  STUN imposes some restrictions on the network topologies for
>       proper operation.  If client A obtains an address from STUN server
>       X, and sends it to client B, B may not be able to send to A using
>       that IP address.  The address will not work if any of the
>       following is true:
> 
>       -  The STUN server is not in an address realm that is a common
>          ancestor (topologically) of both clients A and B.  For example,
>          consider client A and B, both of which have residential NAT
>          devices.  Both devices connect them to their cable operators,
>          but both clients have different providers. Each provider has a
>          NAT in front of their entire network, connecting it to the
>          public Internet.  If the STUN server used by A is in A's cable
>          operator's network, an address obtained by it will not be
>          usable by B.  The STUN server must be in the network which is a
>          common ancestor to both - in this case, the public Internet.
> 
>       -  The STUN server is in an address realm that is a common
>          ancestor to both clients, but both clients are behind the same
>          NAT connecting to that address realm.  For example, if the two
>          clients in the previous example had the same cable operator,
>          that cable operator had a single NAT connecting their network
>          to the public Internet, and the STUN server was on the public
>          Internet, the address obtained by A would not be usable by B.
>          That is because some NATs will not accept an internal packet
>          sent to a public IP address which is mapped back to an internal
>          address.  To deal with this, additional protocol mechanisms or
>          configuration parameters need to be introduced which detect
>          this case.
> 
> 
> 
> 
> 
> 
> Rosenberg, et al.           Standards Track                    [Page 41]
> 
> RFC 3489                          STUN                        March 2003
> 
> 
>    o  Most significantly, STUN introduces potential security threats
>       which cannot be eliminated.  This specification describes
>       heuristics that can be used to mitigate the problem, but it is
>       provably unsolvable given what STUN is trying to accomplish.
>       These security problems are described fully in Section 12.

Well, the market didn't find it useful enough. And so we worked to 
improve. Nearly every one of these limitations has been eliminated by 
ICE. Go read the IAB considerations section, which discusses this. 
Binding lifetime discovery is pretty much the only remaining one; 
fortunately that is a minor one and ICE is just aggressive in that area 
to compensate. The STUN-control work Dan has been promoting is meant to 
add ontop of ICE to finally close that issue.

So, in case its not abundantly clear, I think there is no merit to the 
calls for changing ICE to informational or experimental, and that these 
last minute claims of better solutions or simpler solutions are also 
without merit. ICE is as deserving, and indeed more so, of a PS moniker 
than most other documents that achieve that label.

-Jonathan R.

David Barrett wrote:
> Hi Cullen, I think you bring up lot of really great and detailed questions.
> 
> However, speaking for myself at least, answering those questions doesn't
> really address my concern.  All I want to know is:
> 
> 	Does ICE work, and how well?
> 
> What "works" means is entirely open to debate.  I've tossed out "high peer
> connectivity" and "low connection setup time" as the most important
> criteria, and I've put hard data behind those numbers as a stake in the
> ground for comparison, but I'm open to other metrics as well.
> 
> But regardless of the metrics, I want somebody who uses it and loves it and
> bases their business upon its success to stand up and explain why it's
> great.  And I want this person to provide real-world data, sampled on a wide
> scale, proving that ICE "works" -- by any definition.
> 
> Basically, I want ICE firmly grounded in wide-scale testing and real-world
> data, and answering the questions below doesn't bring us any closer to that.
> Whether it's level 10 or level 12 doesn't produce new data.  How its
> algorithms differ from competing ones doesn't show that they're any better
> or worse.  Detailed proposals for change don't shed any light on whether
> those changes improve or worsen it, because its current state is completely
> unmeasured.
> 
> The most powerful thing the IETF can do to standardize the world upon ICE is
> prove that it works better than any alternative.  Because until that's
> proven, we just need to take it as a matter of faith.
> 
> -david
> 
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: Wednesday, July 18, 2007 7:56 PM
>> To: SIP; Behave WG; [email-masked]
>> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC
>>
>>
>> First I apologize for the cross post - this is a mmusic draft, I
>> would appreciate replies on the mmusic list only.
>>
>> Few things I am looking for here  ....
>>
>> 1) specific reasons why this work is less appropriate for standards
>> track than other work that IETF puts on the standards track. Keep in
>> mind the first step of standards track is Proposed Standards which
>> requires basically no interoperability, then it could move to Draft
>> Standard where interoperability is shown and finally Full Standard if
>> it turns out to be a good idea.  If you are going to post a reply to
>> this point, make sure you have read RFC 2026.
>>
>> 2) I am interested in the specifics of problems that ICE fails to
>> solve that the WG has not previous considered. There are lots of
>> people that have implemented versions of it and think it is a good
>> idea - if people are having some problems with it, I'd love to hear
>> about details of things that are wrong. That it has a lot of messages
>> in some use cases has been known for a long time. It used to have far
>> more messages  - engineering was done to consider what was a
>> reasonable amount for call set up times and a new design was done to
>> bring the message to a level most people invovled with the design
>> felt was reasonable. If there are specific other than these that are
>> wrong and not considered in the design, now would be a good time to
>> get them on the table.
>>
>> 3) If people think that Skype for example has a simpler solution that
>> works better than ICE. Feel free to describe exactly what it is.
>> Several people invovled with the ICE design have looked in extreme
>> detail at Skype and others and so far none of them have come back
>> with what we should do different than ICE.
>>
>> 4) ICE can be used in a mode where it only provided the reflexive
>> candidate. People were pretty clear that this was far inferior to the
>> modes where there are other candidates. If someone would like to
>> provide exactly how hole punching works better than this very limited
>> ICE technique, I'd be glad to hear the details. This has certainly
>> been an topic that any could have brought up over the last several
>> years. If someone has specifics, I suggest they get out a full
>> proposal really soon. I am very doubtful that hole punching solution
>> is fundamentally different than the type of hole punching ICE does.
>>
>> 5) Some people have suggested that if all NATs were behave complaint,
>> then we would not need ICE. I strongly disagree. I think the only
>> part of ICE we would not need is the TURN relays which are more or
>> less an optional part. Again, specifics on what can be removed are
>> welcome.
>>
>> ICE is far more complicated that anyone wants - the problem is, no
>> one has come up with a proposal that looks like it comes anywhere
>> close to meeting the requirements and if simpler. The design space
>> has been extensively explored by many people. The raw data to
>> understand what will work on what NATs have been painfully tested and
>> documented in publications such as:
>>
>> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf
>>
>> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt
>>
>> https://www.guha.cc/saikat/stunt-results.php?
>>
>> (Ford used to have a page too but it seems to be gone)
>>
>> I have a very open mind to considering better ways to do ICE - but I
>> need specific suggestions or it is impossible for me to really think
>> about if the suggestions represent a better path or not.
>>
>> I would love to see more open source ICE code (there is lots already)
>> - I feel that this is an area where ICE is likely just table stakes
>> and owning an proprietary ICE stack will not turn out to be a
>> competitive advantage. Having open source implementations where the
>> development cost was shared and everyone could get working products
>> to market faster would be an advantage to companies. Clearly I expect
>> the bulk of ICE implementations to not be open source but I still
>> would be keen on doing what I can to contribute to an open source
>> version as personally I feel that is in the interest of end users, my
>> employer, and the IETF as a SDO.
>>
>> Cullen <with my individual hat on>
>>
>>
>>
>> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote:
>>
>>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote:
>>>
>>>> Henry Sinnreich skrev:
>>>>> Following some discussions and soul searching, the best approach for
>>>>> ICE-17 for LC would be to _go ahead and make it an experimental
>>>>> RFC_.
>>>>> This would support the development of interoperable
>>>>> implementations, the
>>>>> collection of deployment data and also hopefully open source code.
>>>>> Though I have full faith in ICE, following the practices that
>>>>> made the
>>>>> IETF successful take precedent here, I believe.
>>>>> This is a change from the attached that I wrote on 7/16/2007.
>>>>> Note: We can only hope the proliferation of SBC in VoIP service
>>>>> provider
>>>>> networks will not make these concerns and ICE for SIP a moot
>>>>> issue, but
>>>>> this is another topic.
>>>> Henry,
>>>>
>>>> I don't quite understand why you are requesting a status change of
>>>> ICE? To me it appears that ICE is almost finished spec. It has
>>>> been implemented, used and feedback has been influencing the
>>>> protocol. It is definitly one of the better examples of current
>>>> IETF work that actually has running code. Sure, the
>>>> implementations may not be fully updated yet to the latest draft
>>>> version. But I think it is safe to say that ICE works in the
>>>> intended core cases. If there are some corner cases where it
>>>> fails, that may be. But that is not information we will have until
>>>> really large scale deployement or someone makes very extensive tests.
>>> Henry has, I believe, been very consistent in urging the IETF to
>>> have more "running code" experience on every specification (not
>>> just ICE) than our process requires. He has, IIRC, also advocated
>>> changing the process to require running code before publishing an
>>> RFC. He's even suggested at times that one should have running code
>>> before submitting a protocol draft.
>>>
>>> Another point to consider -- I've known Henry to bark at a tree
>>> with no squirrel in it occasionally, but most of the time he's
>>> pretty reliable, more so than most technology predictors. If he's
>>> worried about ICE, it's probably because he's been talking to
>>> people who are trying to implement it and they're telling him it is
>>> difficult or that they're having performance or reliability issues.
>>> I imagine that there are plenty of internal development teams in
>>> various companies that are working on this and not necessarily
>>> bringing their results back to the IETF. After all, if everybody
>>> sees the emperor as fully clothed, they'd be embarrassed to
>>> proclaim otherwise. Of course, I wish all of these developers were
>>> tied into the IETF, but then I'm sure I don't want to see every ice-
>>> implementor's question on the SIP list. That is why we have a sip-
>>> implementors mailing list, right?
>>>
>>> Personally, I think ICE is the best solution we have. We KNOW of
>>> cases where hole-punching doesn't work, and I think ICE will
>>> produce usable results in most of those cases. But that's just my
>>> personal opinion from reading the specs. I haven't implemented ICE,
>>> and I haven't used anybody else's implementation. Sure, it's
>>> complex, but that's because the underlying problem is complex --
>>> there are just too many different behaviors out there in "NAT and
>>> firewall land". Of course, I could be wrong, too. It's happened
>>> before, once or twice ;-). Just how sure are we that we're right
>>> about this?
>>>
>>> Are we designing a "spruce goose" or a practical system? Only
>>> experience will tell us. But some good flight reports from the
>>> prototypes could go a long way towards reassuring us of the
>>> design's utility.
>>>
>>> So far we've had a couple of people report hearsay evidence -- that
>>> somebody else has an ICE implementation and it works. Any of you
>>> folks have personal experience you can share? Have there been
>>> prototypes exercised at the interop events?
>>>
>>> --
>>> Dean
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/behave
>>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/behave
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Jul 2007 10:22:40 -0400

On Jul 19, 2007, at 6:15 AM, David Barrett wrote:

> What "works" means is entirely open to debate.
It may have been in the past, but the debate I think is closed,  
because the requirements captured the definition of "works". If you  
want to re-open the requirements discussion, please be clear about that.

> I've tossed out "high peer
See the requirements. One not often mentioned but clearly a  
requirement that ICE works very hard to meet is "use the most direct  
path available".

> great.
> And I want this person to provide real-world data, sampled on a wide
This is in fact an extremely important exercise, and precisely the  
activity which according to RFC2026 is what should be happening after  
approval as proposed standard, and before advancement to  draft  
standard.

> those changes improve or worsen it, because its current state is  
Showing how the algorithms work better, or work in more cases that  
are covered by the requirements does in fact show that it's better,  
with respect to the requirements. Again, you're arguing indirectly  
that we should re-open the requirements discussion, which I do not  
think would be terribly productive, but would support if there is in  
fact consensus to do so.

> proven, we just need to take it as a matter of faith.
I do not think that is desirable. The perfect is the enemy of the  
good. ICE does not have to be better than anything else. It just has  
to be "good enough" and see wide adoption.

That's my 2¢ (as an individual, not as an IAB member, in case anybody  
cares).

DaveO

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 19 Jul 2007 10:00:19 -0500

Is there any reason why ICE-17 deprecates RFC 4091, but not RFC 4092?

I think it should obsolete both, otherwise, it will let people believe
that
ANAT is still alive.

- Francois

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 19 Jul 2007 09:19:07 -0600

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 

FM: While I applaud the time and effort that the large vendors have
obviously invested in this, this is a qualitative statement.  Perhaps Cisco
and/or Microsoft have empirical data they would be willing to share about
robustness and performance?  I don't think anyone here, including myself, is
saying that ICE should not go forward or be used (its ability to handle
hairpinning is of great interest for example), we are asking for evidence
that we're not going to have another 3489 experience if we can avoid it.

FM: I think I missed those, can they be repeated?  The only one I'm aware of
is pjnath and its first release was a little over two months ago and its
based on -15.

Thanks,
FM

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Jul 2007 10:42:18 -0500

On 7/19/07 10:19 AM, Frank W. Miller wrote:
> robustness and performance?

That's the kind of data you get between "proposed standard" and "draft
standard" -- not *prior* to publication. I'm not sure why there's so
much noise about setting the bar much, much higher for ICE than we do
for other IETF proposals.

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.

I think we would all benefit from a quick review of RFC 2026:

>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
>
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.
...
>    Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>    However, since the content of Proposed Standards may be changed if
>    problems are found or better solutions are identified, deploying
>    implementations of such standards into a disruption-sensitive
>    environment is not recommended.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Jul 2007 10:25:32 -0600

> for other IETF proposals.

Yes, it's a puzzle. Perhaps someone could elaborate?

> for the kinds of proof that you and others are demanding.

Agreed.

If the proof is not forthcoming once ICE advances to proposed standard,
then it won't deserve to advance to draft standard. Simple as that.

Let's not forget that RFC standards for "request for comments". :)

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Jul 2007 10:28:47 -0600

> is pjnath and its first release was a little over two months ago and its

http://www1.ietf.org/mail-archive/web/mmusic/current/msg05999.html

/psa

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Jul 2007 10:38:31 -0500

...

/a

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 10:57:23 -0700

> security policies and other things we won't touch.

Just to clarify, the 90% number (which I'm guessing comes from my published
stats) is the success rate of any two peers being able to establish a direct
connection without a relay service.  If I were to add a relay service (which
I don't need for my application, but would be trivial) for the remaining 10%
I hope you agree that near 100% of peers would be able to talk.  (I say
"near" because nothing works at 100% in the real world, no matter how simple
it appears on paper.)  

> several others from outside of it) and deployers (Tim Moore from

Excellent!  Do you or any of your implementor colleagues have any data
showing how well the result works?  Or if not, do you have an active system
that you can instrument to get it?  Or a test implementation that can be
instrumented in the lab?  Or any data at all showing how well ICE works?

I understand we have data about the general NAT penetration techniques,
years of experience, and active security teams.  Does anybody have actual
users, using this on a daily basis on a broad scale, proving that the
product of all this hard work accomplishes its goals?

-david

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 11:01:45 -0700

Actually, I'm not trying to reopen the requirements debate.  I just want ICE
measured against the requirements that were agreed upon.

And I completely agree that perfect is the enemy of the good.  The only ally
of the good is reality, and I want to enlist her on our side.

-david

> From: David R Oran [mailto:[email-masked]]
> Sent: Thursday, July 19, 2007 7:23 AM
> To: David Barrett
> Cc: 'Cullen Jennings'; 'SIP'; 'Behave WG'; [email-masked]

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 11:08:25 -0700

> From: Adam Roach [mailto:[email-masked]]

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.

-da

---

From: Dean Willis <[email-masked]>
Date: Thu, 19 Jul 2007 13:30:50 -0500

> scale, proving that ICE "works" -- by any definition.

I issued a plea a few days ago for similar information.

I didn't get the sort of detail that I wanted, but I was contacted by a
lowly peon at an operator that is using an early ICE implementation for
several million minutes of traffic per day and finds it to be
satisfactory. The lowly peon strongly suggested that an RFC would be
extremely helpful at resolving the one point of dissatisfaction noted --
that everybody seems to have an implementation based on a different
version of the draft, resulting in poor interop.

Unfortunately, said operator has neither publicly confirmed nor denied
this position, nor provided time and performance study numbers.

--
Dean

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Jul 2007 14:37:17 -0400

On 19-Jul-07, at 11:38 , Adam Roach wrote:

> That's the kind of data you get between "proposed standard" and  
> "draft standard" -- not *prior* to publication. I'm not sure why  
> there's so much noise about setting the bar much, much higher for  
> ICE than we do for other IETF proposals.

Just to play the other side of the fence ...
In theory, RFCs advance from "proposed standard" to "draft standard"  
to "full standard".
In practice, this rarely happens.
In practice, once an RFC is published, it is either accepted and  
becomes a de-facto standard, or is ignored. Rarely is it revised and  
advanced along the standards track. And it is often difficult to  
discover which status (de-facto standard or ignored) a particular RFC  
actually has.
Look at SIP, for example. It is still at "proposed standard" and will  
likely stay there for a long time.

What Henry, David, and Frank want is some evidence that actually  
works (and thus will become the de-facto standard) before publishing  
the document as an RFC.

- Philip

---

From: Dean Willis <[email-masked]>
Date: Thu, 19 Jul 2007 13:44:09 -0500

> Yes, it's a puzzle. Perhaps someone could elaborate?

There is a school of thought (which the person who opened this debate
has consistently supported) that says we should have running code to
accompany any protocol draft, and that the process of RFC 2026 is broken
because almost nothing advances beyond proposed standard.

SIP, as an example, is on its second rev as a proposed standard, and
although we've started work to advance it to draft, my money is not on
that happening in my productive lifetime.

And, as we all know, there is ongoing work to replace the process of
2026, and its most commonly anticipated result is likely to be the
elimination of at least one level of standards-track status.

Since it takes two years of WG effort, most of a year of IESG effort,
and another year of RFC Editor effort to cough up an RFC, we end up with
a very high need to get the RFC right the first time.

Personally, I'm wondering if a process like 3GPP's, where we could
revise each RFC every 90 days or so, might not have some major
advantages over the IETF process.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 19 Jul 2007 14:34:06 -0500

> From: Dean Willis [mailto:[email-masked]] 

 [ SNIP ]

> 
> Personally, I'm wondering if a process like 3GPP's, where we 
> could revise each RFC every 90 days or so, might not have 
> some major advantages over the IETF process.
> 

You can do that... Just issue a new WG draft every 90 days or so, and
never promote something to RFC status.

Hey wait, isn't that what we've been doing? :)

ICE-17: July 2007
ICE-16: June 2007
ICE-15: March 2007
ICE-14: March 2007
ICE-13: January 2007
ICE-12: October 2006
ICE-11: October 2006
ICE-10: August 2006
ICE-09: June 2006
ICE-08: March 2006
ICE-07: March 2006
...

I'd put the GRUU revisions up there, but I don't want to be accused of
cross-posting. :P

Regards,
Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Jul 2007 14:37:56 -0500

> elimination of at least one level of standards-track status.

But the process currently stands at what is documented in 2026. Perhaps 
it's broken and needs updating. There are places to make that point, but 
a quick glance at MMUSIC's charter leads me to believe that this isn't 
one of them.

In the interim, _selective_ enforcement of new and undocumented process 
requirements as a means to disrupt publication of a document is, at the 
very least, inequitable. (And even if intentions are other than I imply 
by that statement, _capricious_ enforcement of new and undocumented 
process requirements is equally problematic -- "Standards Calvinball 
[1]" may sound fun at first, but you'll lose workers if the rules are 
too amorphous to know whether their work is actually going anywhere).

I'm not arguing either way whether the IETF publication process needs to 
be changed -- I'm arguing that if and when it changes, it needs to be 
the result of a broad community review, it needs to be documented, and 
it needs to be applied uniformly. And this is far more than an MMUSIC or 
RAI issue. This is an IETF issue.

Followups to IETF-general, please.

/a

[1] http://www.geocities.com/SoHo/Nook/2990/cb_rules.htm

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 20 Jul 2007 19:14:19 -0600

Since it appears that the draft will proceed as planned, I've been going
over -17.  I'd first like to say that I have not read the draft since the
-11 timeframe and its readability has improved dramatically!

My questions so far are:

Section 5.1 talks about what an agent does when it encounters another agent
that is not implementing ICE.  It appears that the agent is supposed to
implement the basic hole-punching algorithm in this case.  Is that the
intent?  If so, should that algorithm be spec'd here or perhaps referred to
in the form of the Ford draft?  I think that there will be forever apps that
do not implement ICE so this may be important.

If dealing with a non-ICE agent, it seems logical to me that the ICE enabled
agent should be able to tell which of its candidate addresses to use but
will that really be the case?  For example, let's assume that an ICE enabled
agent decides to send an offer containing host, server-reflexive, and relay
addresses.  It gets a response back without an ICE lines in the SDP.  Which
address should it proceed with?  Any comment on this?

ICE passes candidates using SDP attribute lines.  Once the checks are
completed, I for one would put the winning address in the Contact header
lines in subsequent messages.  Perhaps this is documented elsewhere but it
might be helpful to implementers to include recommendations on where the
resulting addresses should be used in SIP header lines in Section 12.

I'm sure I'll have more questions later on...

Thanks,
FM