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

[Gonzalo Camarillo <[e-mail]>]

Resending to SIPPING this time.

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
> 


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