Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
draft-ietf-sipcore-proxy-feature-12

Note: This ballot was opened for revision 11 and is now closed.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-10-08 for -11)
No email
send info
I have no objection to the publication of this document.

Note that it has become customary to include a reference to the normative definition of the ABNF variant used.

(Stephen Farrell) No Objection

Comment (2012-10-11 for -11)
No email
send info
- Is the consumer of the information in feature-capabilities
well-defined? Is it intended just for the recipient of the SIP
message or is it ok for it to really be intended e.g.  for one
SIP proxy to tell stuf to a downstream proxy but not to the
final recipient? (I may have missed where you said that, in
which case, sorry:-)

The remainder of my comments are really security points, but
given that we're not going to solve e2e (never mind
middle-to-end) security for SIP now, these are just comments.
I'd still be very interested in answers though.

- Are SIP proxies allowed to remove feature capabilities added
upstream? Presumably they MUST NOT re-order them?

- I suspect the last paragraph of section 9 is wishful thinking
at best as it relates to confidentiality. Defining a solution
for middle-to-end or middle-to-middle confidentiality like that
seems like its just not going to happen (and is quite hard in
any case). I think you'd be better to say that you SHOULD NOT
define feature capabilities that need confidentiality that's
better than hop-by-hop as provided by TLS.

- I wondered what'd happen if someone defined a DKIM-like
signature scheme for SIP messages. Has anyone thought about
that?

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Barry Leiba) No Objection

Comment (2012-10-02 for -11)
No email
send info
I have no objection to this document, and no blocking comments.  These are non-blocking, but please consider them, and feel free to chat with me about them:

-- Section 4.2.1 --
   When a SIP entity adds a Feature-Caps header field to a SIP message,
   it MUST place the header field before any existing Feature-Caps
   header field in the message to be forwarded, so that the added header
   field becomes the top-most one.  Then, when another SIP entity
   receives a SIP request or the response, the SIP feature capability
   indicators in the top-most Feature-Caps header field will represent
   the supported features and capabilities "closest" to the entity.

I understand the mandatory ordering, and I'm not asking about that.  But addressing the last point in particular, why is it important to know about supported features and capabilities "closest" to me?  Suppose the entities involved are A -> B -> C -> D, and suppose that A and B put Feature-Caps header fields on but C does not.  Will there be any issue when D sees the field that B put on and "thinks" that it was put there by C?  (I suspect that's not a problem, but I wanted to ask.)

-- Section 5.3.6 --

   If there are specific security considerations that apply to the
   feature capability indicator, the feature capability indicator
   specification MUST document such considerations.

That seems an odd requirement.  If a feature capability indicator specification comes in that has nothing for its security considerations, how does anyone know whether that's because the authors thought that none applied, or that they just decided to skip this item?  Why not just this?:

NEW
   The feature capability indicator specification MUST document
   any specific security considerations that apply to the
   feature capability indicator.

And similarly for Section 5.3.5, about interop considerations.

(Pete Resnick) No Objection

Comment (2012-10-10 for -11)
No email
send info
I find the 2119 keywords in sections 5 & 8 to be completely superfluous. This is about documentation, not about interoperability or network damage. I think they should all be gotten rid of.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection