Subject: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Dec 2002 14:05:30 -0800

Hi,

I'd like the SIPPING working group to provide expert review of:

http://www.ietf.org/internet-drafts/draft-dcsgroup-sipping-proxy-proxy- 
01.txt

The authors have requested individual publication of the P-Headers  
defined therein.  Expert Review will close on January 14, 2003

thanks,
-rohan

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 12 Dec 2002 10:46:16 +0200

Hi:

I have a few comments, mainly from my experience in a similar process in the past (I mean, when we wrote the 3GPP P- headers draft).

1) I would recommend you to not use "addr-spec" in the syntax of any header, and instead, use "name-addr". "name-addr" contains an "addr-spec" within quotes, and optionally, a display name. It is therefore, richer and easier to parse. Besides, there are a few SIP headers (Route, Record-Route) that only allow "name-addr". One of the few changes we did in the last version of the 3GPP P-headers draft was to fix all the relevant headers to include "name-addr" instead of "addr-spec".

So, for instance, the P-DCS-Trace-Party-ID syntax would become:

         P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr

2) I miss in the document a table of new headers. Basically an extension of Table 2 in RFC 3261. We have a similar one in section 5.7 of the 3GPP P- headers.

3) With respect the name that you have chosen for the headers, I don't understand why all of them are prepended by a "DCS" substring. I understand that the headers were originally designed for the DCS architecture, but once you publish the internet draft as an informational RFC, other organizations (e.g., 3GPP) could "import" one or more headers in its work. The fact that all the headers begin with "P-DCS-" will probably give problems to some folks to use those headers outside their original context. As an example, none of the 3GPP P- headers are named "P-3GPP-" (I remember I fought this hard with some 3GPP folks). My recommendation is to remove the "DCS" substring from the name of all these headers.

4) Section 6.6. (Procedures at the proxy for P-DCS-Gate): "The P-DCS-Gate header MUST NOT appear in any message other than the initial INVITE request, or in the first reliable non-100 response to that request". I have a question here: do you really mean in any non-100 response to the request?? That will include, for instance, 3xx and upper responses?? Perhaps do you mean "... any realiable 1xx (except 100) or 2xx response ".

5) Section 7.4 (about the P-DCS-OSPS header): " ... it MUST reject the request with a 409-Conflict error code.". Well, first I guess you refer to the 409 response rather than error code. But what is more important: the 409 response is not longer defined in RFC 3261, so you should change it to any other suitable response.

6) Section 7.6 (P-DCS-OSPS header): "If a proxy receives a P-DCS-OSPS header in a request from an untrusted source, it MUST reject the request". I find hard to understand why will you reject a request from an untrusted source when it contains a header that you don't accept. I consider it an easy denial of service attack to a proxy. I would think that is logical to ignore and remove the header, and process the request, if such request came from an untrusted source (similar behaviour as for the P-Asserted-Identity). But if you have a very good reason to reject requests in this case, I would say that you should specify which response are you going to send back.

7) Section 8.1 (Syntax for P-DCS-Billing-Info): According to the comment I gave in my point 1 above, the syntax of Acct-Charge-URI, Acct-Calling-URI- Acct-Called-URI, Acct-Routing-URI and Acct-Loc-Routing-URI should be "name-addr" for all of them. The word "URI" is not defined in this document nor in RFC 3261. The same applies for the Called-ID and Redirector in the P-DCS-Redirect in section 9.1.

8) Section 8.6.1. In this section, you mention several times the "18x-Ringing" response. I am not sure what kind of response is that. Do you mean a 180 Ringing only or any 1xx response (including 181, 182, 183)?

This is all. Regards,

      Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP