[Sipping] resolution of comments received during expert review of draft-dcsgroup-sipping-proxy-proxy-01

[William Marshall <[e-mail]>]

Based on feedback during the "expert review period" for the indicated
draft, the following changes have been incorporated in the recently
submitted version.  Until it appears in the archives, it may be found at 
 ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sipping-proxy-proxy-02.txt
and a MSWord version with changebars from the previous submission is
 ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sipping-proxy-proxy-02.doc

Specific comments received, and the resolution of them, follows.

Miguel Garcia wrote:
> 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

done.

Miguel Garcia wrote:
> 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.

added, although I believe all the information in that table appears
in the text already.

Miguel Garcia wrote:
> 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.
Burcak Beser wrote:
> 4. I agree with Miguel about dropping the DCS portion from the headers.
> Even PacketCable will use these headers in a non-DCS enviroment.

There is an issue of backward compatibility here, and changing the header
names at the last minute, after years and years, seems extremely bad.

But even more important is that removing "-DCS" from the names will leave
such names as P-Billing-Info, P-Gate, P-LAES, etc.  It would be very
presumptuous of us to assume that all Billing information can be stored
in the format we chose for P-Billing-Info, or that all other groups that
needed to pass such information would choose a non-conflicting name for
their header.  While we can claim to be first, and take all that is
available from IANA right now, that just doesn't seem fair to all.

PacketCable is using them in a non-DCS environment, and the current
released PacketCable spec (which was reviewed by all PacketCable vendors
and approved) mandates them.  With the "P-DCS-" prefix.

Miguel Garcia wrote:
> 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 ".

Good point.  This affects lots of other sections as well.  Changed throughout.

Miguel Garcia wrote:
> 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.

Changed to a 403 response.

Miguel Garcia wrote:
> 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.

Having the option to remove the header seems like a reasonable addition.

Miguel Garcia wrote:
> 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.

OK.  Note that in current use, they will all reduce to tel: URLs,
in order to be consistent with the PacketCable Event Messaging 
specification.  But it is nice to generalize the syntax for the future.

Miguel Garcia wrote:
> 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)?

What is meant is any 18x response, typically 180 or 183.  Changed
to "18x response".

Burcak Beser wrote:
> 1. The section '6 P-DCS-GATE' refers to PacketCable Dynamic Quality of
> Service which no longer specifies the Gate Coordination. The term DCS
> QoS mechanism should be used instead.
<points 2 and 3 are related to the same issue>

A note is added stating the manner in which the PacketCable Dynamic
Quality of Service specification currently uses Gate Coordination
(see Section 5.1.5 of PKT-SP-DQOS-I05-021127).

Burcak Beser wrote:
> 2. I know that because of the above issue the editor of the draft
> decided to use old versions of the specifications DQoS
> (PKT-SP-DQOS-I05-021127, the latest version is
> http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I07-021127.pdf)
> and Security (pkt-sp-sec-i05-020116, the latest version is
> http://www.packetcable.com/downloads/specs/pkt-sp-cmss-i02-021205.pdf).
and
> 7. The reference to pkt-sp-em-i03-011221, should be updated due to above
> specified reasons. The correct reference is PKT-SP-EM-I05-021127.

The "above issue" (your item #1) had nothing to do with it.  The PacketCable
specs have been updated several times and the references are outdated.
All references in the draft have now been updated to the current versions 
of the PacketCable specs. However, we need to recognize that this problem 
will reappear.

Burcak Beser wrote:
> 5. In section 8, the definition of Financial Entity ID (FEID) should be
> as Financial-Entity-ID for consistency with other definitions.

done

Burcak Beser wrote:
> 6. The FEID is defined as 8 byte structure in text, where as the
> specification referenced defines it as 'variable length ASII character
> string, where first 8 bytes constitute MSO defined data, the rest
> contains MSO's domain name.

The Event Message spec (PKT-SP-EM-I05-021127) does state that the field
is an ASCII string, but further states that the first 8 bytes, which are
MSO-defined data, are zero filled.  The "zero fill" may be either 
binary or ascii.  The domain name (up to 239 bytes) is certainly
ASCII, and is passed as such.  The only way to guarantee passing the
MSO-defined data transparently is to separate out the first 8 bytes
from the last 239 bytes and treat them separately.

Burcak Beser wrote:
> 8. I could not locate the definitions of Acct-Charge-URI,
> Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and
> Acct-Location-Routing-URI in the EM spec. 

Perhaps it is not clear that Acct-Charge-URI corresponds to "Charge
Number" (EM attribute ID 16), and that Acct-Calling-URI corresponds
to "Calling Party Number" (EM attribute ID 4), etc.  Although I
think it is obvious to anyone looking at the SIG-START event, some
text added to make this correspondance explicit.

Burcak Beser wrote:
> 9. Why not use the same approach as RKS-Group-ID not refer to EM spec,
> for all these details. The parameters should be defined as more
> generalized  which would make the definitions valid even if the specs
> change in the future. (By the way any reasons to keep RKS-Group-ID?)

PKT-SP-CMSS-I02-021205 Section 8.4.1.2 makes extensive use of RKS-Group-ID.
It is not defined in the EM spec.

Burcak Beser wrote:
> 10. Both P-DCS-LAES and P-DCS-Laes are being used in section 9. I
> suggest the use of P-DCS-LAES for consistency.

done

Burcak Beser wrote:
> 11. In section '10 Security Considerations' normative MUST is being used
> where I believe that should be non-normative must.

Note how in other documents, such as draft-ietf-sip-call-auth-06, the IESG
demanded a normative MUST in the Security Considerations section.  Similar
situation and wording here.

Burcak Beser wrote:
> 12. The acknowledgements section is divided into two and gives the
> impression that the DCS team and authors are a disjoint set, which is
> not the case. I would like to see that the real authors of the draft (at
> least Mike Mannette who wrote most of the initial text) should be
> properly acknowledged.

This was discussed in Spring 1999, nearly four years ago, and the agreed
attribution of the co-authors has been maintained.

Burcak Beser wrote:
> 13. Is there a reason for two editors instead of one, as suggested in
> rfc-editor policies (http://www.rfc-editor.org/policy.html).

because there are two editors for this document.  Further, there are
other examples with multiple editors, e.g. RFC3312.


Further, based on comments received from PacketCable MSOs, a new
token value was added to the P-DCS-OSPS header in Section 7, value "RING",
in order to signal a need to perform the Basic-911 operator ringback
function in regulatory environments where it is mandated.

Second, the use of MUSTs in Section 9 for including P-DCS-LAES information
into SIP messages was changed to SHOULD, and an explanatory paragraph
added at the beginning of the section explaining the conditions under
which it is/isn't to be added.

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