Re: [Gen-art] Re: Gen-ART review of draft-ietf-sip-consent-framework-03

[Gonzalo Camarillo <[e-mail]>]

Hi Vijay,

FYI: I have just submitted a new revision of the draft addressing your 
comments per my previous email (below).

http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-04.txt

Thanks,

Gonzalo


Gonzalo Camarillo wrote:
> Hi Vijay,
> 
> thanks for the comments. Answers inline:
> 
> Vijay K. Gurbani wrote:
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>> Document: draft-ietf-sip-consent-framework-03
>> Reviewer: Vijay K. Gurbani
>> Review Date: 19 Dec 2007
>> IESG Telechat date: 20 Dec 2007
>>
>> Summary: This draft is basically ready for publication, but has nits
>> that should be fixed before publication.
>>
>> Substantive comments are first, followed by nits.
>>
>> - Abstract and S1: The text says that SIP supports communications across
>>    many "media types, including real-time audio, video, text, instant
>>    messaging, and presence."  However, real-time audio, video, text,
>>    IM&P are not "media types" as much as they are models of services
>>    (as defined in rfc4479.)  Consider changing the text in the Abstract
>>    and S1 as follows:
>>
>>      OLD:
>>      The Session Initiation Protocol (SIP) supports communications
>>      across many media types, including real-time audio, video, text,
>>      instant messaging, and presence.
>>
>>      NEW:
>>      The Session Initiation Protocol (SIP) supports communications for
>>      several services, including, real-time audio, video, text, instant
>>      messaging, and presence.
>>
>>    I am aware of all the gyrations we have had on the SIMPLE mailing
>>    list about how to discover services over multiple devices, etc.
>>    However, I believe that we all do agree that real-time audio, video,
>>    IM&P, et al. are services.
> 
> Done.
> 
>>
>> - S3, last paragraph at the end of Page 5: For the sake of
>>    completeness, I would suggest the following modification:
>>
>>    OLD:
>>    Translation operations that result in more than one recipient URI are
>>    a source of amplification.  Servers that do not perform translations,
>>    such as outbound proxy servers, do not cause amplification.
>>
>>    NEW:
>>    Translation operations that result in more than one recipient URI are
>>    a source of amplification.  Servers that do not perform translations,
>>    such as outbound proxy servers, do not cause amplification.  On
>>    the other hand, servers that perform translations (inbound proxies
>>    authoritatively responsible for a SIP domain, for instance) may
>>    cause amplification if the user can be reached at multiple endpoints
>>    (thereby resulting in multiple recipient URIs.)
> 
> Done.
> 
>>
>> - S4.1, third paragraph, last sentence: I think you need to be
>>    careful here because of the normative SHOULD in the preceding
>>    sentence -- is the example simply drawing a parallel to how a
>>    registrar works, or are you saying that a relay functionality
>>    can logically reside at a registrar?  When you defined a Relay
>>    in S2, you did not include a registrar.
> 
> There is a whole section about registrations (S 5.10). Yes, registrars 
> can perform translations.
> 
>> - S4.2, second paragraph:
>>    s/If the answer is positive/If a 2xx-class response is issued to
>>    the MESSAGE request/
> 
> the answer is not the response to the MESSAGE request. It is the user's 
> answer (the user clicks on a URI to grant permission or on another to 
> deny it).
> 
>> - S4.3: The first couple of paragraphs are trying to justify the
>>    existence of store-and-forward servers.  I think the intent may be
>>    a bit clearer if the first two paragraphs are re-written as follows:
>>
>>    When a MESSAGE request with a permission document arrives to the
>>    recipient URI to which it was sent by the relay, the receiving user
>>    can grant or deny the permission needed to perform the translation.
>>    However, the receiving user may not be available when the
>>    MESSAGE request arrives, or it may have expressed preferences to
>>    block all incoming requests for a certain time period.  In such
>>    cases, a store-and-forward server can act as a substitute for
>>    the user and buffer the incoming requests, which are subsequently
>>    delivered to the user when he or she is available again.
> 
> Done.
> 
>> - S4.3: Paragraph three states that "There are several mechanisms
>>    to implement store-and-forward message services..."  Is there an
>>    IETF RFC or I-D that can be referenced here?
> 
> I do not think so.
> 
>> - Figure 4: Should message (3) be shown going from Relay to
>>    "[e-mail]" instead of "B's Store & Fwd server"?  The
>>    accompanying text in S5.3 seems to point this way, as does
>>    the discussion preceding Figure 4 (see S4.2, second paragraph.)
>>
>>    If message (3) is indeed destined to "[e-mail]", then this
>>    begs the next logical question: What if B is not online?  Then
>>    the message has to bounce and be stored on B's S&F server.  You
>>    discuss this aspect later on in S5.5, but I think it ought to
>>    be pointed out earlier.
> 
> yes, we can point it out earlier. I have added text to S.5.3 explaining 
> that B is off-line and that his store-and-forward server takes care of 
> the MESSAGE request until he returns on-line.
> 
>> - S5.4, first paragraph:
>>     s/A permission document is the representation (e.g., encoded in
>>      XML) of a permission./A permission document is an XML-encoded
>>      representation of a permission that the owner of a URI wants to
>>      convey to a relay.
> 
> I would prefer to keep this description of a permission document 
> general. The fact that the only permission document format we have 
> defined is based on XML does not mean that there could be permission 
> document formats based on something else in the future.
> 
>> - S5.4, last paragraph: I think this paragraph is confusing.  With
>>    reference to Figure 4, who is the "Sender"?  Is it [e-mail]?
>>    But the text right above the paragraph says "Identity of the
>>    Sender: Any Sender".  If so, who is to be authenticated?
>>    [e-mail] or anyone that sends a message to the relay?
> 
> If the permission does not identify a particular sender, there is no 
> further authentication requirements on the relay beyond what it normally 
> does. If the permission document identifies a particular sender (e.g., 
> [e-mail]), then the relay needs to make sure that the user sending 
> the request to be relayed to the user is actually [e-mail].
> 
>> - S5.6, first sentence: maybe it is better to say "A recipient
>>    gives a relay..." instead of "A client gives a relay..."  The
>>    discussion in S5.4 centered around recipients granting permissions.
>>    To keep the flow of the document straight, I think it would be
>>    helpful to be consistent on terminology.
> 
> Agreed. Done.
> 
>> - S5.6: while reading the second paragraph of the section, it seems
>>    like the recipient echoes the same permission document back to
>>    the relay.  Is this always the case?  What if the recipient
>>    wanted to modify the document and add/remove URIs to grant/deny
>>    permissions?  Or change the identity of the sender?  Is that
>>    possible?  If so, it may be worth mentioning there.
> 
> No, the PUBLISH or the HTTP GET have an empty body, as stated in the 
> last sentence of the previous paragraph.
> 
>> - S5.9: third paragraph begins with stating that "Relays implementing
>>   this framework and providing this type of ..."  Here, what do the
>>   two instances of "this" refer to: the framework defined in the
>>   draft-ietf-sip-consent-framework-03 itself, or a different
>>   framework to handle URI-list services as described in the second
>>   paragraph, which I believe  corresponds to the work in
>>   draft-ietf-sipping-uri-services-07?
> 
> Changed to: "Relays implementing this consent framework and providing 
> request-contained URI-list services behave..."
> 
>>
>> - Figure 6 is best put at the end of S5.9.1 because that section
>>   and the preceding section describe the behavior depicted in
>>   Figure 6.
> 
> I have moved it there.
> 
>> - In Figure 6, it appears as if the INVITE request consists of
>>   multiple R-URIs (which would be illegal as per the ABNF.)  I
>>   think the intent here is probably to carry the set of URIs
>>   through the recipient-list disposition type specified in
>>   draft-ietf-sipping-uri-services-07.  If so, maybe making this
>>   a bit more obvious in the example may not be a bad idea.
> 
> I have added clarifying text.
> 
>> - S5.10, third paragraph: I think the mention of sip-outbound
>>   muddies up the waters here.  Certainly rfc3261 in and of itself
>>   does not depend on outbound like functionality to be implemented
>>   between a proxy/registrar and a UA.  Why tie outbound to how
>>   a REGISTER transaction is supposed to work in rfc3261?
> 
> Because we received explicit comments about that. The thing is that, if 
> you use outbound, you do not need consent. That's why we call it out 
> explicitly.
> 
>> - S5.10, third and fourth paragraphs: I think you need to make it
>>   more explicit that when using registrations as a mechanism to
>>   inject a recipient URI into a relay, the only way to do so is
>>   through 3rd-party registrations.  Thus, we have to ensure that
>>   3rd party registrations are valid through the return routability
>>   gyrations shown in Figure 7 (i.e., sending a MESSAGE to the
>>   URI in the Contact header of an incoming REGISTER, etc.)  If you
>>   don't make explain the reason for this 3rd-party registration step
>>   in some detail, the nuances on why this is done is perhaps lost
>>   on the reader.
> 
> Could you propose text to make it more explicit? I have read so many 
> times this draft that it looks perfectly explicit to me :o)
> 
>> - S5.10, the paragraph above Figure 7:
>>   s/at the registrar (4)./at the registrar (5)./
>>
> 
> Done.
> 
>> NITS:
>>
>> - In Figure 1, I would put vertical ellipses between the two arrows
>>    labeled "recipient URI".  This is to visually denote that there
>>    are arbitrary many recipient URIs that may result from a
>>    translation.
> 
> I have added [...] between them.
> 
>> - S4.3: s/from day one./from the outset.
> 
> Done.
> 
>> - S4.4: the opening sentence was a bit hard to parse on a quick
>>    read.  I had to re-read it for the sentence to make sense.  I
>>    would suggest that it be re-written as follows:
>>
>>    Permission documents generated by a relay include URIs that can
>>    be used by the recipient of the document to grant or deny the
>>    relay the permission described in the document.
> 
> Changed.
> 
>> - S4.5, last paragraph: s/integrity- protected/integrity-protected/
> 
> Fixed.
> 
>> - S5.3.1, the MESSAGE request shown as beginning on page 14 appears
>>    to be indented incorrectly.  But this may have been intentional
>>    so as to pretty-display the permission document...
> 
> yes, it was intentional. If the RFC editor does not like it, they will 
> change it.
> 
>> - S5.9, third paragraph, second line:
>>   s/different ways as the relays/different ways from the relays/
> 
> I have done s/as/than/
> 
> Thanks a lot for all your comments. I have included them in my working 
> copy of the draft. I am currently discussing with the IESG how to 
> resolve the discusses this document got. As soon as I agree with them 
> how to address their comments, I will revise the draft.
> 
> Cheers,
> 
> Gonzalo
> 
>>
>> Thanks,
>>
>> - vijay
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art