Thanks Martin - more comments inline.
Will you be at the Paris IETF meeting?
On 2/17/12 10:41 AM, [email protected] wrote:
Hi Robert,
thank you very much for the detailed review.
We will provide a new version considering your comments.
Please find already some answers inside.
Best regards, Martin
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]]
Im Auftrag von Robert Sparks
Gesendet: Freitag, 13. Januar 2012 23:41
An: [email protected]; [email protected]
Betreff: [BLISS] AD review: draft-ietf-bliss-call-completion-14
Summary: This document has issues that need to be addressed
before progressing to IETF Last Call.
This document was very difficult to review. Please call out
anyone who provided a substantive review in the document
quality section of an updated shepherd writeup - they deserve
the acknowledgement!
I think there might be places where the structure of the
document became stressed as the design changed over time.
Please consider an editorial pass focusing on organizing the
resulting implementation requirements in ways that are easier
to reference.
Major issues
- The document's proposed use of PUBLISH is not consistent with the
semantics of that method. It attempts to use PUBLISH to affect
the subscription state, not the state of the event being
subscribed to (it's telling that PUBLISHing to this event package
doesn't allow setting the state being subscribed to). Among other
things, this prevents separating the state agent from the state
authority.
The concept is the following: The caller sends it's own status information in
the PUBLISH request. In this case there is no change in the CC monitor (the
queue) state done by the PUBLISH request directly, but either an indirect
change of the state based on the information about the caller status. The CC
monitor acts as a state composer, composing the state of the queue from the
states of the different callers.
This isn't composition. It's conflation of unrelated things. You have an
application that's operating on two unrelated sources of information. If
you really want to use sip events to carry the information about the caller,
you should be considering a separate event package for it. If that feels
wrong, it's another sign that PUBLISH is
not the hammer you're looking for to pound on this particular nail.
Speaking more generally to the events architecture, an element that has
enough information to act as a publisher necessarily has the information
it needs to be able to serve subscriptions directly. It is choosing to
publish to a state agent to deal with matters outside of the contents of
the package itself (not always being connected, having limited
bandwidth, etc.). Even in an idealized presence system where the
ultimate presence document is composed from many contributing
publishers, the individual sources have enough information (and it makes
sense within the definition of the package) to accept subscriptions to
their part of the total state. Further,
subscribing to presence.winfo at the state agent will provide meaningful
data to each of the contributing sources.
The document modifies how PUBLISH identifies the
resource being manipulated by looking at the From URI and not
only at the Request-URI. How the Callee's agent responds to the
request to change this subscription state is underspecified -
when can it reject a request? What is the caller supposed to do
if the request fails?
As mentioned the PUBLISH is not a RPC, the CC agent on behalf of the callee
publishes information about the reachability of the callee for CC recalls. The
monitor composes the state. This state can be used to evaluate if it is useful
to start a CC recall or not.
I think you were still trying to respond to the first point above here.
This is a different question, and will stand independent of what
technique you use to make
the request to change the information about the caller. What happens
when that request needs
to fail (due to parsing, overload, authorization, application-specific
logic, or any of the other reasons
UAS have to reject requests)?
- As written, the first paragraph of section 9.7 asks this package
to violate the basic mechanics of RFC3265. It is a violation of
the architecture to completely ignore the the expiration time
value requested in an initial or refresh SUBSCRIBE request. The
responder may choose an expiration time less than or equal to the
value there. It may not choose a longer expiration time for the
subscription.
Yes this is unclear, what is meant is that the duration in the exoires answer
shall not exceed the remaining CC timer.
- There is some important conversation missing from the security
considerations section.
- The dialog event package requires authentication, and digest
authentication is mandatory to implement. This package
doesn't appear to require any authentication other than
presenting a (possibly well known) URI. More discussion of
the policy for accepting subscriptions is needed to allow
implementers to protect the privacy of the callee. Otherwise,
it becomes trivial to use this package to obtain, for
instance, information about the callee's phone usage.
Similarly, the presence event package has a rich
authorization model, and discusses the security (particularly
privacy) implications of having the authorization settings
too open.
- As written, there does not appear to be any protection
against an attacker causing everyone else that might be in a
queue to be marked not-available, ensuring his call moves to
the front of the queue. He only needs to know the AoRs of the
callers he might be competing with and send PUBLISH requests
with those AoRs in the From header field.
- What keeps a new caller from just adding the m= attribute to
a new INVITE in order to get the preferential treatment by
the network and the callee's UA described in several sections
of the document? Was an approach that used a temp-GRUU
considered instead? It would not have the property of being
as easy to guess as adding an m= URI parameter to an AoR.
As for many mechanisms in the CC draft also here we had to consider the
interworking to the PSTN. There we have only a very basic CC prioritization
indicator in the IAM, saying not much more than 'this IAM is prioritized for
CC'. That's why the callee's monitor MUST record the From URI from the initial
call, to have the chance to check it against incoming INVITEs and verify id
this INV is in fact for CC. Clarifying text for this is needed in the draft.
That clarifying text needs to capture the scenarios above, and answer
the questions. For instance, if there is nothing to keep an attacker
from marking everyone else in the queue as not available, the document
needs to call that out as a security consideration. (I hope this isn't
what the group plans to end with).
- A malicious callee could return several (many) NOTIFYs with
different to-tags, each containing a different cc-URI,
leading the caller to parallel-fork a large number of
subscriptions to a victim.
Some questions
- Section 9.10 calls out that subscribers need to be prepared to
get NOTIFYs from multiple places due to forks in the SUBSCRIBE,
but nothing in the document explores how this affects the
call-completion application. What keeps the following scenario
from occurring: Adam tries to call me, but I'm busy (on my desk
phone). He subscribes for call completion, and the subscribe gets
forked to both my desk and home phone. My home phone is not busy,
so it sends a NOTIFY with "ready" right away. Adam's phone calls
my home phone.
To avoid this situation Adam should add the 'm' (mode) URI parameter, in this
case set to 'BS' (busy subscriber). In this case a CC recall is triggered twhen
a busy condition at a callee UA has ended. Of course this situation also
depends a littlebit on the forking proxy, does it for the initial INVITE send
back the 180 from your home phone (indication CC possible 'NR') and also the
486 (indication CC possible 'BS')? Clarifying text is needed.
- What keeps this from happening? Adam calls and I reject his call
because I'm waiting for another (I press X and the phone just
reports that I'm busy). Adam's phone subscribes for
call-completion and gets a NOTIFY of "ready" - his phone calls
mine again, forcing me to re-reject him. This repeats until I
take my phone off the hook (or engage a global DND) causing me to
not be able to receive the call I was waiting for.
If the callee's monitor does not want to enable the caller to make use of the CC service,
it will not insert a Call-Info header field with "purpose=call-completion" in
the final response message.
Where is the text in the document that defines that behavior?
Of course Adam's phone could try to sunscribe for CC at your phone, but in this
case your phone simply rejects the subscription, which should not affect your
reachability for the call you are waiting for.
Similarly, where in the text is this made clear? It is separable from
the the scenario above - Adam could write a script to subscribe to every
address at an enterprise. What normative text causes all those
subscriptions to be rejected?
- Would a callee ever want to subscribe to call-completion.winfo to
see who's in his queue? Will the current design prevent
implementing a server for call-completion.winfo?
Actually we never discussed this option. We will check it.
Remaining issues (mostly in document order)
- application/call-completion needs to be sent to type review.
- It would be useful to more carefully describe exactly what the
resource being subscribed to.
- Please call out how this document updated 3261 in the
introduction.
- Section 4.2 paragraph 1: Is 100rel required? recommended?
- It's not easy to understand from the text why the subscribing UA
is attempting to subscribe to multiple URIs (the first occurrence
is in 4.2 paragraph 4). Some additional motivating text would
help.
- The document mischaracterizes 'merged' requests as being those
that share the same Call-ID. As Section 8.2.2.2 of RFC3261
defines, it's more than that - the things that have to be the
same are the From tag, Call-Id, and CSeq. This occurs several
places in the document: 6.2 second paragraph, description of
example in section 8, 9.7 third paragraph. It's worth noting that
the UA core in 8.2.2.2 does this merge detection - you are
restating a requirement, not adding one - you should probably
just note that the UA will behave as required by that section of
RFC3261.
- It's worth explicitly calling out (at least in section 6.2) that
you are expecting the subscribing UA to fork its own requests (so
that the merge behavior you are describing can take place). This
means keeping more than the Call-Id constant. An implementer will
have to select or develop a SIP implementation that allows them
to do that.
- There needs to be additional clarity to the specification of the
use of the service-retention indication. What is the caller's
(the subscriber's) endpoint supposed to do differently when it
sees the service-retention option arrive in a NOTIFY? The
difference in the behavior of the callee's system is hard to
extract - the most salient description is the last paragraph of
4.2.
- Section 6.2 first paragraph: m parameter of a SUBSCRIBE SHOULD
match the m parameter passed through the Call-Info header. Why is
this not MUST?
Again because of the PSTN interworking, on TCAP there isn't an equivalent for
all the m-parameter values.
I see there are more questions why there is SHOULD and not MUST. I still have
to check them in particular. But as i said, most of the softening in the draft
is due to enable an interworking with the PSTN CC service. For the latter more
information can be found in ETSI ETS 300 356-18 and ITU-T Q.733.
Please watch for opportunities to make this clear in the text.
- Why does the document specify a request-disposition of no-cancel
for SUBSCRIBE requests? An intermediary cannot send a CANCEL to
forked legs of a SUBSCRIBE request in the first place.
- In section 6.2 paragraph 4, you mean to say the caller's agent
must be prepared to receive multiple NOTIFYs establishing
different dialogs for each initial SUBSCRIBE request it sends. It
is not possible for the agent to receive multiple (final)
responses to the SUBSCRIBE request itself.
- The string 'cc-state' appears for the first time in section 6.3
with no context. The discussion of state before that in the
document is a superset of the states represented with cc-state.
Please at least provide a forward pointer. It would be better to
explicitly describe what cc-state is before you get to this
section.
- The first sentence in section 6.3 is hard to parse. Could it be
broken into more than one sentence? Why are the SHOULDs in this
section not MUSTs?
- In section 7.1, why is the callee's monitor required to send at
least one non-100 provisional (with a Call-Info in it)? Is it
because the final response might not be delivered to the calling
endpoint due to forking. If so, don't you need to require 100rel?
- Why is the SHOULD in 7.1 paragraph 3 not a MUST?
- Why does 7.1 paragraph 4 start "When applicable,"?
Means simply 'if CC is offered'.
- In this version of the document, the last paragraph of 7.1 is the
only definition of the possible values for the m= URI parameter.
It would help to list them with the definition of the parameter
itself.
- The requirements around forking in section 7.2 paragraph 2 belong
in section 9. Why is the requirement to respond with a 482 to all
but one fork a SHOULD and not a MUST?
- Why is the SHOULD in 7.3 paragraph 2 not a MUST?
- Subsections of Section 7 use SHALL instead of MUST - it would be
better to be consistent throughout the document.
- In 7.4 paragraph one, where you say "if the CC call fails", it
would be better to say "if the CC call is not accepted". The call
could fail without the callee's monitor seeing any of the
signalling.
- In 7.4 paragraph 1, last sentence, in what circumstance would the
callee's monitor NOT terminate the relevant subscription?
I think this SHOULD should or better must be a MUST.
- 7.4 paragraph 2 (which assumes the UA can only handle one call at
a time) should be made consistent with 7.3 paragraph 3 (which
allows UAs that can support multiple calls)
- 7.6 paragraph 1 says "SHALL process the queue as described in
subclause 7.3". But 7.3 does not talk about processing queues.
- In the example, you show a 487 to the invite and motivate it by
some proxy having generated a CANCEL. That proxy would have
received a 487, but assuming it got no better responses from any
other leg, it would most likely send a 480. If there weren't
intervening proxies, the response might be one of several
400-class responses (perhaps a 408). Please call out that there
may be many variations in this failure response.
- Proxies will not aggregate Call-Info header fields from multiple
final responses into the response they send upstream. In a
general deployment, the only time you will see that the callee
supports call-completion (at least given how the capability is
signaled in this document) is if it's final response is chosen as
"best" by every proxy in the chain. It's worth pointing out that
some 4xx responses from the callee's UA are more likely to be
chosen as "best" than others. It's also probably worth pointing
out that in in situations like you allude to in the example in
section 8, when proxies cancel legs, the 487 they stimulate from
the callee's UAs are not likely to be chosen as "best".
Text for forking proxies need, s.a.
- The third paragraph of section 9.4 is very unclear. I can't parse
the first sentence at all. In the second sentence, it might be
clearer to say "can never" instead of "cannot" (assuming my guess
at what the paragraph is trying to say is correct). The third
sentence doesn't make sense, and I wonder if the text matched a
previous design better? Moving between available and
not-available (using PUBLISH) doesn't affect the subscription
duration - what is the sentence trying to talk about when it
mentions granting a duration as part of resuming a subscription?
For example if it is clear that you leave your office latest at 8 in the
evening, and a subscription for CC arrives at your desk phone at 7:45, expires
set to 1 hour, expires in the response should be set to 15 minutes.
- Section 9.5 third paragraph points to a format described in
section 8. It means to point to section 10.
- The description of NOTIFY bodies in section 9.5 allows bodies of
type application/sdp to be sent in notifies as long as that type
occurs in the Accept header field of the most recent SUBSCRIBE
request on the dialog. Is that intentional?
- Section 9.6 is vague about a call-completion service specific
timer. It points into 9.4 claiming the timer is described there,
but 9.4 is talking about subscription duration, only noting that
the duration default value is chosen based on a timer value from
other specifications. Why is this MAY important? What are the
implementations supposed to do with this implication?
- In the second paragraph of section 9.7, should the 480 include a
retry-after? Why was 403 chosen for long-term-denial _error_
situations. Why isn't that a 500?
- The first sentence of section 9.8 would be much more effective if
it said (or pointed to text that describes) what the event
triggering conditions actually are.
- The third paragraph of section 9.8 has a MUST requirement that is
conditional on an agent initiating an INVITE "promptly", but
there's no characterization of "promptly" in the document. How
does it account for the time it takes to reconfirm the caller is
actually present and available before initiating the INVITE due
to a recall? (This should also be accounted for in the first part
of the security considerations).
- Section 9.9 (corresponding to section 4.4.8 of RFC3261) is not
adequate. It needs to actually describe the package specific
subscription processing (including how the state is built), or
provide a finer reference to where that specification lies than
"in this and possibly in other documents". Section 7 has most of
this information, but it's fairly widely scattered. Please
consider consolidating the normative behavior into one place.
- Section 9.11 claims the service typically involves a single
notification per notifier per subscription. This cannot be the
case. There will typically be three - the initial notify in
response to the subscribe request, the notify representing the
state transition from queued to ready, and the notify
corresponding to the termination of the subscription. (It is not
clear from the document when you expect the notification of
"ready" to immediately terminate the subscription, if ever.)
- The timing restrictions in section 9.11 seem artificial, and
interact badly with the application this package is intended to
support (the implication is that the server should delay send a
"ready" for example). Can the document explain how these
restrictions were chosen?
- Why does the call-completion information format make a provision
for X- headers since you ignore lines with unknown names?
- Instead of saying "Two lines with the same name MUST NOT be
present, except where specifically permitted", consider saying
"The header lines defined in this document can occur at most once
in any given call-completion document. Extensions must define
whether defined lines may occur more than once. How likely is
this format to be extended? Do these need to be put in a
registry?
- Why does the syntax for cc-URI allow cc-URI header line
parameters? You certainly want the URI to be able to contain URI
parameters, but when would you ever use the header line
parameters? What you have now allows
cc-URI: random display text
<sip:name@domain;uri-param=uri-value>;cc-uri-header-param-name
=cc-uri-header-param-value
How is having that display text ever useful? When would
you every use
a cc-uri-header-param? In other words, why isn't this simply
cc-URI = "cc-URI" HCOLON addr-spec?
- Item 2 in the security considerations section is unclear. It
seems to be placing a requirement on the subscriber (the caller),
but it's not clear what that requirement is (don't suspend any
subscriptions longer than a typical call? than some duration a
user entered for _this_ call? or what?). What's the subscriber
supposed to do if it would have suspended a subscription that
long - terminate the subscription? How does this protect the
privacy of the callee?
- The media-type form sections should point to specific sections in
this document. Consider calling out the most important
interoperability and security considerations.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
