Subject: [Sip] Comments on draft-ietf-sip-199-00.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Jul 2008 13:26:28 -0500

Here are a set of comments to start/continue some discussions on the  
199 draft around.
Many of them are nits. Some of them are fairly big.

The draft has quite a bit of cooking to go through yet, but its mostly  
of a nature that can be
cooked through fairly quickly I think. I plan to spend time in the  
hall with Christer to address
what we haven't killed off on list this week.

----

1) The header says intended status is Informational? You mean PS, right?

2) The draft is still unclear about proxy interaction with the 199  
idea, particularly
      when it comes to sending them reliably. We need to spend more  
time making
      the text clear, being particularly careful when there are  
multiple proxies in the
      path of a response. I bring this up here as a general comment  
because I don't
      think just fixing individual sections is going to be good enough  
- I think its going
      to take a holistic editing pass to address.

3) In section 6 you talk of a non-2xx final response terminating one  
or more early
     dialogs. Can you give me an example scenario where "more" comes  
into play?
     (preferably add one to the text)? I'm having a hard time seeing  
how this ever more
      than one.

4) Section 6 says the proxy MUST send a 199 when it receives on of  
these non-2xx
      final responses. Why is this MUST and not MAY?
      There's no Require header here. We can have motivational text  
saying why
      proxies might really want to, but saying MUST or even SHOULD  
seems wrong
      from a protocol requirement point of view.

5) With respect to that same requirement - it looks right now like  
you're requiring
      the proxy to 199 this to-tag even if the UAS that generated it  
already did and the
      proxy already forwarded that 199 even.

6) Section 6 paragraph one's "MAY release resources" might be  
misconstrued to
      imply releasing the transaction state, which is NOT what you  
mean. I'll propose
      text to help try to avoid that later.

7) Section 7: "A UAC that receives a 199 response for an early dialog  
MUST NOT
    send any further requests on that dialog...". Can you point to any  
list discussion
    around this requirement? I think there's some danger to consider  
there. At the
     very least we need to make this statement multiple-usage safe.

8) The last paragraph of section 7 uses MUST NOT and MUST where it  
really
      should be using does not and is. This paragraph describes things  
that are
      rather than mandate behavior.

9) Section 8 second open issue: We agreed that we were not addressing  
HERFP
      with this draft. If we are going to open this mechanism up to  
something that
      even _partially_ starts to address HERFP (by, as proposed,  
including the
      non-2xx response that caused the 199), then we need to stop work  
on this
      draft and go work on HERFP. In other words, my vode for the  
answer to this
      open issue is "NO".

10) Section 8 first open issue: This looks, at best, to be an  
optimization of an
        optimization. Considered in the light of having multiple  
proxies on the
        response path that would have to do extra parsing work because  
of this
        optimization, I don't think we should consider it further.

11) I can't follow the second paragraph of section 9 at all. Can you  
rephrase it?
       Once I know what its trying to say, I'll propose alternate text.

12) The open issue in section 10 (can we get a proxy involved in  
sending its own
        199 reliably) is a big part of the confusion I pointed to at  
the beginning of
        these comments. This is the part of the draft that I expected  
needing face time
        in Dublin, but maybe we can make enough progress on it in the  
hallway.
        I don't think there's any way to allow it, and what we'll need  
instead is text
        more strongly recommending the endpoints do this themselves  
and restrict
        any proxy genesis of 199s to the unreliable case (and explain  
more that this
        is just a transitionary optimization - we _really_ want the  
endpoints doing this
        work if anything's going to be doing it at all.

13) The security considerations section is TBD.
        There's a lot to talk through here. For instance, I can spoof  
199s to affect how a call
        is ultimately answered in ways that are different (from the  
endpoints visibility into
        what happened point-of-view) from cancels/byes or even other  
response manipulation.

_______________________________________________
Sip mailing list  https://www.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: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Jul 2008 15:03:27 -0400

>     very least we need to make this statement multiple-usage safe.

This is a very good catch. This needs to be aligned with dialogusage. If 
the 199 contained the final response that triggered it, then that final 
response could be used to determine the impact on the dialog or dialog 
usage or just the transaction. But if the 199 doesn't contain the final 
response, then this is a problem.

> 12) The open issue in section 10 (can we get a proxy involved in sending 
> its own
>        199 reliably) is a big part of the confusion I pointed to at the 
> beginning of
>        more strongly recommending the endpoints do this themselves and 
> restrict

If the "proxy" wants to send a reliable 199, then I think it needs to do 
so on its own dialog. But that makes no sense. Having the proxy attempt 
to send the reliable response on the dialog belonging to the UAS is 
*insane*.

	Paul