The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular
draft-allen-sipping-poc-p-answer-state-header-05

[Ballot discuss]
This document defines a private-use SIP header for the OMA community.
  Why is it intended for an Experimental RFC?  Aren't such document
  generally published as Informational RFCs?

IANA Last Call Comment :

Upon approval of this document, the IANA will make the
following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters
in sub-registry "Header Fields"

Header Name | Compact | Reference |
P-Answer-State | | [RFC-allen-sipping-poc-p-answer-
state-header-04]

We understand the above to be the only IANA Actions
for this document.

Expert Review (Gonzalo)

>> 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.
>>
>>
>> Gonzalo Camarillo
>> Designated reviewer for draft-allen-sipping-poc-p-answer-state-header-03.txt
>>