Subject: [BLISS] draft-ietf-bliss-call-park-extension-01.txt

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 19 Feb 2010 12:45:49 -0500

This is both my personal review of this draft [1], and a question with
my WG Chair hat on for both the author and the working group.

First, my question as WG Co-Chair...

  This draft has a nice section on how some existing implementations
  work, and some descriptions of a couple of different call flows for
  different deployment environments and/or sets of user expectations
  (for example, whether park orbit identifiers are allocated by the
  parking UAC or by the park service and whether those identifiers
  need to be human-friendly or not).

  Should the goal of this document be to establish a set of call
  flows, including what methods are used and how addressing works so
  that any implementation using those mechanisms can interoperate with
  any other?

  If so, if there are alternative flows (as in the existing document),
  should it be a goal that the SIP clients and servers can detect
  whether or not they are using the same choices?  Should there be
  identifiers for the choices, and if so where would those identifiers
  be used?

  If it is not a goal of this document to establish such a set of
  flows to be used by future implementations, then what is it?

My personal review of the draft...

  This review should be understood in the context of my personal
  (individual contributor) answers to the questions above:

    - The goal of the draft should be to document a (small) set of
      alternative flows that meet the described sets of expectations.

    - It should be possible for an implementation, given only a
      request or response from its peer, to detect whether or not the
      peer is expecting to use the same flow the implementation is
      attempting to use.

    - There should be a set of labels to identify the alternatives.
      These need not (prefereably should not) appear in any SIP
      message, but should be availble for example for implementers to
      use when creating configurations.

  Given the above, I think that the Abstract should be modified to
  clearly state the goals (those, or perhaps others); the current text
  doesn't set out goals clearly enough that one can tell whether or
  not the draft has acheived them.

  I think that the draft needs a tighter set of descriptions of what
  sets of user experiences it is meant to cover.  Then each proposed
  flow should reference those descriptions to make clear which flow(s)
  are appropriate to which kinds of deployments.

    Yes, I know that the old (existing) charter says you're not
    allowed to define features, but I think that's silly (and is why
    the new proposed charter [2] doesn't say that).  If you disagree
    with me on this, please start a new thread to discuss that.

  The descriptions of the flows need to be tightened up considerably.
  They should not rely on any understanding of the flow in RFC 5359
  section-2.15 [3], because any new description should be
  understandable on its own.  I think this draft should itself be a
  BCP and normatively Update that RFC, replacing that section [which I
  think is somewhat underspecified too).

  One thing that both this flow and the 5359 flow do is send the REFER
  from the parking UAC to the Park Service, with a Refer-To and
  Replaces parameter identifying the call to be parked.  Neither spec
  (as far as I can find) make clear what address should be used in the
  Refer-To header for the party to be parked - an AOR from the To/From
  header, or the Contact address?  In many situations, one or the
  other may not be routable, especially in the absence of the route
  set from the dialog.  The draft offers the explanation that this
  avoids any reliance on parked party to correctly handle an orbit
  parameter.  Personally, I don't think there's any alternative to
  allowing Route header parameters somewhere, and yes, I think that's
  a bug in RFC 3261 (yes, I know about gruu, but until everyone does
  them they don't solve the problem, and sometimes not even then).

  One of the more important difference between the offered flows is
  which parties send an 'orbit' parameter in requests and responses.
  It seems to me that it should be possible to nail that down so that
  the presence or absence of an orbit parameter can be used by each
  party to understand the expectations of the other.  Granted, in some
  cases (such as the parker expects the service to allocate the orbit and
  the service needs the parker to do it) this produces only an error -
  but at least it could be an error that spells out what the problem
  is.

 Editorial Nit:

    Abstract: "[...] approaches can be Taken, [...]"
       'Taken' probably shouldn't be capitalized.

[1] http://tools.ietf.org/html/draft-ietf-bliss-call-park-extension-01
[2] http://svn.resiprocate.org/rep/ietf-drafts/lawrence/bliss-charter/charter.txt
[3] http://tools.ietf.org/html/rfc5359#section-2.15