Draft:  draft-ejzak-sipping-p-em-auth-00.txt
Reviewer: Aki Niemi [aki.niemi@nokia.com]
Review Date: Wednesday 4/12/2006 5:06 AM
Review Deadline: 4/18/2006
Status: Expert review

Summary:  This draft is basically ready for publication, but has nits that should be fixed before publication. 

Review:
-------
I was asked to make an expert review of
draft-ejzak-sipping-p-em-auth-00.txt. Please see below.

ADs are also CC'd, as instructed by RFC 3427. I'm also citing the
relevant portions of that RFC as reference.

   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.

Yours truly.

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

Check; defines a single P-header field.

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

The proposed mechanism in this draft relates to early media, specified
in RFC3959 and RFC3960. But it is an orthogonal mechanism to early media
as such, being that it is solving the authorization issue of
(bidirectional) early media also mentioned in the Security
Considerations of RFC3959. Therefore there is no overlap, AFAICS, to
existing or planned chartered extension work in SIP.

   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.

Strictly speaking, the behavior of SIP entities is not altered, but the
extension serves as an indication to controlling related media session
gating. Therefore this extension isn't contradicting #4.

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

Check. The draft is explicitly scoped for systems where RFC3325 security
model based on transitive trust applies. In such scenarios, the security
properties are not affected by the proposed mechanism.

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

The ABNF of the extension header field is defined, but the IANA
considerations section is missing.

   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 applicability statement does state that the extension is not
suitable for the Internet at large, but is only intended for specialized
deployments that have the RFC 3325 security and trust model. However, it
doesn't go into details as to what are the exact reasons this mechanism
couldn't have wider applicability. I suspect many of those reasons have
to do with coupling of signaling and media resources, and especially the
charging model of those media resources. Since this coupling can not be
made in the general case, the authorization decisions can not be made
based on signaling alone.

So in conclusion, it seems this proposed extension is in line with the
criteria of RFC 3427. The only thing missing is the IANA considerations
section, which should make a registration of a new SIP header field.

As a side comment, the draft also doesn't explain what would happen in a
scenario where early media is not allowed, indicated by "P-Early-Media:
inactive", and is therefore gated off; yet the UAC doesn't support the
proposed extension. How does it handle getting silence while expecting
early media?

Also a nit: the short draft title says P-Early-Media-Auth, but the
header field is called P-Early-Media.