Subject: [Sip] WGLC comments for draft-ietf-sipping-consent-format-00

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Oct 2006 22:56:01 -0500

Hi,

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?

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Oct 2006 17:22:12 +0300

Hi Ben,

thanks for your comments. Answers inline:

Ben Campbell wrote:
> 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.)

yes, you are probably right. In any case, this is a change we may be
able to do in AUTH48, when all the references have become RFCs. Doing a
global replace should not be a big deal for the RFC editor at that point.

> I am at a loss to understand how transformations would be used at all

I have clarified that point adding the following sentence at the end of
the first paragraph of Section 3:

    However, even though permission documents need to
    have a transformation part to comply to the common policy syntax,
    effectively, permission documents do not make any use of
    transformations.

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

yes. I have clarified it as follows:

   The 'id' attribute in the elements <one> and <except> MUST
   contain a scheme when these elements appear in a permission document.

> does not allow wildcarding of identity.

you are right. The framework disallows to wildcard recipient URIs.
However, in the future, there might be use cases for wildcarded
recipients. Therefore, it seems enough forbidding them in the framework.
No need to restrict the syntax of the document format.

In any case, if you feel very strongly about this, I can add a normative
sentence forbidding them in the format as well.

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

I believe that the paragraph is clear enough: if the signature is
validated, then the identity is the one in the From header field.
Otherwise, the sender cannot be considered authenticated. However, feel
free to suggest how to modify the paragraph if you think it can be
clarified even further.

>> the identity of the sender of the PUBLISH request is equal to the 
> come from a trusted element.

This part of the document describes where to get the identity from when
using different authentication mechanism; not how to use those
mechanisms. Implementors should check the references specifying those
mechanisms to implement them anyway. So, I do not think we need to
clarify how P-Asserted-Identify works even further.

>> the request that is used as input for a translation.  Sender
>> conditions can contain the same elements and attributes as identity
>> conditions.
> 

no, those rules do not apply to senders. In fact, further down in the
same section, the document explains how to compute a URI from an id
attribute in a <one> or <except> element without scheme.

> 
> 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 
> domain parts, rather than just take the AoR URI as a whole?

you are right. I have removed "the user and domain part of"

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

I have removed " the username and domain parts of" here as well.

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

then, no sender will match the <sender> element in the document and the
permission document would be useless.

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

Per my previous email addressing your comments on the framework, I have
clarified that point.

Regarding other schemas, what do you have in mind? Being able to provide
SIP and HTTP URIs seems enough for all practical purposes.

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

Fixed.

I have posted a working version of the next revision of this draft at:
http://users.piuha.net/gonzalo/temp/draft-ietf-sipping-consent-format-01.txt

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Oct 2006 19:23:46 +0300

Hi,

I replied to Ben's email and we ended up in the SIP mailing list, while 
this draft should be discussed in SIPPING. Please, if you have any 
comments, use the SIPPING mailing list instead.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
>>>  that are authenticated using the P-Asserted-Identity mechanism, the 
>>> identity of the sender of the PUBLISH request is equal to the