Draft:  draft-ietf-sipping-consent-format-00
Reviewer: Ben Campbell [ben@estacado.net]
Review Date: Monday 10/16/2006 10:56 PM CST
Review Deadline: 17 October 2006
Status: WGLC 

Summary: 
This draft is on the right track but has open issues, described in the review. 

General comments:

(editorial) Personal pet-peeve: It is much more friendly to the  
reader to use the form, "...defined in RFCXXX [8]", than to say  
"...defined in [8]." Otherwise they have to keep referring to the  
reference section. I realize that is hard to do with works-in- 
process, but we could use a descriptive name. (I mention this in  
general as it is pervasive to the draft.)

3.

>    This section defines the new conditions and actions defined by this
>    specification.  This specification does not define any new
>    transformation.

I am at a loss to understand how transformations would be used at all  
for this purpose.

3.1.1.

>    The elements <one> and <except> MUST contain a scheme when they
>    appear in a permission document.

We are talking about the "id" attribute in each of those, correct?

Also, is the <many> element permissible in <identity>? I don't  
understand how it would be used, particularly since the framework  
does not allow wildcarding of identity.

> For PUBLISH requests that are
>       authenticated using the SIP Identity mechanism, the identity of
>       the sender of the PUBLISH request is equal to the SIP URI in the
>       From header field of the request, assuming that the signature in
>       the Identity header field has been validated.

Should we have a normative statement that the signature MUST be  
validated?

>    P-Asserted-Identity [5], as described in [9].  For PUBLISH requests
>       that are authenticated using the P-Asserted-Identity mechanism,
>       the identity of the sender of the PUBLISH request is equal to  
> the
>       P-Asserted-Identity header field of the request.

Need to mention the P-Asserted-Identity requires the request to have  
come
from a trusted element.

3.1.2:

>
>    The sender condition is matched against the URI of the sender of  
> the
>    request that is used as input for a translation.  Sender conditions
>    can contain the same elements and attributes as identity  
> conditions.

does this include the same rules about having a scheme in <exception>  
and <one>?

Also, is <many> allowed? It seems to make more sense for <sender>  
than for <identity>

3.1.2.2

>    For requests that are authenticated using SIP Digest, the  
> identity of
>    the sender is set equal to the user and domain part of the SIP
>    Address of Record (AOR) for the user that has authenticated

why not just the whole SIP AoR? That is, why did we mention user and  
domain
parts, rather than just take the AoR URI as a whole?

>    For requests that are authenticated using RFC 3325 [5], the  
> identity
>    of the sender is equal to the username and domain parts of the SIP
>    URI in the P-Asserted-ID header field.  If there are multiple  
> values
>    for the P-Asserted-ID header field (there can be one sip URI and  
> one
>    tel URI [10]), then each of them is used for the comparisons  
> outlined
>    in [8], and if either of them match a <one> or <except> element, it
>    is considered a match.

why do we call out user and domain parts, instead of just
taking the URI as a whole?

3.1.2.3

what are the consequences of being unable to convert the id?

3.2.1:

The use of the transl-handling URIs seems under-specified to me. The
framework document mentions you can send a SIP PUBLISH or an HTTP  
get. In the case
of publish, what do you publish? An empty document? HTTP is easier to  
figure
out, but it is still not explicit. What about other schema?

4.

Should the two <id> elements be <one> elements instead?