Requesting Answering Modes for the Session Initiation Protocol (SIP)
draft-ietf-sip-answermode-07

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"?

I agree w/ Lars, WG history not appropriate.

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?

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.

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?