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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Jan 2008 20:04:31 +0200

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
>    "[email-masked]" 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 "[email-masked]", 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 [email-masked]?
>    But the text right above the paragraph says "Identity of the
>    Sender: Any Sender".  If so, who is to be authenticated?
>    [email-masked] 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., 
[email-masked]), then the relay needs to make sure that the user sending 
the request to be relayed to the user is actually [email-masked].

> - 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Jan 2008 20:54:22 +0200

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 31 Jan 2008 13:03:13 -0600

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

Gonzalo: I did receive your earlier email (Jan 22, 2008) on the
initial feedback of my review.  My apologies in not getting back to
you, but I was indisposed during that week.  I have it on my list
of tasks to get back to you.

With the release of -04, I will re-review the -04 version in view
of the email dated Jan 22, 2008.  I will do so next week.

Thank you for attending to my comments.

Regards,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs