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