[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-dcgroup-sipping-proxy-proxy - notes



When I took this document off the agenda last time, I said I would
give RFC-Editor notes for it next time.  These are the notes.  Some
stuff has Cablelabs agreement, but not all.

I think more will be needed too.  

As to the normative language, I want to argue that it has the scope
of the Applicability Statement and leave it in, even though this is
an Informational and I've added language to help with that.



Proposed New Title: Private Session Initiation Protocol (SIP) Proxy-to-Proxy
   Extensions for Supporting the PacketCable Distributed Call Signaling 
   Architecture

Replace Abstract with:

   In order to deploy a residential telephone service at very large 
   scale across different domains, it is necessary for trusted elements 
   owned by different service providers to exchange trusted information 
   that conveys customer-specific information and expectations about 
   the parties involved in the call. This document describes private 
   extensions to the Session Initiation Protocol (RFC3261) for 
   supporting the exchange of customer information and billing 
   information between trusted entities in the PacketCable Distributed
   Call Signaling Architecture. These extensions provide mechanisms for 
   closed access network coordination to prevent theft of service, customer 
   originated trace of harassing calls, support for operator services 
   and emergency services, and support for various other regulatory 
   issues. The use of the extensions is only applicable in closed
   administrative domains, or among closed federations of administrative 
   domains with previously agreed-upon policies where coordination of 
   charging and other functions is required. 

Replace Applicability Statement with:
The SIP extensions described in the document make certain assumptions 
regarding network topology, linkage between SIP and lower layers, and 
the availability of transitive trust. These assumptions are generally 
NOT APPLICABLE in the Internet as a whole. The use of these headers is only
applicable in closed administrative domains, or among closed federations
of administrative domains with previously agreed-upon policies where 
coordination of charging, call trace, and other functions are required, 
as in for example the architecture presented in [4]. Use outside such a 
domain could result in the leakage of potentially sensitive or private 
information.  User consent to the privacy implications of the policies
in [4] is strongly encouraged in these domains as well.  N.B. Although
RFC 2119 language is used in the document, the scope of the normative
language is only for the area of applicability of the document and like
the technology, it does not apply to the general Internet.


section 5.1: remove "(missing productions can be found in [2])"

section 8.1:
replace 1st definition in BNF with:
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON Billing-Correlation-ID
		SEMI feid-param *(SEMI Billing-Info-param)

insert between 2nd and 3rd definition BNF:
feid-param = "feid" EQUAL LDQUOT FEID RDQUOT

in the remainder of the BNF in this section (8.1)
s/name-addr/LDQUOT addr-spec RDQUOT/g

section 9: P-DCS-LAES and P-DCS-REDIRECT 

add before the first paragraph

NOTE: According to RFC 2804 [add citation to normative references],
the IETF supports documentation of lawful intercept technology if
it is necessary to develop it.  The following section provides such
documentation.  The RFC 2119 language, as stated above, describes
the requirements of the specification only if implemented, and strictly
within the applicability domain described above.  See RFC 2804 for
for description of issues regarding privacy, security and complexity
in relation to this technology.

section 9.1:
in BNF    s/LAQUOT UTI RAQUOT/LDQUOT addr-spec RDQUOT/



section 9.6.1 and normative references:
add citation/reference to REFER method

section 10:  Security Considerations
Change last sentence to read:
Use of TLS and mutual authentication among Proxies and 
Trusted User Agents is REQUIRED.