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

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi Robert,

In this reply I will try to address all issues except the ones related
to proxies-sending-reliably-199, which is dealt with in another thread.

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

I guess so.

>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.

What I mean to say is that when the UAC receives a final response for an
early dialog it normally releases all other early dialogs (the UAC
should of course still be ready to accept 200 OK responses for other
dialogs).

>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.

The idea is that if the proxy supports the 199, it must send it.

>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.

I can add text saying that if the proxy is aware that a 199 has already
been sent for a particular dialog, it shall not send a 199.

>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.

I guess we can add text saying that the transaction state must be
maintained as defined in 3261. Feel free to propose text :)


>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.

I'll have a look.

>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".

Based on the agreement in Dublin I intend to remove it.

>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.

Ok.


>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.

What it is supposed to say is that you cannot send a 199 if you are
required (by the offer/answer rules) to include SDP.


>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.

I agree we need to deal with the security considerations. I was hoping
we could get rid of some of the open issues first.

Thank you very much for your comments!

Regards,

Christer

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip