RE: [Sipping] SIPPING review ofdraft-vanelburg-sipping-served-user-02.txt

["Hans Erik van Elburg" <[e-mail]>]

Hi Spencer,

Thanks a lot for performing the review!

Some short response on the expert review comments below:
- On note 2:
There is some indication of the use of this header in clause 5 where it
states that 
"This header field can be added to initial requests routed from an
S-CSCF to an AS
or from an AS to an S-CSCF."
However I think we need to improve this to: 
"initial requests for a dialog or standalone requests".

- On note 3:
This is not yet another identity header being transported end to end. It
is only information shared between a SIP proxy (S-CSCF) and an
Application Server in the IMS architecture, as such it is not another
identity. 

- On note 7:
I quickly glanced through the main MEDIACTRL drafts, but they don't seem
to link in an AS on the dialog between two endpoints. But use a
dedicated dialog between an MS and an AS that manages the control
channel. Therefore I doubt that P-Served-User has application in that
context, I would expect the existing identity mechanisms to be
sufficient. 

Further I have tried to introduce all 3GPP specifics in a way that I
thought understandable to IETF, that is why certain parts are quite
chatty. If I failed there then we need to improve, but it is not yet
clear to me what is not clear.

Response to the other comments can be found inline tagged with
"HansErik:".

I sumitted an 03 version that until it appears on the IETF site can be
found here:
http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user
-03.txt

Best Regards,
/Hans Erik

-----Original Message-----
From: Spencer Dawkins [mailto:[e-mail]] 
Sent: Monday, October 08, 2007 7:53 PM
To: [e-mail]
Cc: ext Cullen Jennings; Jon Peterson
Subject: [Sipping] SIPPING review
ofdraft-vanelburg-sipping-served-user-02.txt

I was asked to provide an expert review for this draft. My review
follows.

The ADs should pay particular attention to notes 3 and 7 below - they
are the requirements I'm still not sure are satisfied.

I also included additional comments for the authors, but these comments
should not be considered part of the expert review.

Thanks,

Spencer

Summary...

1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
       proposal for applicability to SIP and conformance to these
       guidelines.  The Expert Reviewer will send email to the Transport
       Area Directors on this determination.  The expert reviewer can
       cite one or more of the guidelines that haven't been followed in
       his/her opinion.

* Spencer Dawkins is the designated expert. This e-mail is sent to the
SIPPING mailing list. The RAI ADs are copied in this email.

   2.  The proposed extension MUST NOT define SIP option tags, response
       codes, or methods.

* The draft satisfies this requirement: The draft defines a new P-Header
called "P-Served-User" that identifies an IMS Public User Identity.

I should mention that I didn't see any explanation of usage for this
P-Header - is it applicable for all SIP methods? response codes? etc.

   3.  The function of the proposed header MUST NOT overlap with current
       or planned chartered extensions.

* The draft satisfies this requirement to the best of my ability to tell
(although this isn't easy to know for sure because "served user" is only
defined as "IMS Public User Identity of the user" in this specification
- I'm fairly sure that we don't have current or planned chartered
extensions for exactly this, but can't be sure that we don't have
current or planned chartered extensions for anything analogous to this,
and that's the critical question).

I wish this draft did not define Yet Another Identity (as Jeroen pointed
out), but I don't think this concern belongs in my expert review.

   4.  The proposed header MUST be of a purely informational nature, and
       MUST NOT significantly change the behavior of SIP entities which
       support it.  Headers which merely provide additional information
       pertinent to a request or a response are acceptable.  If the
       headers redefine or contradict normative behavior defined in
       standards track SIP specifications, that is what is meant by
       significantly different behavior.

* The draft satisfies this requirement: the P-Served-User header
contains an IMS Public User Identity. This header does not redefine or
contradict normative behavior defined in standards track SIP
specifications.

A proxy or AS might change its behavior based on a difference between
P-Served-User and some other identity, but since conveying the
difference between this the P-Served-User identity and other SIP
identities is the goal for this P-header, this effect seems reasonable.

   5.  The proposed header MUST NOT undermine SIP security in any sense.
       The Internet Draft proposing the new header MUST address security
       issues in detail as if it were a Standards Track document.  Note
       that, if the intended application scenario makes certain
       assumptions regarding security, the security considerations only
       need to meet the intended application scenario rather than the
       general Internet case.  In any case, security issues need to be
       discussed for arbitrary usage scenarios (including the general
       Internet case).

* The draft satisfies this requirement:  The security section describes
the security considerations that apply to insecure network paths and
allows for two methods of securing those paths (physical security and
IPsec). The draft also points out the need to remove these headers at
domain trust boundaries.

   6.  The proposed header MUST be clearly documented in an (Individual
       or Working Group) Informational RFC, and registered with IANA.

* The draft satisfies this requirement:  It is intended to become an
Informational RFC, and lists the header in its IANA section. The IANA
section includes all the information that
http://www.iana.org/assignments/sip-parameters contains for entries in
the header field subregistry.

   7.  An applicability statement in the Informational RFC MUST clearly
       document the useful scope of the proposal, and explain its
       limitations and why it is not suitable for the general use of SIP
       in the Internet.

* The draft may very well satisfy this requirement:  Two points here.

First, I'm reading "in the Internet" as "in non-IMS environments", so
the text that says

   When SIP is used on the Internet, there are typically no proxies
   involving an application server over an ISC interface.  Consequently,
   the P-Served-User header field does not seem useful in a general
   Internet environment.

does make me wonder if similar functionality is useful in non-IMS
environments (for example, MEDIACTRL use of ASs might also find a
similar capability useful).

Second, sections 3.1-3.4 are very dense (a lot of 3GPP-specific call
flows that are mostly the same from scenario to scenario), and I'm not
sure how "clear" this text is to the non-3GPP SIP community that needs
to reach consensus that this P-Header would not be useful in a non-3GPP
environment.

--------------------------------------------------------------

The following notes are included for the draft authors, but aren't part
of the expert review.

1.  Introduction

   The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
   Subsystem) uses SIP (RFC3261 [2]) as its main signalling protocol.
   (For more information on the IMS, a detailed description can be found
   in 3GPP TS 23.228 [8] and 3GPP TS 24.229 [10].) 3GPP has identified a
   set of requirements that can be met, according to the procedures in
   RFC 3427 [5], by defining a new SIP P-header.

Spencer: I am hoping that you're saying "that are most appropriately
met", but (nit) this should probably be "met by defining a new SIP
P-header, according to the procedures in RFC 3427 [5]".
HansErik: Changed accordingly.

Spencer: I note that neither the abstract nor the introduction actually
summarize what that requirement is. Could a one-sentence description be
added?
HansErik: Changed to "3GPP has identified issues with the linking in of
a SIP application server that are most appropriately resolved by
defining a new SIP P-header, 
according to the procedures in RFC 3427 <xref target="RFC3427"/>."
The issue is hinted at in the abstract and is further explained in the
remainder of the document.

   The remainder of this document is organized as follows.  Section 3
   outlines the problem using particular service scenarios and Section 4
   discusses the requirements derived from these scenarios.  Section 5
   defines the P-Served-User header field, which meets those
   requirements, and Section 6 discusses the applicability and scope of
   this new header field.  Section 7 registers the P-Served-User header
   field with the IANA and Section 8 discusses the security properties
   of the environment where this header field is intended to be used.

3.1.  General

   In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves
   as a registrar and handles originating and terminating session states
   for users allocated to it.  This means that any call that is
   originated by a specific user or any call that is terminated to that
   specific user will pass through an S-CSCF that is allocated to that
   user.

Spencer: If this draft can be slightly de-3GPPed, it would be much
easier for the IETF community to understand (and to agree with). Simply
referring to the CSCF as a SIP proxy in many places would be a simple
change, and text like "over the Cx interface" is true but not necessary
for an understanding of this proposed P-header within the IETF. Some
uses of 3GPP terminology in the Abstract and Introduction are useful,
because they provide context for the request.
HansErik: I think that the first sentence of section 3.1 is very clear
in this:
"In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves as
a registrar and handles originating and terminating session states for
users allocated to it. "
I prefer to keep the text as is, I think appropriate clarification is
provided for the IETF community to understand how this is used.


   At the moment that an S-CSCF is allocated for a specific user, a user
   profile is downloaded to the S-CSCF from the HSS (Home Subscriber
   Server) over the Cx interface.  This user profile tells the S-CSCF
   whether the user is allowed to originate or terminate calls or

Spencer: either this is garbled or my English skills have evaporated.
Perhaps "important for this particular document" was cut-and-pasted in
error?
HansErik: I removed the offending fragment. I guess it missed the needed
punctuation. But I agree removing it completely is better.

   important for this particular document whether an AS needs to be
   linked in over the ISC interface.  The user profile information that
   determines whether particular initial request need to be sent to a
   particular AS is called initial Filter Criteria (iFC), see for
   example 3GPP TS 23.218 [7].

Spencer: the previous paragraph has a lot more detail than necessary. Is
this saying more than "When a S-CSCF is allocated for a specific user,
the S-CSCF receives a profile that tells the S-CSCF whether the user is
allowed to originate or terminate calls, or whether an application
server is required"?
HansErik: But the iFC concept is referred to later on, this was a
natural place to introduce it as it is not generally understioiod in the
IETF community. Or do I misinterpret your comment here?

   To be able for an S-CSCF to perform its responsibilities it needs to
   determine on which users behalf it is performing its tasks and which
   session case is applicable for the particular request.  (For session
   case see 3GPP TS 29.228 [11]) The session case distinguishes the
   originating and terminating call cases and whether the particular
   user is registered or not.

   When the S-CSCF determines that for an incoming initial request the
   originating call case applies, it determines the served user by
   looking at the P-Asserted-Identity header field ( RFC 3325 [4]) which
   carries the network asserted identity of the originating user.  When
   after processing the iFC for this initial request the S-CSCF decides
   to forward the request to an AS, the AS has to go through a similar
   process of determining the session case and the served user.  Since
   it should come to the same conclusion that this is an originating
   session case it has to look at the P-Asserted-Identy header field as
   well to determine the served user.

   When the S-CSCF determines that for an incoming initial request the
   terminating call case applies, it determines the served user by
   looking at the Request-URI ( RFC 3261 [2]) which carries the identity
   of the intended terminating user.  When after processing the iFC for
   this initial request the S-CSCF decides to forward the request to an
   AS, the AS has to go through a similar process of determining the
   session case and the served user.  Since it should come to the same
   conclusion that this is a terminating session case it has to look at
   the Request-URI as well to determine the served user.

   In the originating case it can be observed that while the P-Asserted-
   Identity header field just represents the originating user when it
   enters the S-CSCF, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In the terminating case a similar overloading happens to the Request-
   URI, while it first only represented the identity of the intended
   terminating user, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In basic call scenarios this does not show up as a problem, but once
   more complicated service scenarios (notably forwarding services)
   needs to be realised it poses severe limitations.  Such scenarios are
   brought forward in the following sub sections.

3.2.  Diversion; continue on terminating leg, but finish subsequent
      terminating iFC first

Spencer: given that sections 3.1-3.4 are very dense and repetitive, and
you think 3.2 justifies this header, you might either delete the others
or simply list additional scenarios in one paragraph. 
HansErik: I think all the scenarios are needed, allthough they may seem
repetitive all emphasize another crucial aspect of the problem. 3.2
overloading of the Request URI, 3.3 overloading of the
P-Asserted-Identity and 3.4 a non-forwarding scenario that shows that
there are also cases not related to forwarding that are not able to
realize because of P-Asserted-Identity overloading.




_______________________________________________
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


_______________________________________________
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