Requesting Answering Modes for the Session Initiation Protocol (SIP)
RFC 5373

[Ballot discuss]
I am unpersuaded that the text adequately differentiates the behavior of a UAS receiving an Answer-Mode header versus a Priv-Answer-Mode header. I think the argument in 4.3.2 greatly suffers for not mentioning the use of the 'require' parameter to "Auto" and "Manual". The best description of the motivation for Priv given in 4.3.2 is:

  This distinction is what allows the fleet operator to make
  polite (Answer-Mode: Auto) requests to Larry under normal conditions,
  and receive different handling (Priv-Answer-Mode: Auto) for a request
  having greater urgency.

I would have thought that "Answer-Mode: Auto" would be polite and "Answer-Mode: Auto;require" would be insistent. If Larry has fallen asleep, and the dispatcher wants to contact him, how would Larry's UA behave differently if it received an INVITE with "Answer-Mode: Auto;require", as opposed to "Priv-Answer-Mode: Auto;require"? In both cases, the UAS will authenticate the UAC. In both cases, the UAS will make a policy decision to determine whether or not the caller is authorized to invoke this feature. If they are, then the feature will be invoked and the call will be answered automatically. If not, then a 403 will be sent in the backwards direction. So what's the difference? In either case, there needs to be something configured in Larry's UA that says "if this is the caller, then you have to honor their 'require'". So how does the "Priv-" prefix alter the logic that the UA performs? 4.3.2 needs to explain, basically, what semantics you would need to add to 'require' such that "Answer-Mode: Auto;require" means the same thing as "Priv-Answer-Mode: Auto;require".

It's clear that the draft assumes that UAs have multiple levels of policy, some policy set by users (like Larry) and some policy set by administrators (like Larry's dispatcher). Even granting that (and it isn't especially plausible), it isn't clear that you need a "Priv-" clue in the message to inform the UA where it needs to look for policy information, unless the administrators want to have multiple "polite" ways of sending requests. Look at it this way: if Larry's dispatcher can't just send an INVITE with "Answer-Mode: Auto;require" because that means that Larry's personal policies (as opposed to the dispatcher's corporate policies) might result in the rejection of the request, then what's the difference between Larry's dispatcher sending "Answer-Mode: Auto" and "Answer-Mode: Auto:require"?

Either way, it looks to me like some element of this protocol is redundant. 4.3.2 really needs to describe what role the 'require' flag plays in describing a request as urgent or polite when "Priv-" enters into the equation.

[Ballot comment]
I wonder why RFC3325 is an Informative Reference but RFC4474 is a Normative Reference? Well, actually, I don't wonder, but to make a long story short they should both be Informative.

I found the problem statement of 4.2.2 compelling, but the proposed solution in the last sentence of the second paragraph pretty vacuous. How is a UAC or UAS supposed to ascertain that it is in an "environemnt" which "includes" parallel forking? Or to put that in plainer terms, is this mechanism applicable only to environments in which parallel forking can be prohibited?

[Ballot comment]
The following text has a nasty typo:

  This document defines two SIP extension header fields, "AnswerMode"
                                                          ^^^^^^^^^^
  and "Priv-Answer-Mode".  These two extensions take the same
  parameters and operate in the same general way.

I believe that should be "Answer-Mode"
                                ^

I found the discussion of WG history harmless and the technical
content of that discussion was helpful to understand the context
and scope of this specification.  If the authors choose to remove
mention of the WG history, please do not remove the design rationale
and scope.

The ABNF in section 2 does not mention that it imports the ABNF
rules for "SEMI", "HCOLON", "token" and "generic-param" come from
another specification (3261?).  Folded lines need leading whitespace to
comply with RFC 4234.

Shouldn't the "require" parameter be registered in the SIP Header
Field Parameters registry in addition to "Manual" and "Auto"?

[Ballot discuss]
draft-ietf-sip-answermode-04.txt

  Based on the Gen-ART Review by Suresh Krishnan.

  In Section 4, the following text does not look right. The client and
  server roles have been reversed:
  >
  > Each value of the Answer-Mode or Priv-Answer-Mode header field can
  > include an optional parameter, "require".  If present, this parameter
  > indicates that the UAS would prefer that the UAC reject the request
  > if the UAC is unwilling (perhaps due to policy) to answer in the mode
  > requested, rather than answering in another mode.

[Ballot comment]
Section 1., paragraph 0:
> 1.  Background

  Personally, I don't feel that including WG history in RFCs is
  appropriate, given the ephemeral nature of WGs. Timelines of events
  and decisions are almost never a good way to present technical
  subjects.

[Ballot comment]
Section 7.3 establishes directionality policy classes for inbound and outbound flows.  Request identities for each directional flow are divided into (1) explicitly authorized, (2) explicitly denied, and (3) user decision required.  The specification models bidirectional flows as the "worst case" sum of the risks for inbound and outbound flows. 

It is unclear to me whether modeling bidirectional flows as the sum of the directional flows is appropriate.  For a bidirectional device, the set of identities in each class is not entirely independent, as this would seem to imply.  As written, it is clearly possible to construct scenarios where the bidirectional flow is in conflict; that is, the same identity could be explicitly authorized for inbound flows and explicitly denied for outbound flows.  I can justify a scenario where inbound is authorized and outbound requires a user decision, but not authorized and denied for the different directional flows.

Am I missing something here?  And did the wg consider modeling bidrectional flows as a unique policy class?

[Ballot discuss]
This DISCUSS is a placeholder for the resolution of issues raised Sandy Murphy's secdir review.  The reviewer and editors have agreed on a proposed resolution for all the issues she raised, so this is simply procedural, and I will clear when a new draft with the appropriate text is submitted.

IANA Last Call Comments:

Action #1 (section 8.1)

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

sub-regisry "Header Fields - per [RFC3261] Section 27.3"

| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| Answer-Mode | | [RFC-sip-answermode-04] |
| Priv-Answer-Mode | | [RFC-sip-answermode-04] |
+------------------+--------------+-----------+



Action #2 (section 8.2)
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

sub-regisry "Header Field Parameters and Parameter Values - per [RFC3968]"

| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| Answer-Mode | Manual | No | [RFC-sip-
answermode-04] |
| Answer-Mode | Auto | No | [RFC-sip-
answermode-04] |
| Priv-Answer-Mode | Manual | No | [RFC-sip-
answermode-04] |
| Priv-Answer-Mode | Auto | No | [RFC-sip-
answermode-04] |
+------------------+----------------+-------------------+-----------+


Action #3 (section 8.3)
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

sub-regisry "Option Tags - per [RFC3261] Section 27.1"

| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| answermode | This option tag is for support of the | [RFC-sip-
answermode-04] |
| | Answer-Mode and Priv-Answer-Mode | |
| | extensions used to negotiate automatic | |
| | or manual answering of a request. | |
+------------+------------------------------------------+-----------+


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

PROTO Write-up

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Document history:

- draft-allen-sipping-poc-p-headers-00 created November 2004, expired
May 2005.
- draft-allen-sipping-poc-p-headers-01.txt created February 7th 2005,
expired August 8th 2005 (split into two drafts, the one below and a
separate P-header draft which remained in SIPPING).
- draft-willis-sip-answeralert-00 created June 14th 2005, expired
December 16th 2005. Discussed at IETF#63.
- draft-willis-sip-answeralert-01 created August 31st 2005, expired
March 4th 2006. Discussed at IETF#64.
- draft-ietf-sip-answermode-00 created December 14th 2005, expired June
17th 2006.
- draft-ietf-sip-answermode-01 created April 3rd 2006, expired October
3rd 2006.
- draft-ietf-sip-answermode-02 created March 4th 2007, expires
September 5th 2007.
- draft-ietf-sip-answermode-03 created May 10th 2007, expires November
11th 2007.
- draft-ietf-sip-answermode-04 created June 12th 2007, expires December
14th 2007.

WGLC was initiated on draft-ietf-sip-answermode-00 on 23rd February 2006 with
comments requested by 15th March 2006.

Reviews were conducted by and comments received from Hans Persson, Jeroen
van Bemmel, and Paul Kyzivat. At least 5 other people commented on earlier
versions of the document.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document defines mechanisms that are entirely internal to the Session
Initiation Protocol (SIP). The document shepherd considers that no external
review from an external specialist is necessary.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

The document defines a new SIP protocol extension for a particular purpose
in a form that has been used for many other extensions. The document
shepherd has no concerns with the document.

There have been no IPR disclosures on this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Section 1 of the document represents the background to the initiation of
this work, and details a strong requirement from OMA for a SIP solution in
this area. However uses in the SIP WG were found for a more general
mechanism. Less generic parts of the original proposal form the basis of a
separate draft draft-allen-sipping-poc-p-answer-state-header-04 being
progressed under the rules of RFC 3427 as a P-header.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None indicated.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document has been reviewed against the guidelines in RFC 4485 and it is
believed that the document is conformant with those guidelines.

While the document defines new SIP headers and a new SIP option tag, these
have been performed as a SIP working group item, and therefore this draft is
in conformance with RFC 3427.

For ID-NITS (idnits 2.04.09) the checks report no errors.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and informative
references. All the normative references are now published RFCs. There are
no downward references.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

Section 8 of the document contains the IANA considerations.

Section 8.1 of the document registers the two new SIP header fields that are
defined elsewhere in the document. This registration is consistent with RFC
3968 which defines the registry and is also consistent with the current
format of the registry.

Section 8.2 of the document registers two new header field parameters for
the new Answer-Mode header field, and which are defined elsewhere in the
document. Section 8.2 of the document also registers the same two new header
field parameters for the new Priv-Answer-Mode header field, and again these
are defined elsewhere in the document. This registration is consistent with
RFC 3968 which defines the registry and is also consistent with the current
format of the registry.

Section 8.3 of the document registers a new option-tag; the new option-tag
is defined elsewhere in the document. This registration is consistent with
RFC 3968 which defines the registry and is also consistent with the current
format of the registry.

It has been checked that there are no other protocol elements requiring
registration.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Section 3 of the document specifies the new headers in ABNF. This ABNF
passes the checks in http://rtg.ietf.org/~fenner/abnf.cgi.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Technical Summary

This document defines extends SIP with two header fields and associated
option tags that can be used in INVITE requests to convey the requester's
preference for user-interface handling related to answering of that request.
The first header, "Answer-Mode", expresses a preference as to whether the
target node's user interface waits for user input before accepting the
request or instead accepts the request without waiting on user input. The
second header, "Priv-Answer-Mode" is similar to the first, except that it
requests administrative-level access and has consequent additional
authentication and authorization requirements. These behaviors have
applicability to applications such as Push-to-Talk and to diagnostics like
loop-back. Usage of each header field in a response to indicate how the
request was handled is also defined.

Working Group Summary

There is consensus in the working group to publish this document. The
proposal was originally submitted as a P-header, but it was decided that
this aspect should be brought out and made generally applicable to all SIP
implementations. Early concerns about the possibility to use the header as a
means of eavesdropping have been addressed in the security considerations.

Document Quality

There has been no indication of implementation. The document has been
required in support of the OMA PoC feature, and it can be assumed that there
have been implementations of the OMA work that have therefore used this
feature.

Personnel

The document shepherd for this document was Keith Drage. The responsible
Area Director was Cullen Jennings. The IANA Expert(s) for the registries in
this document are .