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

["Vijay K. Gurbani" <[e-mail]>]

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.

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

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

- S4.2, second paragraph:
    s/If the answer is positive/If a 2xx-class response is issued to
    the MESSAGE request/

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

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

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

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

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

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

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

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

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

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

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

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

- S5.10, the paragraph above Figure 7:
   s/at the registrar (4)./at the registrar (5)./

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.

- S4.3: s/from day one./from the outset.

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

- S4.5, last paragraph: s/integrity- protected/integrity-protected/

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

- S5.9, third paragraph, second line:
   s/different ways as the relays/different ways from the relays/

Thanks,

- 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


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