Last Call Review of draft-ietf-sipcore-proxy-feature-
review-ietf-sipcore-proxy-feature-genart-lc-carpenter-2012-09-09-00

Please see attached review.

     Brian


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sipcore-proxy-feature-09.txt
Reviewer: Brian Carpenter
Review Date: 2012-09-07
IETF LC End Date: 2012-09-184
IESG Telechat date: 

Summary:  Almost ready
--------

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.

Major issues:
-------------

None.

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. 

...
>   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.


> 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."

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.