Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
draft-ietf-sipcore-199-06

[Ballot comment]
I agree that Experimental for this document is going to be better.


I don't think the document is doing a very good job convincing readers about utility of this mechanism. At least not until it starts describing detailed use cases.


4.1.  Examples of resource types

  NOTE: When using SRTP [RFC3711], the secure media stream is bound to
  the crypto context setup for the dialog, and can be identified using
  the MKI (if used) of SRTP.

Please expand the acronym on first use.

  If the client only has a single early dialog (other early dialogs MAY
  not have been established, or they MAY have been established and

It doesn't look like use of these 2 MAYs is correct - they don't describe requirements.

  later terminated) and a 199 response is received for that early
  dialog, the client terminates the early dialog.  Afterwards, the
  client SHOULD act as before the first early dialog was established.


4.2.  Examples of policy procedures

  2.  SBC early media selection - when an SBC is used to control which

Please expand the acronym on first use.

  media is processed and forwarded.  In many cases, the SBC only
  processes media associated with a single early dialog.  Typical for
  NAT traversal, the SBC often "latches" onto a media stream.  If a 199
  response is received, the SBC can choose to start processing media
  associated with another dialog.  If the SBC performs latching, it can
  trigger a "re-latch" onto a new media stream when the 199 response is
  received.

[Ballot comment]
#1) Sec 1: Can you provide an example of policy related decision?

  In addition, SIP entities might also use the 199 response to make
  policy related decisions related to early dialogs.

#2) Sec 5: This is a little hard to parse (it's all one sentence):

  If a UAS receives an initial dialog initiation request, with a
  Supported header field that contains a "199" option-tag, it SHOULD
  NOT send a 199 response on an early dialog associated with the
  request, before it sends a non-2xx final response, unless it e.g. has
  been configured to do so due to lack of support of the 199 response
  code by forking proxies or other intermediate SIP entities, or it is
  used in an environment that specifies that it shall send a 199
  response before sending a non-2xx response.

#3) I'm trying to reconcile the statement in the 2nd to last para of Sec 5, which says that the 199 is only for informational purposes, with the MUST NOT In the last paragraph.  If it's informational then why is it a MUST NOT?

[Ballot comment]
#1) Sec 1: Can you provide an example of policy related decision?

  In addition, SIP entities might also use the 199 response to make
  policy related decisions related to early dialogs.

#2) Sec 5: This is a little hard to parse (it's all one sentence):

  If a UAS receives an initial dialog initiation request, with a
  Supported header field that contains a "199" option-tag, it SHOULD
  NOT send a 199 response on an early dialog associated with the
  request, before it sends a non-2xx final response, unless it e.g. has
  been configured to do so due to lack of support of the 199 response
  code by forking proxies or other intermediate SIP entities, or it is
  used in an environment that specifies that it shall send a 199
  response before sending a non-2xx response.

#3)

[Ballot comment]
The introduction is difficult to understand. It would be helpful to provide a picture of the scenario that motivates this document, or at least to provide a forward reference to the "swim lane" diagrams in Section 9.

IANA understands that, upon approval of this document, there are two
IANA Actions that must be completed.

First, in the SIP response code registry located in the SIP Parameters
registry at:

http://www.iana.org/assignments/sip-parameters

a new response code will be registered as follows:

Response Code Number: 199

Default Reason Phrase: Early Dialog Terminated

Reference: [ RFC-to-be ]

Second, in the SIP option-tag registry located in the SIP Parameters
registry at:

http://www.iana.org/assignments/sip-parameters

a new option-tag will be registered as follows:

option-tag: 199

Description: This option-tag is for indicating support of the 199 Early
Dialog Terminated provisional response code. When present in a Supported
header of a request, it indicates that the UAC supports the 199 response
code. When present in a Require or Proxy-Require header field of a
request, it indicates that the UAS, or proxies, MUST support the 199
response code. It does not require the UAS, or proxies, to actually send
199 responses.

Reference: [ RFC-to-be ]

IANA understands that these actions are the only ones that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard

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'
  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
ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be
sent to iesg@ietf.org 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/

[Ballot discuss]
----Adopting Cullen Jennings' discuss---
The draft needs to be explicitly clear about what
conditions it helps in. The current text is not clear
enough given that many people end up debating it and or
confused. I think this is just a matter of getting more
explicitly about these points and deleting any ones where
it is not clear exactly what cases it helps in. We just
need to get these to the point where it is clear that they
are factually correct.


1.  Codec release - when resources for a specific codec has
been reserved only for the stream that is terminated.  In
that case the resources associated with that codec can be
released.

I don't understand what resource is released. On some very
old large gateways that loaded codecs into the DSP du to
DSP memory limitations, I understand what codec released
means but that does not make sense in this context. Please
explain in email what gets released and in what real world
scenarios this occurs then we can sort out what the draft
needs to say. I obviously consider mobile batter operated
devices over wireless to be very important use cases.

2.  Pre-conditions - when the dialog is terminated,
procedures and resources associated to the pre-conditions
for that dialog can be released.

Please clarify this to around the allocated bandwidth. I
would also like to understand in what real world scenarios
this is going to result in additional dialogs being set up
once the bandwidth becomes available. You need to walk me
through a scenario of how this is going to work.

3.  In-band security negotiation - when the dialog is
terminated, procedures and resources associated with the
in-band security negotiation for that dialog can be
released.

Ditto on this.

You wrote "[Christer] Whatever procedures takes place on
the media plane in order to establish the security
associated, and resources reserved in order to deal
(encrypt/decrypt) with the secure media itself." I still
don't understand what resources. Jari said that if a slow
UA was still trying to set up a security associations by
the time the 199 arrived, this could allow it to stop that
and it might take a long time due to CPU speed and doing
PKi computations.  If this is what you mean, I'd be
interested in understanding when that might happen. It does
make sense but I don't understand when it would occur.

4.  ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog
is terminated, procedures and resources associated with the
ICE related in-band procedures for that dialog can be
released.

In email you mentioned that it is the sending of keep
alives that can be stopped. This is a good answer and makes
sense. Can you update the text to say that and also mention
how frequently they are sent and what sort of scenarios
benefit from this optimization.

5.  Limited access resources - in case of forking and
multiple stream it may not be possible to allow early media
on all dialogs, so media sessions associated with some
dialogs may e.g. be set to "inactive".  When a dialog is
terminated, media sessions associated with other dialogs
can be allowed.

From email "[Christer] The probably most common scenario is
when an application server in the network creates an early
dialog with the UA in order to send an announcement, while
the INVITE is forwarded towards the remote UA(s). There are
specified procedures (in TISPAN and 3GPP) where this occur,
and I believe this mechanism has also been discussed on the
IETF SIP lists."

Can you help educate me about theses a bit more. The ones I
saw before involved the announcement finishing before the
PSTN got the call.

  6.  Secure media selection - when SRTP is used to encrypt
the media.

I'm still not following what this allows that would not be
otherwise possible without the 199. I did read the Note
about SRTP.

I'm not understanding why 199 allows the SBC to do
something it can not do today in the section where latching
is discussed.  Typically "Latching" in SBC is not at all
what you describe here. It is the process by which an SBC
decide to send RTP to a IP address that is different than
what is in the SDP. Can walk me through in email what is
going on propose some text.

In  the case of early ring tone termination where say a
PSTN gateway roles over to voicemail, I don't see who this
will accelerate the move in any useful way from the PSTN
ringback tone to the voicemail server media.

I see no reason to allow this in a Require or proxy-Require
and think that should be a MUST NOT. As you can tell, I
think the value of this draft is somewhat limited but I am
OK with publishing it as long as it does no harm. I view
adding a require or proxy-require as something that would
reduce interoperability of SIP call in a significant way
and thus be harmful. I am very unlikely to be convinced to
change my position on this one but I would be happy to hear
concrete reasons why this needs to be a SHOULD.

It's unclear to me what Reason code to insert or why this
is a MUST. The reason code seems non necessary for the
describes uses of this mechanism. I read your email and it
did not help me understand why the Reason was mandated.
Mandating things that are not needed and can be separated
seldom turns out to be good [as you rightly pointed out in
putting the keep-alives in the same draft as rest of
outbound]. Unless there is a compelling technical reason
for this we should not do it.

The actual specification of how you deal with SDP in a 199
containing an offer is probably all correct in the draft
but it is very difficult to understand the logic that lead
to this and what one is supposed to do. Could you rephrase
it be clear on exactly how this interacts with invites with
no offer and explain why it needs to work the way it does.

The not sending things reliably that have a Require: 100rel
seems like it will break some IDS, firewalls, and middles
boxes that are expecting any 1xx to reliable since that was
signaled. I'd like to see text that helped explain this.
I'm not asking you to change this - I am asking to discuss
and point out the implications of if.

I would like to see it very clear in the document at if you
receive SDP in a 199, the UA MUST ceases sending all media
on the RTP streams associated with that dialog. I would not
want this to be used in an attack where one could send an
an authenticated 199 and cause devices to star sending
media to random 3rd parties that showed up in the SDP.

[Ballot discuss]
The draft needs to be explicitly clear about what conditions it helps in. The current text is not clear enough given that many people end up debating it and or confused. I think this is just a matter of getting more explicitly about these points and deleting any ones where it is not clear exactly what cases it  helps in. We just need to get these to the point where it is clear that they are factually correct.


1.  Codec release - when resources for a specific codec has been
  reserved only for the stream that is terminated.  In that case the
  resources associated with that codec can be released.

I don't understand what resource is released. On some very old large gateways that loaded codecs into the DSP du to DSP memory limitations, I understand what codec released means but that does not make sense in this context. Please explain in email what gets released and in what real world scenarios this occurs then we can sort out what the draft needs to say. I obviously consider mobile batter operated devices over wireless to be very important use cases.

  2.  Pre-conditions - when the dialog is terminated, procedures and
  resources associated to the pre-conditions for that dialog can be
  released.

Please clarify this to around the allocated bandwidth. I would also like to understand in what real world scenarios this is going to result in additional dialogs being set up once the bandwidth becomes available. You need to walk me through a scenario of how this is going to work.

  3.  In-band security negotiation - when the dialog is terminated,
  procedures and resources associated with the in-band security
  negotiation for that dialog can be released.

Ditto on this.

You wrote "[Christer] Whatever procedures takes place on the media plane in order to establish the security associated, and resources reserved in order to deal (encrypt/decrypt) with the secure media itself." I still don't understand what resources. Jari said that if a slow UA was still trying to set up a security associations by the time the 199 arrived, this could allow it to stop that and it might take a long time due to CPU speed and doing PKi computations. If this is what you mean, I'd be interested in understanding when that might happen. It does make sense but I don't understand when it would occur. 

  4.  ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
  terminated, procedures and resources associated with the ICE related
  in-band procedures for that dialog can be released.

In email you mentioned that it is the sending of keep alives that can be stopped. This is a good answer and makes sense. Can you update the text to say that and also mention how frequently they are sent and what sort of scenarios benefit from this optimization.

  5.  Limited access resources - in case of forking and multiple stream
  it may not be possible to allow early media on all dialogs, so media
  sessions associated with some dialogs may e.g. be set to "inactive".
  When a dialog is terminated, media sessions associated with other
  dialogs can be allowed.

From email "[Christer] The probably most common scenario is when an application server in the network creates an early dialog with the UA in order to send an announcement, while the INVITE is forwarded towards the remote UA(s). There are specified procedures (in TISPAN and 3GPP) where this occur, and I believe this mechanism has also been discussed on the IETF SIP lists."

Can you help educate me about theses a bit more. The ones I saw before involved the announcement finishing before the PSTN got the call.

  6.  Secure media selection - when SRTP is used to encrypt the media.

I'm still not following what this allows that would not be otherwise possible without the 199. I did read the Note about SRTP.

I'm not understanding why 199 allows the SBC to do something it can not do today in the section where latching is discussed.  Typically "Latching" in SBC is not at all what you describe here. It is the process by which an SBC decide to send RTP to a IP address that is different than what is in the SDP. Can walk me through in email what is going on propose some text.

In  the case of early ring tone termination where say a PSTN gateway roles over to voicemail, I don't see who this will accelerate the move in any useful way from the PSTN ringback tone to the voicemail server media.


I see no reason to allow this in a Require or proxy-Require and think that should be a MUST NOT. As you can tell, I think the value of this draft is somewhat limited but I am OK with publishing it as long as it does no harm. I view adding a require or proxy-require as something that would reduce interoperability of SIP call in a significant way and thus be harmful. I am very unlikely to be convinced to change my position on this one but I would be happy to hear concrete reasons why this needs to be a SHOULD.


It's unclear to me what Reason code to insert or why this is a MUST. The reason code seems non necessary for the describes uses of this mechanism. I read your email and it did not help me understand why the Reason was mandated. Mandating things that are not needed and can be separated seldom turns out to be good [as you rightly pointed out in putting the keep-alives in the same draft as rest of outbound]. Unless there is a compelling technical reason for this we should not do it.

The actual specification of how you deal with SDP in a 199 containing an offer  is probably all correct in the draft but it is very difficult to understand the logic that lead to this and what one is supposed to do. Could you rephrase it be clear on exactly how this interacts with invites with no offer and explain why it needs to work the way it does.

The not sending things reliably that have a Require: 100rel seems like it will break some IDS, firewalls, and middles boxes that are expecting any 1xx to reliable since that was signaled. I'd like to see text that helped explain this. I'm not asking you to change this - I am asking to discuss and point out the implications of if.

I would like to see it very clear in the document at if you receive SDP in a 199, the UA MUST ceases sending all media on the RTP streams associated with that dialog. I would not want this to be used in an attack where one could send an an authenticated 199 and cause devices to star sending media to random 3rd parties that showed up in the SDP.

I imagine more than one of these thing may just be talking past each other so I'm glad to have a phone call if that helps clear any of this up. I'm sure some rounds of email will be needed.

[Ballot comment]
I agree that Experimental for this document is going to be better.


I don't think the document is doing a very good job convincing readers about utility of this mechanism. At least not until it starts describing detailed use cases.


4.1.  Examples of resource types

  NOTE: When using SRTP [RFC3711], the secure media stream is bound to
  the crypto context setup for the dialog, and can be identified using
  the MKI (if used) of SRTP.

Please expand the acronym on first use.

  If the client only has a single early dialog (other early dialogs MAY
  not have been established, or they MAY have been established and

It doesn't look like use of these 2 MAYs is correct - they don't describe requirements.

  later terminated) and a 199 response is received for that early
  dialog, the client terminates the early dialog.  Afterwards, the
  client SHOULD act as before the first early dialog was established.


4.2.  Examples of policy procedures

  2.  SBC early media selection - when an SBC is used to control which

Please expand the acronym on first use.

  media is processed and forwarded.  In many cases, the SBC only
  processes media associated with a single early dialog.  Typical for
  NAT traversal, the SBC often "latches" onto a media stream.  If a 199
  response is received, the SBC can choose to start processing media
  associated with another dialog.  If the SBC performs latching, it can
  trigger a "re-latch" onto a new media stream when the 199 response is
  received.

14.1.  Normative References

  [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

  [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

  [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

I think the above references are Informative.

[Ballot discuss]
Discuss:

This draft has been discussed in many many WG meetings. Most people gave up and stopped commenting on it. I do not believe that further working group discussion will result in any substantial improvements. That said, the draft is not very useful and has many problems. I would not object to it moving forward as Experimental. I have substantial issues with it as a PS draft.


The draft lists several reasons that it is useful. I disagree with every single one of them. (note none of these objections are new, they have all been pointed out in the WG)

1.  Codec release - when resources for a specific codec has been
  reserved only for the stream that is terminated.  In that case the
  resources associated with that codec can be released.

No, lets say that I have loaded iLBC into the DSP and put it in the offer, just because one dialog that was using iLBC terminates does not mean I can unload it. It's still int eh SIP offer and I have to accept RTP with that codec.

  2.  Pre-conditions - when the dialog is terminated, procedures and
  resources associated to the pre-conditions for that dialog can be
  released.

What resources exactly and how will this help, It's not like I can release one set of bandwidth before the next allocation comes. This only causes the return to happen a matter of seconds sooner. I'm unconvinced this offers any compelling value.

  3.  In-band security negotiation - when the dialog is terminated,
  procedures and resources associated with the in-band security
  negotiation for that dialog can be released.

What resources?

  4.  ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
  terminated, procedures and resources associated with the ICE related
  in-band procedures for that dialog can be released.

No, the candidates are still in the offer and need to remain valid. I don't really know what resources this means

  5.  Limited access resources - in case of forking and multiple stream
  it may not be possible to allow early media on all dialogs, so media
  sessions associated with some dialogs may e.g. be set to "inactive".
  When a dialog is terminated, media sessions associated with other
  dialogs can be allowed.

Remind me of a practical scenario where multiple entities on the dialog will be sending simultaneously early mead. I agree it can happen but it is not at all clear to me why any of them would terminate the dialing.


  6.  Secure media selection - when SRTP is used to encrypt the media.

I have no idea what this means. You talking about a few bytes of a MKI mapping to crypto context ?

"Latching" in SBC is not at all what you describe here. It is the process by which an SBC decide to send RTP to a IP address that is different than what is in the SDP.

In  the case of early ring tone termination where say a PSTN gateway roles over to voicemail, I don't see who this will accelerate the move in any useful way from the PSTN ringback tone to the voicemail server media.


I see no reason to allow this in a Require or proxy-Require and think that should be a MUST NOT.

It's unclear to me what Reason code to insert or why this is a MUST. The reason code seems useless for the alleged uses of this mechanism.

The 199 SHOULD/NOT have SDP, please help me understand when it is OK to do that. Actually probably need to understand when it is OK to violate just about every SHOULD in the document.

The handling of an INVITE without an offer looks somewhat broken. I Sending an offer with empty m-lines is not going to cause the call to fail with plenty of 3261 compliant equipment. You need to fix this. I have no idea how to fix it.

You say when a proxy receives an out of dialog 199, it processes it normal. How exactly is that? If the answer is it forwards it in a stateless way I think this is a big security problem as I can use that get random people to redirect their RTP streams to perform DOS attacks.

I could be confused but it looks like section 8 contradicts section 5 on what a UAS does to send responses containing an offer.

The not sending things reliably that have a Require: 100rel seems like it will break cretin IDS, firewalls, and middles boxes.


The security considerations section ill be pretty useless for any implementor.

I support the point Sam Weiler made of
I'm also a little worried about the implications of one party or
another trying to continue the dialog, perhaps maliciously, after
sending or receiving one of these.  What if one of these were used to
disable a monitoring or billing system, but the parties continued to
use the open session?  (Compare to sending a weak C-tone on a
wiretapped PSTN line.)

[Ballot discuss]
This draft has been discussed in many many WG meetings. Most people gave up and stopped commenting on it. I do not believe that further working group discussion will result in any substantial improvements. That said, the draft is not very useful and has many problems. I would not object to it moving forward as Experimental. I have substantial issues with it as a PS draft.


The draft lists several reasons that it is useful. I disagree with every single one of them. (note none of these objections are new, they have all been pointed out in the WG)

1.  Codec release - when resources for a specific codec has been
  reserved only for the stream that is terminated.  In that case the
  resources associated with that codec can be released.

No, lets say that I have loaded iLBC into the DSP and put it in the offer, just because one dialog that was using iLBC terminates does not mean I can unload it. It's still int eh SIP offer and I have to accept RTP with that codec.

  2.  Pre-conditions - when the dialog is terminated, procedures and
  resources associated to the pre-conditions for that dialog can be
  released.

What resources exactly and how will this help, It's not like I can release one set of bandwidth before the next allocation comes. This only causes the return to happen a matter of seconds sooner. I'm unconvinced this offers any compelling value.

  3.  In-band security negotiation - when the dialog is terminated,
  procedures and resources associated with the in-band security
  negotiation for that dialog can be released.

What resources?

  4.  ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
  terminated, procedures and resources associated with the ICE related
  in-band procedures for that dialog can be released.

No, the candidates are still in the offer and need to remain valid. I don't really know what resources this means

  5.  Limited access resources - in case of forking and multiple stream
  it may not be possible to allow early media on all dialogs, so media
  sessions associated with some dialogs may e.g. be set to "inactive".
  When a dialog is terminated, media sessions associated with other
  dialogs can be allowed.

Remind me of a practical scenario where multiple entities on the dialog will be sending simultaneously early mead. I agree it can happen but it is not at all clear to me why any of them would terminate the dialing.


  6.  Secure media selection - when SRTP is used to encrypt the media.

I have no idea what this means. You talking about a few bytes of a MKI mapping to crypto context ?

"Latching" in SBC is not at all what you describe here. It is the process by which an SBC decide to send RTP to a IP address that is different than what is in the SDP.

In  the case of early ring tone termination where say a PSTN gateway roles over to vowicemail, I don't see who this will accelerate the move in any useful way from the PSTN ringback tone to the voicemail server media.


I see no reason to allow this in a Require or proxy-Require and think that should be a MUST NOT.

It's unclear to me what Reason code to insert or why this is a MUST. The reason code seems useless for the alleged uses of this mechanism.

The 199 SHOUDL/NOT have SDP, please help me understand when it is OK to do that. Actually probably need to understand when it is OK to violate just about every SHOULD in the document.

The handling of an INVITE without an offer looks somewhat broken. I Sending an offer with emptily m-lines is not going to cause the call to fail with plenty of 3261 compliant equipment. You need to fix this. I have no idea how to fix it.

You say when a proxy receives an out of dialog 199, it processes it normal. How exactly is that? If the answer is it statelessly forwards it I think this is a big security problem as I can use that get random people to redirect their RTP streams to perform DOS attacks.

I could be confused but it looks like section 8 contradicts section 5 on what a UAS does to send responses containing an offer.

The not sending things reliably that have a Require: 100rel seems like it will break cretin IDS, firewalls, and middlesboxes.


The security considerations section ill be pretty useless for any implementor.

I support the point Sam Weiler made of
I'm also a little worried about the implications of one party or
another trying to continue the dialog, perhaps maliciously, after
sending or receiving one of these.  What if one of these were used to
disable a monitoring or billing system, but the parties continued to
use the open session?  (Compare to sending a weak C-tone on a
wiretapped PSTN line.)

[Ballot comment]
Section 1 states

  The 199 response code is an optimization, which allows the UAC to be
  informed about terminated early dialogs.  However, since the support
  of the 199 response is optional, a UAC cannot assume that it will
  always receive a 199 provisional response for all terminated early
  dialogs.

Section 4 seems to imply that there are some applications that will not work unless 199
is supported:

The UAC SHOULD NOT insert the 199 option-
  tag in the Require header, unless the particular session usage
  requires the UAS to support the response code.  Also, the UAC SHOULD
  NOT insert the 199 option-tag in the Proxy-Require header, unless the
  particular session usage requires every proxy on the path to support
  the response code.

Are these two sections in conflict?

[Ballot comment]
The document does not say what track it is targeting. I assume from the
ballot that it is intended as Standards Track. Please can you confirm
and update the document header.

The abbreviations UAC and UAS will need to be expanded in the Abstract
and on first usage in the body text.

[Ballot comment]
INTRODUCTION, paragraph 2:
>            Response Code for Indication of Terminated Dialog

  Add something to the title that makes it clear this is for SIP?

Section 3., paragraph 1:
>    REQ 1: It must be possible to indicate to the UAC that an early
>    dialog has been terminated before a final response is sent.

  I don't understand the purpose of including this single requirement in
  this specification document. At least not without further explanation.

[Ballot comment]
I don't think the document is doing a very good job convincing readers about utility of this mechanism. At least not until it starts describing detailed use cases.


4.1.  Examples of resource types

  NOTE: When using SRTP [RFC3711], the secure media stream is bound to
  the crypto context setup for the dialog, and can be identified using
  the MKI (if used) of SRTP.

Please expand the acronym on first use.

  If the client only has a single early dialog (other early dialogs MAY
  not have been established, or they MAY have been established and

It doesn't look like use of these 2 MAYs is correct - they don't describe requirements.

  later terminated) and a 199 response is received for that early
  dialog, the client terminates the early dialog.  Afterwards, the
  client SHOULD act as before the first early dialog was established.


4.2.  Examples of policy procedures

  2.  SBC early media selection - when an SBC is used to control which

Please expand the acronym on first use.

  media is processed and forwarded.  In many cases, the SBC only
  processes media associated with a single early dialog.  Typical for
  NAT traversal, the SBC often "latches" onto a media stream.  If a 199
  response is received, the SBC can choose to start processing media
  associated with another dialog.  If the SBC performs latching, it can
  trigger a "re-latch" onto a new media stream when the 199 response is
  received.

14.1.  Normative References

  [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

  [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

  [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

I think the above references are Informative.

[Ballot comment]
I don't think the document is doing a very good job convincing readers about utility of this mechanism.


4.1.  Examples of resource types

  NOTE: When using SRTP [RFC3711], the secure media stream is bound to
  the crypto context setup for the dialog, and can be identified using
  the MKI (if used) of SRTP.

It would be nice to expand the MKI acronym on the first use

  If the client only has a single early dialog (other early dialogs MAY
  not have been established, or they MAY have been established and

It doesn't look like use of these 2 MAYs is correct - they don't describe requirements.

  later terminated) and a 199 response is received for that early
  dialog, the client terminates the early dialog.  Afterwards, the
  client SHOULD act as before the first early dialog was established.


4.2.  Examples of policy procedures

  2.  SBC early media selection - when an SBC is used to control which

Please expand the acronym.

  media is processed and forwarded.  In many cases, the SBC only
  processes media associated with a single early dialog.  Typical for
  NAT traversal, the SBC often "latches" onto a media stream.  If a 199
  response is received, the SBC can choose to start processing media
  associated with another dialog.  If the SBC performs latching, it can
  trigger a "re-latch" onto a new media stream when the 199 response is
  received.

14.1.  Normative References

  [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

  [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

  [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

I think the above references are Informative.

[Ballot comment]
The Gen-ART Review by Avshalom Houri on 26 Jan 2010 suggested adding
  references to other relevant RFCs in the Security Considerations.  A
  few editorial changes were suggested.  Please consider these changes.

IANA comments:

Action #1:

Upon approval of this document, IANA will make the following
assignment in the "Response Codes" registry at
http://www.iana.org/assignments/sip-parameters

Response Code Reference
------------------------------------------ ---------
Provisional 1xx
199 Early Dialog Terminated [RFC-sipcore-199-02]


Action #2:

Upon approval of this document, IANA will make the following
assignment in the "Option Tag" registry at
http://www.iana.org/assignments/sip-parameters

Name : 199
Reference: [RFC-sipcore-199-02]
Description :
This option tag is for indicating support of the 199
Early Dialog Terminated provisional response code. When present
in a Supported header, it indicates that the UA supports the
response code. When present in a Require header in a request,
it indicates that the UAS MUST support the sending of the
response code.

We understand the above to be the only IANA Actions for this document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Gonzalo Camarillo who has reviewed the document
and believes it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been sufficiently reviewed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Some people found the problem this document resolves to be too small to
bother fixing it. Those who thought the problem was relevant agree with
the contents of the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

ID nits complains about a couple of formatting issues that will be
easily resolved by the RFC Editor.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and informative.
There is a normative reference to the ICE specification. There is a
downreference to RFC 5009 (P-header for authorization of early media).

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The IANA Considerations Section is OK.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document does not contain formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP forking proxy and a UAS can use to indicate
upstream towards the UAC that an early dialog has been terminated,
before a final response is sent towards the UAC.

Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?

Nothing worth noting.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?

Some vendors indicated that they would implement this extension.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Gonzalo Camarillo is the document shepherd. Robert Sparks is the
responsible AD.