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

[Spencer Dawkins <[e-mail]>]

Hi, Gonzalo,


> Hi Spencer,
>
> Hans Erik responded to your expert comments with the email below. Could 
> you please have a look at it and let the mailing list know whether those 
> changes address your concerns?
>
> Once your concerns are addressed, we will be forwarding this draft to Jon 
> for publication.
>
> Thanks!
>
> Gonzalo

My understanding is that for this type of document, I just need to feel good 
about the checklist questions, right?

I am satisfied with Hans Erik's answers. I don't think it's appropriate for 
me to pursue other changes that aren't required in order to meet the expert 
review criteria.

Thanks,

Spencer

> -------- Original Message --------
> Subject: RE: [Sipping] SIPPING review 
> ofdraft-vanelburg-sipping-served-user-02.txt
> Date: Fri, 12 Oct 2007 15:02:46 +0200
> From: Hans Erik van Elburg <[e-mail]>
> To: Spencer Dawkins <[e-mail]>, <[e-mail]>
> CC: ext Cullen Jennings <[e-mail]>, Jon Peterson 
> <[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
>
>
> 




_______________________________________________
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