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

[Brian E Carpenter <[e-mail]>]

Thanks, Christer and Paul. Your proposed changes seem fine to me.

Regards
   Brian

On 10/09/2012 10:45, Christer Holmberg wrote:
> Hi Brian,
> 
> Thanks for your review! Comments inline (<christer></christer>).
> 
> (I also include Paul's comments)
> 
> 
>> 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.
> 
> <paul>
> 
> 	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.
> 
> </paul>
> 
> <christer>
> 
> 	I have nothing to add to Paul's reply regarding this issue.
> 
> </christer>
> 
> 
> 	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
> 
> </paul>
> 
> <christer>
> 
> 	I could extend the paragraph:
> 	
> 	"If there are specific interoperability considerations that apply to
>    	the feature capability indicator, the feature capability indicator
>    	specification MUST document such considerations.
> 
> 	Interoperability considerations can e.g. include procedures related
> 	to cases where an expected feature capability indicator is not present, 
> 	or where it contains an unexpected value."
> 
> </christer>
> 
> 
> 
> -------------------------------------------------
> 
> 
>> Minor issues:
>> ----------------
>>
>> 4.2.1.  General
>> ...
>>   NOTE: It is not possible to, as a Feature-Caps header field value,
>>   convey the address of the SIP entity that inserted the Feature-Caps
>>   header field. 
>>
>> I cannot parse this sentence. Does it mean this?
>>
>>   NOTE: A Feature-Caps header field value cannot
>>   convey the address of the SIP entity that inserted the Feature-Caps
>>   header field. 
>>
>> Or does it mean?
>>
>>   NOTE: A Feature-Caps header field value MUST NOT
>>   convey the address of the SIP entity that inserted the Feature-Caps
>>   header field. 
> 
> <christer>
> 
> 	The *first* alternative. I can replace the current note text with your suggested text.
> 
> </christer>
> 
> 
> -------------------------------------------------
> 
> 
>>   For a given fc-value, as defined in section 5.3.1, feature capability
>>   indicators are listed in a non-priority order, and any order of the
>>   listed SIP feature capability indicators have the same meaning.
>>
>> This is very hard to understand. Does it mean this?
>>
>>   For a given fc-value, as defined in section 5.3.1, the order in which
>>   feature capability indicators are listed has no significance.
> 
> <christer>
> 
> 	Correct. I can replace the current text with your suggested text.
> 
> </christer>
> 
> 
> -------------------------------------------------
> 
> 
>>> 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."
> 
> <paul>
> 
> 	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.
> 
> </paul>
> 
> <christer>
> 
> 	(The SHOULD is taken from RFC 3840.)
> 
> 	In some cases the information itself might not be confidential, e.g. because the procedures associated with the feature
> 	will ensure that non-authorized users are able to use the feature.
> 
> 	Maybe we could say something like:
> 
> 	"Therefore, if the feature capability indicators provide sensitive information, mechanisms for guaranteeing confidentiality 
> 	and authenticity MUST be provided."
> 
> </christer>
> 
> 
> -------------------------------------------------
> 
> 
>> Nits:
>> -----
>>
>> I don't think that the labels "Figure 1" to "Figure 6" are useful.
>> They are not referred to in the text, and they distract the reader.
> 
> <christer>
> 
> 	I can remove the labels.
> 
> </christer>
> 
> 
> -------------------------------------------------
> 
> 
> Regards,
> 
> Christer
> 
> 
>