Skip to main content

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

Yes

(Robert Sparks)

No Objection

(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

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

Robert Sparks Former IESG member
Yes
Yes (for -11) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-10-08 for -11) Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection (2012-10-02 for -11) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-10-10 for -11) Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-10-11 for -11) Unknown
- 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?
Stewart Bryant Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -11) Unknown