Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2009 13:32:34 -0600

On Oct 14, 2009, at 1:20 PM, Christer Holmberg wrote:

>
> Hi Robert,
>
> Comments inline.
>
> -------------------
>
>> In preparing this document for IETF last call, I found a few points  
>> we
> should discuss before moving forward.
>>
>> Major Comments
>>
>> I don't understand the sentence in section 4.1 that talks about
> RFC5009.  There is not enough here to inform an
>> implementor and don't think 5009 is required reading to understand or
> implement this document (hence, I don't agree that
>> 5009 should be a normative reference). The sentence has been there  
>> for
> a long time, but I think other things have pulled
>> reviewer's eyes away from it.
>
> I can change 5009 into an informative reference.
>

You didn't do this in -01?

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2009 13:37:38 -0600

...

>
>
>> In Sections 5 and 9, the document says to include SDP in a 199 if
>> RFC3263 requires it. I would like to see some additional discussion
> around whether this is the right way to deal with
>> this edge case. If it is, then this document needs to explain how a  
>> UA
> should handle receiving an offer in a 199.  A
>> different path out is to say that such a 199 MUST NOT be sent  
>> reliably.
> (More explanation of why we allow 199 to be sent
>> reliably at all (why this is SHOULD not MUST) would also help).
>
> I wouldn't like to generally disallow to send 199 reliably, in case
> there is some future use-case which would need it. That's the reason  
> for
> the SHOULD: don't send it reliably unless you have a good reason to do
> so.
>
> Regarding the specific must-include-SDP-offer case (which will be very
> rare, in my opinion) I see two alternatives:
>
> 1.  We disallow reliable 199 in such cases
> 2.  We say that the UAS must include e.g. an SDP offer without any m-
> lines.
>
> My proposal is to describe both alternatives, and say that the UAS  
> MUST
> use of them.
>

I'm not seeing any changes in -01 addressing this comment?

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2009 13:41:08 -0600

>
>> Last sentence on page 8: This paragraph is talking about the proxy
> generating a 199 itself. It would be terribly
>> misleading from a diagnostics point of view for the proxy to put the
> Record-Route and contact from some UA (it would then
>> look like the 199 came from the remote endpoint - is that what you  
>> are
> trying to accomplish?). Why is having these bits
>> in the message useful at all?
>
> The intention is NOT to make the 199 look like it came from the
> endpoint, but someone commented that the UA could be confused if the
> bits aren't included.
>
> Personally I would bo ok to remove the text, since the proxy is not
> allowed to send a 199 reliably (there will be no PRACK etc, for which
> the bits would b needed)

The document shows no change from -00 addressing this comment either?

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2009 13:43:29 -0600

I still can't find where in the document this is answered. Can you  
point to the sentence(s) that you
think covers these.

RjS

On Oct 16, 2009, at 1:29 PM, Christer Holmberg wrote:

>
> Hi,
>
>>> I don't think the document currently provides a solid answer to this
>>> question (maybe I'm missing it): If a proxy has
>>> multiple branches outstanding and receives a 200 OK on one of  
>>> them, it
>>> forwards it immediately. As the other branches
>>> complete, should the proxy send 199s for them (assuming they didn't
>>> complete with additional 200s)?
>>
>> The intention is that NO 199s are sent after 200 OK has been  
>> forwarded
> on a branch, and the proxy sends CANCEL on the other branches.
>>
>> I DO agree that it is not clear in the spec, and that we can add some
> text about that.
>
> Actually, when taking a closer look at the text, I think this is  
> already
> covered. The text says that when the proxy receives a non-2xx final
> response, it sends 199 if the forking proxy has not already sent a  
> final
> resposne for any of the early dialogs. So, if a final response (2xx or
> non-2xx) response has been sent, additional non-2xx responses will not
> trigger 199.
>
> Regards,
>
> Christer
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Dec 2009 13:50:45 -0600

While these were less important, I'm not seeing any changes at all  
addressing them, even for those you indicated you would make changes.

At this point, I'd like to double-check that you submitted what you  
meant to submit as -01?

RjS

On Oct 14, 2009, at 1:20 PM, Christer Holmberg wrote:
>
>> Minor Comments
>>
>> Bottom of page 3, next to last paragraph, last sentence: This assumes
> the response can't be recovered from, precluding
>> responding to authentication challenges, extension negotiation, etc.
>
> Again, I am not sure I understand the comment.
>
> -------------------
>
>> Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP?
>
> I can add it. How would you like to change to look like?
>
> -------------------
>
>> Section 8 is completely redundant. It adds no value to the draft. I
> suggest deleting it.
>
> I based this on other drafts, but I can remove it.
>
> -------------------
>
>> Nits
>>
>> The 2119 language (two instances of MAY unless I missed more)  
>> appearing
> in the introduction are inappropriate in an
>> introduction.
>
> I propose to change "MAY" to "can" (in the introduction).
>
> -------------------
>
>> Page 5, second paragraph : is "shall not" meant to be normative?
>
> Yes. I'll change it to uppercase.
>
> -------------------
>
>> Page 8 Section 6 first paragraph: Suggest dropping "on an early  
>> dialog"
> from the first sentence. Does it add anything?
>> This would help avoid the problem the current text has about assuming
> proxies know about dialogs.
>
> I can drop it from the first sentence.
>
> -------------------
>
> Thanks for your comments!
>
> Regards,
>
> Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Dec 2009 20:56:05 +0100

Hi Robert,

It seems like I did some of the changes in another XML file than the one
I used to produce the -01 draft - sorry for that :(

>>>for a long time, but I think other things have pulled

It is now in the correct XML file, so it will be done in -02.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Dec 2009 21:45:16 +0100

Hi,
 
meant to submit as -01?

Again, most changes were done (note the DTLS/SRTP issue, though), but in
the wrong xml file. "Change done now" means that the changes will be in
version -02.

-------------------

>>the response can't be recovered from, precluding responding to
authentication challenges, extension negotiation, etc.
>Again, I am not sure I understand the comment.

The sentence tries to describe current behavior. I added ", or retry,"
to the text, in order to clarify that the UAC may retry the session
setup.

"When SIP entities upstream receive the non-2xx final response they will
release resources associated with the
session, and the UAC will terminate, or retry, the session setup."

-------------------

>I can add it. How would you like to change to look like?

On this topic I did send out an e-mail (RE: [sipcore] AD review
draft-ietf-sipcore-199-00 - DTLS/SRTP), where I said:

"I would need some clarification on why DTLS would have to be added
here. The issue is not related to a specific key management mechanism
used, but with the fact that the media is encrypted in general.

Of course different key management mechanisms may have different impacts
on the needed resources etc, but I still don't see why this would be an
issue specific to DTLS."

-------------------

suggest deleting it.
>I based this on other drafts, but I can remove it.

Change done now.

-------------------

appearing
>>in the introduction are inappropriate in an introduction.
>		

Change done now.

-------------------

>Yes. I'll change it to uppercase.
	
Change done now.

-------------------

dialog"
>I can drop it from the first sentence.

Change done now.
	
-------------------

Again, sorry for the mess.

Regards,
	
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Dec 2009 21:49:15 +0100

Hi, 

>I still can't find where in the document this is answered. Can you
point to the sentence(s) that you think covers these.

Section 6 says:

"When a forking proxy receives a non-2xx final response that it
recognizes as terminating one or more early dialogs, it SHOULD
generate and send a 199 response upstream for each of the terminated
early dialogs that satisfy each of the following conditions:

- the forking proxy does not intend to forward the final response
immediately (in accordance with rules for a forking proxy)

- the UAC has indicated support (using the 199 option tag) for the
199 response code

- the forking proxy has not already received and forwarded a 199
response for that early dialog

- the forking proxy has not already sent a final response for any of
the early dialogs"

I think the fourth condition addresses your issue.

Regards,

Christer

>>> question (maybe I'm missing it): If a proxy has multiple branches 
>>> outstanding and receives a 200 OK on one of them, it forwards it 
>>> immediately. As the other branches complete, should the proxy send 
>>> 199s for them (assuming they didn't complete with additional 200s)?
>>
> already covered. The text says that when the proxy receives a non-2xx 
> final response, it sends 199 if the forking proxy has not already sent

> a final resposne for any of the early dialogs. So, if a final response

> (2xx or

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Dec 2009 21:55:04 +0100

Hi,

>>Record-Route and contact from some UA (it would then look like the 199
came 
>>from the remote endpoint - is that what you are trying to
accomplish?). 
>>Why is having these bits in the message useful at all?
>		

In version -02 the last sentence, talking about Contact and
Record-Route, will be removed.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Dec 2009 15:03:25 -0600

Ok - I can see how you are reading the text.

I think the opportunity for mis-interpretation is very high here  
though, and
encourage adding a sentence after this saying something like:

"As a consequence, once a final response to the INVITE has been issued  
by
  the proxy, no further 199 messages corresponding to the INVITE will be
  generated or forwarded by the proxy"

RjS

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Dec 2009 22:04:59 +0100

Hi,

>>UA should handle receiving an offer in a 199.  A
>>for the SHOULD: don't send it reliably unless you have a good reason 
>>to do so.
>>

>>1.  We disallow reliable 199 in such cases 2.  We say that the UAS 
>>must include e.g. an SDP offer without any m- lines.
>>
>>MUST use of them.

I changed and extended (will be seen in -02) the note into normative
text:

"A 199 Early Dialog Terminated provisional response SHOULD NOT contain
an SDP offer/answer message body, unless required by the rules in
[RFC3264].

If the INVITE request did not contain an SDP offer, and the 199
response is the first reliably sent response, the 199 response is
required to contain an SDP offer. In this case the UAS SHOULD send
the 199 response unreliable, or include an SDP offer with no m- lines 
in the reliable 199 response."

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Dec 2009 22:14:03 +0100

Hi, 

>I think the opportunity for mis-interpretation is very high here
though, and encourage adding a sentence after this saying something
by
>generated or forwarded by the proxy"

I can do that. I will add the text below the conditions.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 09 Dec 2009 17:03:40 +0200

Hi Christer,

> the wrong xml file. "Change done now" means that the changes will be in

why don't you submit 02 now so that people can follow the discussions 
more clearly? You can submit 03 later if more changes are needed.

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Dec 2009 21:56:28 +0100

Hi,

I have now submitted version -02.

Regards,

Christer

-----Original Message-----
From: Gonzalo Camarillo 
Sent: 9. joulukuuta 2009 17:04
To: Christer Holmberg
Cc: Robert Sparks; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00

Hi Christer,

> Again, most changes were done (note the DTLS/SRTP issue, though), but 
> in the wrong xml file. "Change done now" means that the changes will 
> be in version -02.

Thanks,

Gonzalo