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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
