Completion of Calls for the Session Initiation Protocol (SIP)
draft-ietf-bliss-call-completion-19

[Ballot comment]
This is a well-written document specifying a useful protocol; thanks.  The -19 version addresses all the issues and questions I had.

Because there was a gap in IANA's action list on their review -- a gap which has since been clarified with them -- I urge the authors to be especially careful to review IANA's final actions after the document is approved, and be sure that all five actions are correct.

[Ballot comment]
I was worried that a caller could dominate a callee's call completion queue, but Robert's convinced me it's probably not that big of a deal.  But, what about adding some text about repeated call cases and that agents shouldn't subscribe again when they already have a subscription. (or is it in there and I missed it)

[Ballot comment]

Only the first of these is (maybe) really a deal:

- I wondered about the duration of state here. E.g. if the
callee's monitor could get a caller's UA to maintain state for
a long time then the callee could track the caller's presence.
I think you should note that in the security considerations. Or
maybe it'd be better if the caller's agent had to have some
kind of limit after which subscriptions are definitely
terminated. (You do recommend an hour, but that's not quite the
same.)

- I wondered about authentication here and the possibility to
get someone else billed for something. Does CC open up any new
ways to do that? Say if hop-by-hop authentication is in use,
but someone uses a credential that gets revoked - could CC
happening after the revocation incur costs on someone wrongly?
I suspect these are all existing issues or trivial corner cases
that don't warrant a mention but just wanted to check.

- In section 9 the term "notifier" confused me. I guess it'd be
clear to SIP folks, but it might be good to say here who that
is somewhere in section 3.

- 6.2, typo: s/SHOULD presented/SHOULD be presented/?

- 9.4, typo: s/after certain/after a certain/?

- 11, typo: s/DoD/DoS/

[Ballot comment]
Two very minor points.

Acronym: while UA, UAC, and UAS might be known in the SIP world, I had to look up the AOR acronym.

4.4. Differences from SS7

    SIP call completion differs in some ways from the CCBS and CCNR features of SS7 (which is used in the PSTN).
    For ease of understanding, we enumerate some of the differences here.

From the 3 following paragraphs, it's not too clear where the differences are since don't speak about SS7 at all.

[Ballot discuss]
This is a well-written document specifying a useful protocol, and I'll be happy to switch to a "Yes" ballot after a couple of easy issues are taken care of.

-- Section 5 --

  The callee's monitor MUST select for recall only CC requests with a
  CCE's availability state 'available', and for which the callee
  appears to be available when considering the 'm' value of the CCE.

This sort of sentence construction, using 2119 "MUST" in this way, is often confusing.  Please re-word this to make it clear what's intended.  I will suggest one of these these, depending upon what you intend and assuming that I'm reading the intent right (if neither of these is correct, I suppose that's additional evidence that it's unclear):

NEW-1
  A CC request is eligible for recall only when its CCE's availability
  state is "available" and the "m" value of the CCE also indicates an
  available state.  The callee's monitor MUST NOT select for recall
  any CC requests that fail to meet those criteria.

NEW-2
  A CC request is eligible for recall only when its CCE's availability
  state is "available" and the "m" value of the CCE also indicates an
  available state.  The callee's monitor MUST select for recall all
  eligible CC requests, and MUST NOT select any CC requests that
  fail to meet those criteria.

END

-- Sections 12.4 and 12.5 --

Pearl Liang's IANA review noted three actions that IANA will take, corresponding to Sections 12.1, 12.2, and 12.3 of the IANA Considerations.  Martin confirmed that Pearl's note was correct.  But I see IANA actions requested in Sections 12.4 and 12.5 as well:

Section 12.4 is asking for a change in the "Header Field Parameters and Parameter Values" registry in http://www.iana.org/assignments/sip-parameters, as follows:
OLD
  Call-Info
  purpose
  Yes
  [RFC3261][RFC5367]
NEW
  Call-Info
  purpose
  Yes
  [RFC3261][RFC5367][RFCXXXX]

Section 12.5 is asking for a new entry in the same registry, "Header Field Parameters and Parameter Values, as follows:
NEW
  Call-Info
  m
  Yes
  [RFCXXXX]

These were not picked up by IANA, and they'll most likely not be made unless the authors discuss this with IANA and make sure they know they need to be made.

[Ballot comment]
Some non-blocking comments that I'd like you to please consider.

In his AppsDir review (which is too recent for you to have responded to yet)...
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08569.html
...Salvatore Loreto pointed out two minor items:

-- Section 4.1 --

  The callee's monitor may utilize several methods to monitor the
  status of the callee's UA(s) and/or their users for availability to
  receive a CC call.  This can be achieved through monitoring calls
  made to the callee's UA(s) to determine their caller's and their
  final response' statuses.  And in a system with rich presence
  information, the presence information may directly provide this
  status.  In a more restricted system, this determination can depend
  on the mode of the CC call in question, which is provided by the 'm'
  parameter.  E.g., a UA is considered available for CCBS ("m=BS") when
  it is not busy, but a UA is considered available for CCNR ("m=NR")
  when it becomes not busy after being busy with an established call.

Is that 'm' parameter the URI 'm' parameter or the Call-Info header 'm' parameter?  Please clarify that in the text.

-- Section 11 --

  The use of the CC facility allows the caller's agent to determine
  some status information regarding the callee.  The information is
  confined to a busy/not-busy indication, and in legitimate use, will
  be subscribed to stereotyped ways that limit the disclosure of status
  information:

That implies that the only status a caller's agent can determine with this is CCBS.  The document also discusses statuses of CCNR and CCNL.  Can't the caller's agent also determine those statuses?  Should this discuss those as well, and note the security implications?

IANA has reviewed draft-ietf-bliss-call-completion-18 and has the following comments:

IANA understands that, upon approval of this document, there are three
actions which IANA must complete.

First, in the Event packages and Event template-packages registry
located in the Session Initiation Protocol (SIP) Event Types Namespace
located at:

http://www.iana.org/assignments/sip-events/sip-events.xml

a new SIP Event Packaged will be registered as follows:

Package Name: call-completion
Type: package
Contact: martin.huelsemann@telekom.de
Reference: [ RFC-to-be ]

Second, in the application media types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new application media type will be registered as follows:

call-completion
[ RFC-to-be ]

Third, in the SIP/SIPS URI Parameters subregistry of the Session
Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

a new SIP/SIPS URI parameter will be registered as follows:

Parameter Name Predefined Values Reference
-------------- ----------------- ---------
m Yes [ RFC-to-be ]

IANA understands that, upon approval of this document, these are the
only actions which IANA must complete.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

UPDATED Document writeup

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard. Header says ' Intended status: Standards Track '

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines call completion feature allowing caller of a
failed call to be notified when the callee becomes available to
receive a call.

Working Group Summary

The WG path of this document was very long. The draft has been
revised numerous time (Total of 19 times including the individual
draft), went through 2 WGLC and a huge re-write after an AD review.

The WG consensus were reached during the two WGLCs and
AD's comment were to increase text in security consideration and
to clarify the involvement of presence server which was rather
implicit in the previous draft.

Document Quality

There are implementations and real life deployment based on this
draft. The document has been revved and reviewed many times,
indicating that viability of the document quality.

Personnel

Shida Schubert is the Document Shepherd. Robert Sparks
is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have performed a detailed review of the document and I consider it
ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document was already reviewed by members in GEN-ART, along with
some key members in SIP community, Paul Kyzivat (SIPCORE chair) and
by co-author of SIP specification itself (The responsible AD, Robert Sparks).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been submitted directly on
draft-ietf-bliss-call-completion.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The number of active participants in the Working Group was not very
high at the time this draft was going through WGLCs. Among the active
participants there seems to be solid consensus in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues excepting the ones related to the submission date and a
couple of references on documents that have issued more recent versions
since the publication of the I-D.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

MIME media type defined in this specification has been
requested for a review.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document requires from IANA allocations of values in existing
registries which are clearly defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Call Completion for Session Initiation Protocol (SIP)) to Proposed Standard


The IESG has received a request from the Basic Level of Interoperability
for SIP Services WG (bliss) to consider the following document:
- 'Call Completion for Session Initiation Protocol (SIP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The call completion feature defined in this specification allows the
  caller of a failed call to be notified when the callee becomes
  available to receive a call.

  For the realization of a basic solution without queuing, this
  document references the usage of the dialog event package (RFC 4235)
  that is described as 'automatic redial' in the SIP Service Examples
  (RFC 5359).

  For the realization of a more comprehensive solution with queuing,
  this document introduces an architecture for implementing these
  features in the Session Initiation Protocol where "call completion"
  implementations associated with the caller's and callee's endpoints
  cooperate to place the caller's request for call completion into a
  queue at the callee's endpoint, and when a caller's request is ready
  to be serviced, re-attempt of the original, failed call is made.

  The architecture is designed to interoperate well with existing call-
  completion solutions in other networks.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO Writeup for draft-ietf-bliss-call-completion
=================================================

http://tools.ietf.org/html/draft-ietf-bliss-call-completion

  (1.a)  Who is the Document Shepherd for this document?  Has the
    Document Shepherd personally reviewed this version of the document
    and, in particular, does he or she believe this version is ready
    for forwarding to the IESG for publication?

Shida Schubert is the document shepherd.  I have personally reviewed
the document, and believe it is ready for publication as a standard track RFC.

Document History:

draft-poetzl-bliss-call-completion-00.txt was submitted 11th Nov 2007
draft-ietf-bliss-call-completion-00.txt was submitted 18th Feb 2008
draft-ietf-bliss-call-completion-01.txt was submitted 26th Feb 2008
draft-ietf-bliss-call-completion-02.txt was submitted 20th Jun 2008
draft-ietf-bliss-call-completion-03.txt was submitted 8th Dec 2008
draft-ietf-bliss-call-completion-04.txt was submitted 13th Jul 2009
draft-ietf-bliss-call-completion-05.txt was submitted 26th Oct 2009
draft-ietf-bliss-call-completion-06.txt was submitted 25th Jun 2010
draft-ietf-bliss-call-completion-07.txt was submitted 13th Oct 2010
draft-ietf-bliss-call-completion-08.txt was submitted 28th Oct 2010
draft-ietf-bliss-call-completion-09.txt was submitted 14th Apr 2011
draft-ietf-bliss-call-completion-10.txt was submitted 6th May 2011
draft-ietf-bliss-call-completion-11.txt was submitted 24th Oct 2011
draft-ietf-bliss-call-completion-12.txt was submitted 15th Nov 2011
draft-ietf-bliss-call-completion-13.txt was submitted 30th Nov 2011

  (1.b)  Has the document had adequate review both from key members of
    the interested community and others?  Does the Document Shepherd
    have any concerns about the depth or breadth of the reviews that
    have been performed?

The document has been discussed on BLISS mailing list and on
separate mailing list where design team for this draft shared opinions
and revised the document. The draft went through two WGLC and
received substantial number of comments over 3 years.

As a result, the reviews appear to have been reasonably thorough and representative.

Furthermore the draft has been implemented by major open-source PBX vendor
as well as by major service provider in Europe where the specification is deployed.

  (1.c)  Does the Document Shepherd have concerns that the document
    needs more review from a particular or broader perspective, e.g.,
    security, operational complexity, someone familiar with AAA,
    internationalization or XML?

No concerns.

  (1.d)  Does the Document Shepherd have any specific concerns or
    issues with this document that the Responsible Area Director
    and/or the IESG should be aware of?  For example, perhaps he or
    she is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it.  In any event, if
    the interested community has discussed those issues and has
    indicated that it still wishes to advance the document, detail
    those concerns here.

No concerns.

  (1.e)  How solid is the consensus of the interested community behind
    this document?  Does it represent the strong concurrence of a few
    individuals, with others being silent, or does the interested
    community as a whole understand and agree with it?

Full consensus exists on this document.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director.  (It
    should be in a separate email because this questionnaire is
    entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
    document satisfies all ID nits?  (See
    http://www.ietf.org/ID-Checklist.html and
    http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
    enough; this check needs to be thorough.  Has the document met all
    formal review criteria it needs to, such as the MIB Doctor, media
    type and URI type reviews?

IDNits are clean.

idnits 2.12.12

tmp/draft-ietf-bliss-call-completion-12.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC XXXX' is mentioned on line 1289, but not defined


    Summary: 0 errors (**), 1 warning (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

  (1.h)  Has the document split its references into normative and
    informative?  Are there normative references to documents that are
    not ready for advancement or are otherwise in an unclear state?
    If such normative references exist, what is the strategy for their
    completion?  Are there normative references that are downward
    references, as described in [RFC3967]?  If so, list these downward
    references to support the Area Director in the Last Call procedure
    for them [RFC3967].

The references are split properly.

draft-ietf-sipcore-rfc3265bis which is work in progress updates rfc3265 which
previous version of this draft referenced. As the draft which updates rfc3265
received consensus in relevant workgroup (SIPCORE) to progress the draft as
a workgroup item, it is only sensible to reference the updated version of rfc3265.

  (1.i)  Has the Document Shepherd verified that the document IANA
    consideration section exists and is consistent with the body of
    the document?  If the document specifies protocol extensions, are
    reservations requested in appropriate IANA registries?  Are the
    IANA registries clearly identified?  If the document creates a new
    registry, does it define the proposed initial contents of the
    registry and an allocation procedure for future registrations?
    Does it suggested a reasonable name for the new registry?  See
    [I-D.narten-iana-considerations-rfc2434bis].  If the document
    describes an Expert Review process has Shepherd conferred with the
    Responsible Area Director so that the IESG can appoint the needed
    Expert during the IESG Evaluation?

The IANA Considerations section exists (section 13). 

It requires IANA to register the followings.

1. SIP event package: "call-completion"
2. MIME subtype: "call-completion"
3. SIP/SIPS URI parameter : "m"
4. Call-info purpose parameter value : "call-completion"
5. New header field parameter for Call-Info header : "m"

  (1.j)  Has the Document Shepherd verified that sections of the
    document that are written in a formal language, such as XML code,
    BNF rules, MIB definitions, etc., validate correctly in an
    automated checker?

XML schema is correctly formatted and shows no error.

  (1.k)  The IESG approval announcement includes a Document
    Announcement Write-Up.  Please provide such a Document
    Announcement Writeup?  Recent examples can be found in the
    "Action" announcements for approved documents.  The approval
    announcement contains the following sections:
    Technical Summary

Technical Summary

  The call completion feature defined in this specification allows the
  caller of a failed call to be notified when the callee becomes available
  to receive a call.

Document Quality

The document has been reviewed by participants within the IETF BLISS WG, including SIP
service providers as well as representatives from the PBX vendor community.  It has gone
through pre-WGLC reviews by experts and went through two WG last calls.

Personnel

Shida Schubert is the document shepherd for this document.
Robert Spark is the responsible AD.