[Sipping] Expert review of draft-hautakorpi-sipping-uri-list-handling-refused-02.txt

[Tom Hiller <[e-mail]>]

Hello,

I have been asked to provide an expert review of 
draft-hautakorpi-sipping-uri-list-handling-refused-02.txt.  This draft 
satisfies the requirements of RFC 3427 Section 4.1, as described below.

       -   Tom
 

   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.

I am the designated expert. 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-Refused-URI-List' that identifies a URI-list being refused and 
the list members of the URI-list. The P-Header is only used in a 403 
(Forbidden) response.  The draft does not define new SIP option tags, 
response codes, or methods.


   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 knowledge .


   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 OMA PoC WG requested the 
proposed P-Header to enable a particular PoC session establishment 
involving URI-lists.   In OMA PoC specifications, only one PoC Server (a 
B2BUA) invites PoC users to a PoC Session.  This PoC Server acts as the 
conference focus of the PoC Session, and in PoC parlance, is called the 
"Controlling PoC Server".  When the Controlling PoC Server sends an 
invitation with a URI of a URI-list to a PoC Server able to serve the 
URI-list, that PoC Server must according to PoC specifications refuse 
the invitation with a 403 (Forbidden) response.   This is because in PoC 
specifications only the Controlling PoC Server invites PoC users.  
Because of this, the PoC Session would not be established to the PoC 
users of the URI-list.  

To remedy the situation, the draft defines a new P-Header that allows a 
PoC Server able to serve a URI-list to return the members of the list in 
a 403 response.  Because a 403 response would occur without this 
P-Header, the behavior of SIP is not being altered.   After retrieving 
the members of the URI-list from the 403 response, the Controlling PoC 
Server then invites those members, and the PoC Session subsequently is 
established including the members of the URI-list. 


   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 outlines PoC 
network security assumptions, such as trust between servers, and 
attackers not having access to SIP requests and responses flowing 
between PoC Servers. The draft provides a reference to the OMA PoC 
Architecture Document that specifies OMA PoC network security 
requirements, which do not apply to a general Internet case. 


   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 has an IANA section.

   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 satisfies this requirement:  It contains an applicability 
section that states the number of focuses in a PoC session is one, and 
that special trust between servers, and inaccessibility of SIP requests 
and responses between servers, are needed.  Therefore, the draft is not 
suitable for the general use of SIP in the Internet. 


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

Editorial nits: 
s/Pust/Push/
s/uri lists/URI-lists/
s/URI lists/URI-list/





_______________________________________________
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