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

Note: This ballot was opened for revision 18 and is now closed.

Barry Leiba (was Discuss) Yes

Comment (2013-02-11)
No email
send info
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.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-01-06 for -18)
No email
send info
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.

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-01-07 for -18)
No email
send info
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/

(Brian Haberman) No Objection

Comment (2013-01-03 for -18)
No email
send info
I support Barry's DISCUSS point related to the IANA Considerations.

(Russ Housley) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-01-09 for -18)
No email
send info
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)