[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-dcgroup-sipping-proxy-proxy - notes
- To: iesg@ietf.org
- Subject: draft-dcgroup-sipping-proxy-proxy - notes
- From: Allison Mankin <mankin@psg.com>
- Date: Wed, 19 Feb 2003 10:36:05 -0800
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.