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
"[EMAIL PROTECTED]" 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 PROTECTED]", 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 [EMAIL PROTECTED]
But the text right above the paragraph says "Identity of the
Sender: Any Sender". If so, who is to be authenticated?
[EMAIL PROTECTED] 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: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
