Draft:  draft-allen-sipping-poc-p-answer-state-header-03.txt
Reviewer: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com]
Review Date: Friday 4/7/2006 8:21 AM
Review Deadline: 4/18/2006
Status: Expert Review 

Summary: Ready.

I have been requested to perform an expert review, on behalf of SIPPING,
on the following draft:

   draft-allen-sipping-poc-p-answer-state-header-03.txt

The following are my answers to the questions in RFC 3427:

   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 and I am cc:ing the RAI ADs in this email.

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

The reviewed document defines one "P-header" without an option tag,
response code, or method, and therefore satisfies this requirement.

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

The P-Answer-State header field does not appear to relate in any
significant way to any ongoing, planned, or proposed work of the
IETF known to the reviewer, and therefore satisfies this requirement.

    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 proposed header field carries information about whether or not the
user agent server was contacted in order to generate the response that
carries the P-Answer-State header field. Even if having that information
is useful, session establishment proceeds normally in the presence and
in the absence of that header field. Therefore, this header field does
not contradict any normative behavior defined somewhere else.

    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 points out that the information carried by the P-Answer-State
header field is informational in nature and not particularly sensitive.
The Security Considerations Section recommends the use of hop-by-hop
security.

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

The reviewed document is intended to become the informational RFC
required by this consideration. Acceptance of this document for
publication as an informational RFC will address this requirement.

    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 reviewed document contains an applicability statement, which points
out that the P-Answer-State is not suitable for general use on the
Internet because elements are supposed to have trust relationships
between them and have knowledge of the network topology. Those
assumptions do not hold on the public Internet.