Subject: Re: Last Call: <draft-ietf-sipcore-199-05.txt> (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard

From: Cullen Jennings <[email-masked]>
Date: Mon, 7 Feb 2011 11:44:50 -0700

I was somewhat surprised to see this back in LC. I am still not aware of any use case where this actually helps. I searched the IETF and WG lists for email with the subject draft-ietf-sipcore-199 and I do not see a single email that suggests there is support for this draft or the changes in it since the previous LC. 

This draft has no use that I understand how it helps - it is at best a very limited optimization. The SIP standards is already too complicated with too many extensions. I believe this draft makes SIP worse.Thought the draft mandates that systems need to work even when the 199 are lost, I do not think that is how the proponents of the work intent to use. I could be very wrong but I presume that people intent to use to control middle boxes that control media gates. It's broken for that but given that is not discussed in the draft, it's hard to discuss how it is broken and what would be needed to fix it. 

I do not support publishing this draft as standards track without actual WG discussion on what the problem is this draft solves and if there is WG consensus that problem is worth solving.  

On Feb 7, 2011, at 10:02 AM, The IESG wrote:

> The IESG has received a request from the Session Initiation Protocol Core
> WG (sipcore) to consider the following document:
> - 'Session Initiation Protocol (SIP) Response Code for Indication of
>   Terminated Dialog'
>  <draft-ietf-sipcore-199-05.txt> as a Proposed Standard
> 
> This is the second IETF last call for this document. The previous last call was on version -02.
> While resolving review comments, an issue with the interaction of the 199 response and the
> 100rel extension was identified and addressed by the SIPCORE working group. A full summary
> of the changes are available in section 13 of the document.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-02-21. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>   This specification defines a new Session Initiation Protocol (SIP)
>   response code, 199 Early Dialog Terminated, that a SIP forking proxy
>   and a User Agent Server (UAS) can use to indicate towards upstream
>   SIP entities (including the User Agent Client (UAC)) that an early
>   dialog has been terminated, before a final response is sent towards
>   the SIP entities.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Adam Roach <[email-masked]>
Date: Mon, 07 Feb 2011 15:01:53 -0600

> I do not support publishing this draft as standards track without actual WG discussion on what the problem is this draft solves and if there is WG consensus that problem is worth solving.

Cullen:

Speaking as a chair of SIPCORE, I would like to clarify a minor point. 
Although it may not have been your intention, your message can be read 
as implying that the SIPCORE chairs and/or the RAI area directors have 
decided to move this document forward without community input.

For the benefit of those on this mailing list who were not involved in 
the earlier stages of this document's progress: the initial community 
input on whether to pursue the problem solved by this draft was taken at 
the face-to-face SIPPING meeting during IETF 69. In particular, the 
minutes for that meeting reflect: "Hum... in support of working on this 
problem."

In April of 2008, the requirements document was handed over from SIPPING 
to the SIP working group for working on actual protocol mechanism. (The 
SIP change process at the time limited core protocol changes to the SIP 
working group, requiring a change in venue).

Within the SIP working group, there were at least 316 message in 38 
different threads on the protocol document over the one year period 
spanning April 2008 to April 2009. This period included a two-week long 
Working Group Last Call period in November of 2008.

In April of 2009, the RAI area underwent a reorganization, which 
resulted in the conclusion of the SIP working group. As part of the 
chartering of the SIPCORE working group, this document (and its 
associated milestone) was transferred to the SIPCORE WG.

In January of 2010, the document entered IETF last call for the first 
time. During IETF balloting, certain issues were identified by the IESG, 
and balloted as a "DISCUSS" position. Over the course of 2010, the 
document's author worked with the RAI ADs to address these issues to the 
satisfaction of the currently seated IESG. As a result of these 
conversations, a technical issue involving interaction with another SIP 
extension mechanism was identified, and brought back to the SIPCORE 
working group. A resolution to the issue was identified in early 
December 2010, and a revised version of the document was produced to 
reflect this resolution.

At every step of this process, the IETF, RAI, and SIP community has 
opportunity for involvement. The volume of discussion demonstrates a 
non-trivial interest in this mechanism.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Feb 2011 08:04:53 +0100

Cullen,

When we last talked, you said that your main is the fact that unreliable responses might be sent even in the case of Require:100rel. That has now been solved, so I am very surprised by your comments.

Also, the draft WAS back in the WG when the proposed solution was presented. Why didn't you say anything then????

Regarding the usage, I have been provided text (mostly by Robert) regarding the usability, limitations etc. Why haven't you said anything before if you didn't like it????

Regards,

Christer 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: 7. helmikuuta 2011 20:45
> To: IESG IESG; [email-masked] IETF
> Subject: Re: Last Call: <draft-ietf-sipcore-199-05.txt> 
> (Session Initiation Protocol (SIP) Response Code for 
> Indication of Terminated Dialog) to Proposed Standard
> 
> 
> I was somewhat surprised to see this back in LC. I am still 
> not aware of any use case where this actually helps. I 
> searched the IETF and WG lists for email with the subject 
> draft-ietf-sipcore-199 and I do not see a single email that 
> suggests there is support for this draft or the changes in it 
> since the previous LC. 
> 
> This draft has no use that I understand how it helps - it is 
> at best a very limited optimization. The SIP standards is 
> already too complicated with too many extensions. I believe 
> this draft makes SIP worse.Thought the draft mandates that 
> systems need to work even when the 199 are lost, I do not 
> think that is how the proponents of the work intent to use. I 
> could be very wrong but I presume that people intent to use 
> to control middle boxes that control media gates. It's broken 
> for that but given that is not discussed in the draft, it's 
> hard to discuss how it is broken and what would be needed to fix it. 
> 
> I do not support publishing this draft as standards track 
> without actual WG discussion on what the problem is this 
> draft solves and if there is WG consensus that problem is 
> worth solving.  
> 
> 
> > The IESG has received a request from the Session Initiation 
> Protocol 
> > Core WG (sipcore) to consider the following document:
> > While resolving review comments, an issue with the 
> interaction of the 
> > 199 response and the 100rel extension was identified and 
> addressed by 
> > the SIPCORE working group. A full summary of the changes 
> are available in section 13 of the document.
> > 
> > [email-masked] mailing lists by 2011-02-21. Exceptionally, 
> comments may 
> > be sent to [email-masked] instead. In either case, please retain the 
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 8 Feb 2011 17:19:09 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]

I am still not aware of any use case where this actually helps. I searched the IETF and WG lists for email with the subject draft-ietf-sipcore-199 and I do not see a single email that suggests there is support for this draft or the changes in it since the previous LC.
_______________________________________________

I recall discussing the utility of 199 at one of the IETF meetings.  Indeed, I pushed Christer rather hard on the subject.  The primary use is situations where the SIP UAC is a gateway and has to allocate audio processors to each early dialog; 199 gives the downstream elements the ability to release the allocated processors when an early dialog ends, even though the UAC will not see the failure response for some time.

Since then, the proposal has gone through a number of changes that increase its value.  E.g., clarification of how it interacts with 100rel processing, ensuring it works correctly when non-199-aware SIP elements are present, providing warnings against likely errors by implementors, and allowing UACs to generate 199s on their own behalf.  (That latter is significant in the SIP environments I work with, as we put more responsibility on the UAs and make the proxies stateless.)

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 28 Feb 2011 10:27:10 -0700

On Feb 7, 2011, at 2:01 PM, Adam Roach wrote:

> Speaking as a chair of SIPCORE, I would like to clarify a minor point. Although it may not have been your intention, your message can be read as implying that the SIPCORE chairs and/or the RAI area directors have decided to move this document forward without community input.

It was really just sloppy overly fast writing on my part - I did not mean to imply that. The total time I'm willing to spend on this draft is pretty minimal.

> 
> For the benefit of those on this mailing list who were not involved in the earlier stages of this document's progress: the initial community input on whether to pursue the problem solved by this draft was taken at the face-to-face SIPPING meeting during IETF 69. In particular, the minutes for that meeting reflect: "Hum... in support of working on this problem."
> 
> In April of 2008, the requirements document was handed over from SIPPING to the SIP working group for working on actual protocol mechanism. (The SIP change process at the time limited core protocol changes to the SIP working group, requiring a change in venue).
> 
> Within the SIP working group, there were at least 316 message in 38 different threads on the protocol document over the one year period spanning April 2008 to April 2009. This period included a two-week long Working Group Last Call period in November of 2008.
> 
> In April of 2009, the RAI area underwent a reorganization, which resulted in the conclusion of the SIP working group. As part of the chartering of the SIPCORE working group, this document (and its associated milestone) was transferred to the SIPCORE WG.
> 
> In January of 2010, the document entered IETF last call for the first time. During IETF balloting, certain issues were identified by the IESG, and balloted as a "DISCUSS" position. Over the course of 2010, the document's author worked with the RAI ADs to address these issues to the satisfaction of the currently seated IESG.

 I thought we were still in middle on conversation about what to do about any this stuff - thus my surprise it was in LC again. Last email I had was you in May of asking Christer if he was going to reply. He eventual did but it did resolve what this was use for. It did point out that no one was complaining about it. That caused me to send an email in June that said 

"Silence is not consent - the WG does not care about this and there is not consensus that it is useful, what it is useful for, or that it should be published. I'd be happy to shown to be wrong as I, like I suspect many others, don't care too much one way or the other. "

After that, other than people saying the IETF had to do this because 3GPP had already made it mandatory, I had not heard any more about it. 

> As a result of these conversations, a technical issue involving interaction with another SIP extension mechanism was identified, and brought back to the SIPCORE working group. A resolution to the issue was identified in early December 2010, and a revised version of the document was produced to reflect this resolution.

Uh, you mean the one where the total traffic seems to be 

Chair (Paul) proposed the WG should see if the WG was OK with it
Christer (Author) said he was OK with even though he did not really like it
Keith proposed some text without saying if he actually liked any of it or not 
Christer (Author) said he was OK with it 

And no one else said anything. Hopefully I failed to find the email, or lost it, or am just confused, but I have a hard time imaging how that looks like consensus in one of the largest WG in the IETF. 

> 
> At every step of this process, the IETF, RAI, and SIP community has opportunity for involvement. The volume of discussion demonstrates a non-trivial interest in this mechanism.

Hmm ... I 100% agree there has been opportunity for involvement. I am talking about the actually involvement since the previous LC over a year ago. In that year, there looks to be mostly silence about any of the issues or changes to the draft. I did not go do a good search but when I searched for the draft name, I'm not seeing much discussion. If you tell me 10 people were actively engaged in the last year and support these changes, I'm happy to agree I am in the rough in the consensus and ignore the whole thing. But if you are telling me that no one objected, then I do not believe silence is the same as consensus. 

> /a

Anyways - I this is very much on my low priority list - I have not gone back and looked carefully at the previous discussions.

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Feb 2011 13:32:43 -0600

On 2/28/11 11:27 AM, Cullen Jennings wrote:
> Hmm ... I 100% agree there has been opportunity for involvement. I am 
> talking about the actually involvement since the previous LC over a 
> year ago.

I would imagine that actual working group involvement on any draft after 
IETF last call generally approaches zero. I believe this document is 
rather average in that regard.

> In that year, there looks to be mostly silence about any of the issues 
> or changes to the draft. I did not go do a good search but when I 
> searched for the draft name, I'm not seeing much discussion. If you 
> tell me 10 people were actively engaged in the last year and support 
> these changes, I'm happy to agree I am in the rough in the consensus 
> and ignore the whole thing. But if you are telling me that no one 
> objected, then I do not believe silence is the same as consensus.
>

I'm not trying to tell you that silence is consensus. In this case, 
silence simply indicates that the working group thinks it is finished, 
and hasn't elected to spend additional work on a completed item.

It's my experience that working groups do not generally work on 
documents after they have been passed off to the IESG for publication. 
This document has been in front of the IESG for the past year that you 
reference. The only mailing list traffic that the working group could 
have generated after publication was requested would have been cheering 
from the sidelines, which isn't part of the publication process as I 
understand it.

So, while your request for 10 people who have expressed interest on the 
list list after IETF last call makes no sense, I *can* offer you the 
following list of 35 people who participated in mailing list discussions 
while the draft was still in a working group:

Adam Roach <[email-masked]>
Anders Kristensen <[email-masked]>
Ashish Hsaxena <[email-masked]>
Attila Sipos <[email-masked]>
Avasarala Ranjit <[email-masked]>
Bob Penfield <[email-masked]>
Brett Tate <[email-masked]>
Christer Holmberg <[email-masked]>
Cullen Jennings <[email-masked]>
Dale Worley <[email-masked]>
Dean Willis <[email-masked]>
Eric Rescorla <[email-masked]>
Eric Wang <[email-masked]>
Francois Audet <[email-masked]>
Hadriel Kaplan <[email-masked]>
Hans Erik van Elburg <[email-masked]>
Ian Elz <[email-masked]>
Jeroen van Bemmel <[email-masked]>
John Elwell <[email-masked]>
Juha Heinanen <[email-masked]>
Keith Drage <[email-masked]>
Martin Dolly <[email-masked]>
Paul Kyzivat <[email-masked]>
Robert Sparks <[email-masked]>
Rockson Li <[email-masked]>
Sanjay Sinha <[email-masked]>
Serhad Doken <[email-masked]>
Spencer Dawkins <[email-masked]>
Sreeram Kanumuri <[email-masked]>
Sreerekha Shenoy <[email-masked]>
Timothy M Dwight <[email-masked]>
Tom Taylor <[email-masked]>
Vijay K. Gurbani <[email-masked]>
Vikram Chhibber <[email-masked]>
Ya Ching Tan <[email-masked]>

/a