Re: [Gen-art] Gen-ART LC review of draft-ietf-sipcore-proxy-feature-09.txt

[Paul Kyzivat <[e-mail]>]

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