Subject: [Sip] Update of outbound

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Jan 2007 21:41:41 -0800

I just put out an updated version of outbound. Now before you even  
look at it, I did not touch the TCP keep alive. I realize the  
questions of if the TCP keep alive are STUN or Double CRLF is still a  
hot topic. I don't know if it is an open issue or not - I'm working  
with the chairs on trying to figure that out. However, this topic is  
totally orthogonal from all the other issues so I did my best to  
resolve the other issues.

Specifically:

The draft makes it clear that if you can do TCP Keep alive, you can  
use those instead of other Keep alive approaches for TCP.

The draft makes it clear that deployments that want to use only TCP  
can use only TCP and do not not have to do any UDP based outbound  
registrations.

The draft makes it clear that deployments that want to use only UDP  
can use only UDP but that large requests will not work and lots of  
the functional of SIP will not work  If there are drawbacks of using  
UDP that I missed, I am glad to add them.

The draft makes it clear that deployments that want to use both TCP  
and UDP or some combination of them can do that and can use the  
current RFC 3261 message switchover approaches if you have both. If  
future works such as draft-petithuguenin-sip-outbound-fragmentation  
defined some way to dynamical start TCP connections, it would work  
fine with outbound and outbound would not forbid something like that.

Pekka (and others) have been regularly pointing out that for  
standards track documents, the normative statements need to be  
testable for the document to be able to advance. Because of this,  
certain types of normative operational advice need to be done in  
BCPs. The draft has no normative language that would block it from  
moving forward in the standards track but it does have very clear  
operational advice on what the problems of using UDP are.

The draft does not change in 3261 the protocols a UA, Proxy, or  
Registrar need to implement. This would be a very difficult thing for  
us to get consensus on and I see no need to get consensus on a change  
here to move this document forward *soon* in a way that meets  
everyone needs.

Until it shows up in the directory, you can find it at:

http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- 
outbound-07.html
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- 
outbound-07.txt

Now more on the big hot item:

Bit of history on this - we have had this as an open issues slide at  
countless IETF meetings. I thought we had closed it a few meetings  
ago but one of the authors reopened it. Then at a later meeting we  
took a big hum to close it once and for all and it was a the usual  
big room full of people and we had a pretty strong hum towards use  
the same thing for both UDP and TCP.  Then very recently on the list,  
the chairs took a poll on the subject. The poll had very few  
responses but were overwhelming in favor of using CRLF. I counted 12  
people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki, Markus, ALfred,   
Miguel, Hisham, Francois,  Byron, Mac, Fredrik).  Unfortunately, none  
of the people that were proponents of STUN in the wg hum commented on  
the most recent poll.

So where does this leave us. Well luckily for me, it leaves the issue  
firmly in the lap of the chairs to determine consensus and I just  
have to edit the document. My personal view on the topic is that 12  
people is no where near enough to overturn the huge hum however given  
the strong direction of the recent poll, it may however be enough for  
the chairs to decide this is an "Open Issue". If it is an open issue,  
then I suspect the only place to get strong enough consensus to  
overturn the previous hum is in the next WG meeting.  I'll work with  
the chairs in trying to find out what they want to do here.

Cullen <with my outbound editor hat on>

_______________________________________________
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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 08:34:29 +0100

Hi,

Thanks for the draft!

A few comments/questions on chapter 8.

First, the text now says that the edge proxy can indicate support of
keepalive by inserting the parameter e.g. in the Path header. So, maybe
the following text futher down could also be modified:

"For example, automatic or manual configuration of an outbound-proxy-set
which contains the keepalive=stun parameter is
considered sufficient explicit indication."

...would be:

"For example, automatic or manual configuration of an outbound-proxy-set
which contains the keepalive=stun parameter, or the receival of the
parameter in the Path header of the edge proxy, is considered..."

Second, the text says that the explicit indication is needed before any
traffic is sent. I said earlier that one could send the REGISTER before
any STUN is sent. And, if the indication comes in the REGISTER response
the REGISTER has to be sent before. OPTIONS is another example there
"traffic" may be sent before the indication has be retrieved. So, maybe
some clarification text is needed, saying that "STUN traffic" (the way
the text is now written could be understood to also cover SIP traffic)
shall not be sent before the indication has been retrieved.

Regards,

Christer

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 8. tammikuuta 2007 7:42
> To: SIP
> Cc: Rohan Mahy
> Subject: [Sip] Update of outbound
> 
> 
> I just put out an updated version of outbound. Now before you 
> even look at it, I did not touch the TCP keep alive. I 
> realize the questions of if the TCP keep alive are STUN or 
> Double CRLF is still a hot topic. I don't know if it is an 
> open issue or not - I'm working with the chairs on trying to 
> figure that out. However, this topic is totally orthogonal 
> from all the other issues so I did my best to resolve the 
> other issues.
> 
> Specifically:
> 
> The draft makes it clear that if you can do TCP Keep alive, 
> you can use those instead of other Keep alive approaches for TCP.
> 
> The draft makes it clear that deployments that want to use 
> only TCP can use only TCP and do not not have to do any UDP 
> based outbound registrations.
> 
> The draft makes it clear that deployments that want to use 
> only UDP can use only UDP but that large requests will not 
> work and lots of the functional of SIP will not work  If 
> there are drawbacks of using UDP that I missed, I am glad to add them.
> 
> The draft makes it clear that deployments that want to use 
> both TCP and UDP or some combination of them can do that and 
> can use the current RFC 3261 message switchover approaches if 
> you have both. If future works such as 
> draft-petithuguenin-sip-outbound-fragmentation
> defined some way to dynamical start TCP connections, it would 
> work fine with outbound and outbound would not forbid 
> something like that.
> 
> standards track documents, the normative statements need to 
> be testable for the document to be able to advance. Because 
> of this, certain types of normative operational advice need 
> to be done in BCPs. The draft has no normative language that 
> would block it from moving forward in the standards track but 
> it does have very clear operational advice on what the 
> problems of using UDP are.
> 
> The draft does not change in 3261 the protocols a UA, Proxy, 
> or Registrar need to implement. This would be a very 
> difficult thing for us to get consensus on and I see no need 
> to get consensus on a change here to move this document 
> forward *soon* in a way that meets everyone needs.
> 
> Bit of history on this - we have had this as an open issues 
> slide at countless IETF meetings. I thought we had closed it 
> a few meetings ago but one of the authors reopened it. Then 
> at a later meeting we took a big hum to close it once and for 
> all and it was a the usual big room full of people and we had 
> a pretty strong hum towards use the same thing for both UDP 
> and TCP.  Then very recently on the list, the chairs took a 
> poll on the subject. The poll had very few responses but were 
> overwhelming in favor of using CRLF. I counted 12  
> Miguel, Hisham, Francois,  Byron, Mac, Fredrik).  
> Unfortunately, none of the people that were proponents of 
> STUN in the wg hum commented on the most recent poll.
> 
> So where does this leave us. Well luckily for me, it leaves 
> the issue firmly in the lap of the chairs to determine 
> consensus and I just have to edit the document. My personal 
> view on the topic is that 12 people is no where near enough 
> to overturn the huge hum however given the strong direction 
> of the recent poll, it may however be enough for the chairs 
> to decide this is an "Open Issue". If it is an open issue, 
> then I suspect the only place to get strong enough consensus 
> to overturn the previous hum is in the next WG meeting.  I'll 
> work with the chairs in trying to find out what they want to do here.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 8 Jan 2007 13:28:41 +0200

Cullen Jennings writes:

 > I counted 12  

you can add me to that list too (lacking tcp keepalive support in ua tcp
stack).

 > If it is an open issue,  
 > overturn the previous hum is in the next WG meeting.

the mailing list needs to be the authority that determines consensus,
not the meeting that is attended only by those who can afford it.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 13:22:06 +0100

>>I counted 12 people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki, 
>>Markus, ALfred, Miguel, Hisham, Francois,  Byron, Mac, Fredrik). 
> 
>you can add me to that list too (lacking tcp keepalive 
>support in ua tcp stack).
> 
>>If it is an open issue, then I suspect the only place to get strong
enough 
>>consensus to overturn the previous hum is in the next WG meeting.
> 
>the mailing list needs to be the authority that determines 
>consensus, not the meeting that is attended only by those who 
>can afford it.

Well, then we don't need any hums in the future, do we? :)

Seriously, I do agree, but I (and I am sure others too) have received
comments saying that "there was a concensus in this-or-that IETF
meeting", without the issue really even being discussed on the mailing
list. In some cases things have been discussed on the list, and have
even got some support, but then being turned down at the meeting.

So, does that mean that all decissions made at meetings should be agreed
also on the list after that?

Regards,

Christer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 9 Jan 2007 04:08:09 +0800

From: "Christer Holmberg (JO/LMF)" <[email-masked]>

"So, does that mean that all decissions made at meetings should be agreed 
also on the list after that?"

Yes, precisely. This is required in our WG BCP, RFC 2418. Scott Bradner 
graciously pointed me to

3.2. Session venue

   Each working group will determine the balance of email and face-to-
   face sessions that is appropriate for achieving its milestones.
   Electronic mail permits the widest participation; face-to-face
   meetings often permit better focus and therefore can be more
   efficient for reaching a consensus among a core of the working group
   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
-> participants.  Decisions reached during a face-to-face meeting about
-> topics or issues which have not been discussed on the mailing list,
-> or are significantly different from previously arrived mailing list
-> consensus MUST be reviewed on the mailing list.

The last sentence is the relevant part.

Thanks, Scott, for helping me find this during jet lag!

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Jan 2007 11:25:08 -0800

I think that chairs need to combine the input they receive in a  
meeting hum with the input they get on the list. Chairs are given  
pretty broad discretion in how they determine consensus but they  
certainly needs to be taking into account any input from the list.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Jan 2007 11:38:56 -0800

> parameter in the Path header of the edge proxy, is considered..."

works for me.

> shall not be sent before the indication has been retrieved.

Yep - I think that everyone meant what you are saying and we just  
typed it up wrong.

I will change this to say "STUN traffic".