On 9/7/12 12:23 PM, Brian E Carpenter wrote:
Please see attached review.
Thank you for the careful review Brian!
I'm going to leave it to Christer to respond to most of your comments.
But I will chime in on a couple of things.
Comment:
--------
I have to say that this is a clear example of intentional feature creep
in an already very complex protocol. I find it scary. I hope the WG has
thought very carefully about the implications for successful interoperability.
There's only a brief mention of this topic (Section 5.3.5).
In future, I'd like to see this sort of document analysed against the RFC-to-be
draft-iab-extension-recs, which is in AUTH48 right now.
That is a nice draft!
SIP already has many extension points. Most of them require standards
action. Now and then, after careful consideration, we add one with
looser requirements. One of those was RFC 3840 which introduced callee
capabilities. That RFC intentionally introduced an a looser extension
mechanism that can work for other SDOs, vendors, and end user
organizations that would not use a mechanism that requires standards
action. In retrospect we could have done a better job on that one - it
allows use of feature tags that were defined for an unrelated purpose,
as well as definition of new ones with minimal semantics.
This draft is related to that. It is desired because of the widespread
use of back to back user agents in sip deployments - entities that were
not anticipated in the design of sip, that introduce new problems.
(Analogous to the problems introduced by NATs.) The earliest versions of
this draft were extensions in the use of that mechanism.
The draft has subsequently been changed (in response to prodding by me
and others) to remedy some of the mistakes we made with 3840. It adds a
specification requirement so that the semantics of proxy feature tags
will always be available. And it only allows use of tags that were
intended to be used with it.
So I think this draft honors draft-iab-extension-recs.
Regarding interop and 5.3.5: This draft introduces a new extension
*mechanism*. Each newly defined tag is independent of all the others. So
interop considerations need to be dealt with separately for each.
I guess this could be more specific about which sorts of things must be
discussed in this section of the profile. E.g.
- that the specification should make provision for its own revision
- what should be done if a sought-after tag is not present
- what should be done if a sought-after tag contains an unexpected value
9. Security Considerations
...
Therefore, mechanisms for guaranteeing confidentiality and
authenticity SHOULD be provided.
Is this SHOULD consistent with SIP in general? It seems to me that
this is a case for "MUST be defined and SHOULD be activated."
This could be better. In general the security of these tags is dependent
on the security of the sip signaling. There is little that the design of
a particular tag can do to improve on this. So for the most part the
issue is to avoid specifying and/or using tags that won't be adequately
secured by the signaling. I think this sentence was trying to address
information that might be carried as the value of a tag. So this would
be a matter of choosing values that don't expose things that ought
remain confidential.
Perhaps Christer will have more to say about this.
Thanks,
Paul
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
