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

[Gonzalo Camarillo <[e-mail]>]

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:
> Hi Ben,
> 
> thanks for your comments. Answers inline:
> 
> Ben Campbell wrote:
>> 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.)
> 
> 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.
> 
>>
>> 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.
>>
> 
> 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.
> 
>> 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?
> 
> 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.
> 
>> 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.
> 
> 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.
>>
>> Should we have a normative statement that the signature MUST be
>> 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.
> 
>>
>>> 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.
> 
> 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.
> 
>>
>> 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>
> 
> 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 
>>> 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?
> 
> you are right. I have removed "the user and domain part of"
> 
>>> 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?
> 
> I have removed " the username and domain parts of" here as well.
> 
> 
>> 3.1.2.3
>>
>> 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.
> 
>>
>> 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?
> 
> 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.
> 
>>
>> 4.
>>
>> 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
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 


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