[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Sip-199-02: majors and nits from Robert (was: RE: WGLC for draft-ietf-sip-199-02)
Hi Robert,
(I will comment the minors in a separate reply)
------
>Major:
>maj-1) Do we have a constituency willing to finish this work? It has a
ways to go and the number of commenters has been
>pretty small. Does anyone know of any attempts to implement this yet?
I am aware of plans to implement it.
------
>maj-2) -02 is an improvement over -00, but the basic architectural
intent is still not clear (as evidenced by the
>remaining open issue in section 5 - in fact I think this is the _REAL_
open issue that the thing in section 5 is
>pointing to). An implementer would probably benefit from a short
overview section that outlined the mechanics.
I agree that it currently is THE open issue. One proposal, based on
inputFrom sip-bounces at ietf.org Fri Nov 21 16:37:21 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 00A423A6808;
Fri, 21 Nov 2008 16:37:21 -0800 (PST)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E1FEC3A6808
for <sip at core3.amsl.com>; Fri, 21 Nov 2008 16:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.137
X-Spam-Level:
X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112,
BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 09JQ2rAbWaiY for <sip at core3.amsl.com>;
Fri, 21 Nov 2008 16:37:18 -0800 (PST)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
by core3.amsl.com (Postfix) with ESMTP id 71C653A67AB
for <sip at ietf.org>; Fri, 21 Nov 2008 16:37:18 -0800 (PST)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
E278720818; Sat, 22 Nov 2008 01:36:21 +0100 (CET)
X-AuditID: c1b4fb3c-ab8c9bb0000015b5-3a-49275405683e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
ACDD0203A4; Sat, 22 Nov 2008 01:36:21 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Sat, 22 Nov 2008 01:36:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 22 Nov 2008 01:36:20 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF05C0F9B3 at esealmw113.eemea.ericsson.se>
In-Reply-To: <58BEC600-AE98-4ADC-A822-DC3FF4B0B398 at nostrum.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Sip-199-02: majors and nits from Robert (was: RE: [Sip] WGLC for
draft-ietf-sip-199-02)
thread-index: AclENT1Jx1/iIji4RxKlbejpCUMInQB6CvXg
References: <5D1A7985295922448D5550C94DE29180024975DD at DEEXC1U01.de.lucent.com>
<900DBDFF-96AA-4EF8-96EC-A5DF0D3A7F92 at nostrum.com>
<58BEC600-AE98-4ADC-A822-DC3FF4B0B398 at nostrum.com>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Robert Sparks" <rjsparks at nostrum.com>
X-OriginalArrivalTime: 22 Nov 2008 00:36:21.0826 (UTC)
FILETIME=[57997A20:01C94C3A]
X-Brightmail-Tracker: AAAAAA==
Cc: SIP IETF <sip at ietf.org>
Subject: [Sip] Sip-199-02: majors and nits from Robert (was: RE: WGLC for
draft-ietf-sip-199-02)
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi Robert,
(I will comment the minors in a separate reply)
------
>Major:
>maj-1) Do we have a constituency willing to finish this work? It has a
ways to go and the number of commenters has been
>pretty small. Does anyone know of any attempts to implement this yet?
I am aware of plans to implement it.
------
>maj-2) -02 is an improvement over -00, but the basic architectural
intent is still not clear (as evidenced by the
>remaining open issue in section 5 - in fact I think this is the _REAL_
open issue that the thing in section 5 is
>pointing to). An implementer would probably benefit from a short
overview section that outlined the mechanics.
I agree that it currently is THE open issue. One proposal, based on
input from Bret (see separate thread) would be to say the following:
"A UAS must send 199 if it establishes more than one early dialog, and a
UAS may send 199 if it establishes a single dialog."
That way I don't think we need to distinguish between endpoint UASs and
B2BUAs.
I've also mailed to other alternatives to the list, which I intended to
present at the meeting.
------
>maj-3) The document defines an option tag but doesn't say what it means
if it shows up in a Require: header.
I think we could say that it means that the UAS must support 199.
Whether it then actually sends 199 depends on whether it fulfils the UAS
criteria for sending 199 (see maj-2).
------
>maj-4) The Security Considerations section is empty. I've pointed
already (in my comments to -00) of at least one
>situation we need to discuss here (It said "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.) We need some focused discussion to
uncover any other issues this new behavior is bringing
>to the system.
I will initiate a separate thread for this.
------
>maj-5) (I waffled on putting this into minor, but I've made this
comment before and it hasn't been sufficiently
>addressed). The document needs to be more explicit in explaining how it
might be that a single 3-6xx response showing up
>at a proxy might cause it to send more than one 199. Something like
http://www.nostrum.com/~rjsparks/example.png
>perhaps.
I will take a second look at that.
------
>maj-6) The document should discuss what a proxy should do if a 199
shows up for an early dialog it's already generated
>its own 199 about.
>(This might happen, for instance, if a 3-6xx and a 199 crossed on the
wire or were reordered by previous elements on the
>way to this proxy).
If the 199 is sent reliably I guess the proxy could forward it, in order
to the UAC to PRACK it.
If the 199 is sent unreliably I guess the proxy could discard it, or
forward it.
But, I need to think about this a little more.
-----
>maj-7) Section 7 on backwards compatibility is really confusing and
doesn't stand up against some edge situations. In
>particular, it doesn't act right when a request comes in that's a
retransmission or a merge. It could also be
>misinterpreted (a stretch, but I've seen this
>stretch) to constrain UASes to send a 481 to an ACK. I suggest we get
together in the hall at IETF73 and collaboratively
>wordsmith a replacement for this section.
I guess we never got a chance to discuss this, but I think I understand
your point. I guess I could modify the text, and simply say that a UAS
which receives a request after it has sent 199 shall act in the same way
as if it had received the request after sending the final non-2xx
response to the INVITE, as specified in RFC3216.
"If such request is received by a UA, it MUST reply to such requests
with a 481 final response."
...is replaced with:
"If such request is received by a UA, it shall act in the same way as if
it had received the request after sending the final non-2xx response to
the INVITE, as specified in RFC3261."
-----
>maj-8) What is the purpose of section 8? I suspect it should just be
deleted.
I took it from another draft (don't remember which) that defines a new
response code.
-----
>maj-9) Section 9 allows a 199 to contain SDP. Why? This document should
either forbid that practice or explicitly
>document why it is allowed.
I am fine with disallowing it completely.
-----
>Nit:
>nit-1) "resrouces" occurs several times in section 4.1
>
>nit-2) The document still contains [ref needed] when talking about ICE
in section 4.1
>
>nit-3) The Note in section 4.1 has a reference to RFC3261 ostensibly
about SRTP. Did it mean to point to an SRTP
>document instead?
>
>nit-4) "intial" appears in section 5
>
>nit-5) Suggest replacing "triggers a 199 response" in section 10 with
"generates a 199 response"
I'll do the fixes in the next version of the draft.
-----
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
from Bret (see separate thread) would be to say the following:
"A UAS must send 199 if it establishes more than one early dialog, and a
UAS may send 199 if it establishes a single dialog."
That way I don't think we need to distinguish between endpoint UASs and
B2BUAs.
I've also mailed to other alternatives to the list, which I intended to
present at the meeting.
------
>maj-3) The document defines an option tag but doesn't say what it means
if it shows up in a Require: header.
I think we could say that it means that the UAS must support 199.
Whether it then actually sends 199 depends on whether it fulfils the UAS
criteria for sending 199 (see maj-2).
------
>maj-4) The Security Considerations section is empty. I've pointed
already (in my comments to -00) of at least one
>situation we need to discuss here (It said "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.) We need some focused discussion to
uncover any other issues this new behavior is bringing
>to the system.
I will initiate a separate thread for this.
------
>maj-5) (I waffled on putting this into minor, but I've made this
comment before and it hasn't been sufficiently
>addressed). The document needs to be more explicit in explaining how it
might be that a single 3-6xx response showing up
>at a proxy might cause it to send more than one 199. Something like
http://www.nostrum.com/~rjsparks/example.png
>perhaps.
I will take a second look at that.
------
>maj-6) The document should discuss what a proxy should do if a 199
shows up for an early dialog it's already generated
>its own 199 about.
>(This might happen, for instance, if a 3-6xx and a 199 crossed on the
wire or were reordered by previous elements on the
>way to this proxy).
If the 199 is sent reliably I guess the proxy could forward it, in order
to the UAC to PRACK it.
If the 199 is sent unreliably I guess the proxy could discard it, or
forward it.
But, I need to think about this a little more.
-----
>maj-7) Section 7 on backwards compatibility is really confusing and
doesn't stand up against some edge situations. In
>particular, it doesn't act right when a request comes in that's a
retransmission or a merge. It could also be
>misinterpreted (a stretch, but I've seen this
>stretch) to constrain UASes to send a 481 to an ACK. I suggest we get
together in the hall at IETF73 and collaboratively
>wordsmith a replacement for this section.
I guess we never got a chance to discuss this, but I think I understand
your point. I guess I could modify the text, and simply say that a UAS
which receives a request after it has sent 199 shall act in the same way
as if it had received the request after sending the final non-2xx
response to the INVITE, as specified in RFC3216.
"If such request is received by a UA, it MUST reply to such requests
with a 481 final response."
...is replaced with:
"If such request is received by a UA, it shall act in the same way as if
it had received the request after sending the final non-2xx response to
the INVITE, as specified in RFC3261."
-----
>maj-8) What is the purpose of section 8? I suspect it should just be
deleted.
I took it from another draft (don't remember which) that defines a new
response code.
-----
>maj-9) Section 9 allows a 199 to contain SDP. Why? This document should
either forbid that practice or explicitly
>document why it is allowed.
I am fine with disallowing it completely.
-----
>Nit:
>nit-1) "resrouces" occurs several times in section 4.1
>
>nit-2) The document still contains [ref needed] when talking about ICE
in section 4.1
>
>nit-3) The Note in section 4.1 has a reference to RFC3261 ostensibly
about SRTP. Did it mean to point to an SRTP
>document instead?
>
>nit-4) "intial" appears in section 5
>
>nit-5) Suggest replacing "triggers a 199 response" in section 10 with
"generates a 199 response"
I'll do the fixes in the next version of the draft.
-----
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