Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-06

[Ballot comment]
From the Gen-ART by Pasi Eronen ...

  Some editorial suggestions: RFC editor nowadays recommends using
  symbolic references (e.g. [RFC3911] instead of [5]); and abbreviations
  should be expanded on first use (e.g. KPLM, UA, UAC, UAS, and GRUU).

[Ballot discuss]
What happened with LC comments from Ian Elz?  I think a response was
  deserved, but I cannot find one.  Did I miss it?

[Ballot discuss]
Section 5.4.  - I am confused by the statement that REFER was "clarified in a bug against RFC
3515".  I assumed that meant "clarified in an errata against RFC 3515" but no such errata were
found on the IETF website.  Where is this documented?

There are also problems with the statement that INVITE, UPDATE, SUBSCRIBE, and NOTIFY
were "clarified in a bug against RFC 3565".  RFC 3565 is actually "Use of the Advanced
Encryption Standard Ecryption Algorithm in the Cryptographic Message Syntax", and I
can't find any SIP related content.  Where are these clarifications documented?

[Ballot discuss]
Section 5.4.  - I am confused by the statement that REFER was "clarified in a bug against RFC
3515".  I assumed that meant "clarified in an errata against RFC 3515" but no such errata were
found on the IETF website.  Where is this documented?

I am even more confused by the statement that INVITE, UPDATE, SUBSCRIBE, and NOTIFY
were "clarified in a bug against RFC 3565".  RFC 3565 is actually "Use of the Advanced
Encryption Standard Ecryption Algorithm in the Cryptographic Message Syntax", and I
can't find any SIP related content.

[Ballot comment]
Should Section 6 be renamed "Avoiding Multiple Usages in Applications"?  As I interpreted the
earlier sections, multiple usages are unavoidable.  The problem is coordination and control
where an application requires multiple simultaneous usages.  Is that correct?  If so, renaming
section 6 would avoid some confusion.

[Ballot comment]
I don't understand this sentence from the Sec Cons:

"A service that disallows multiple usages should consider the effect on clients that, for instance, destroy the entire dialog when only a usage should be torn down."

I'm not sure if it means that a service which plans to reject attempts to create a second usage might consider first whether that would cause clients to destroy the entire dialog unnecessarily, or if there's some other way that a service might disallow multiple usages. 

Part of my confusion might be whether a "service" refers to a SIP feature standard (e.g. an extension), or an instance of a deployed and running feature (kind of analogous to a 'site' in other apps or "Web application" for the Web).

PROTO Write-up

    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

The SIPPING WG chairs have reviewed the document and believe it is ready for publication. Gonzalo Camarillo is its PROTO shepherd.

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has been thoroughly reviewed by a number of SIPPING members.

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

We do not have any particular concern in that respect.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

We feel comfortable with the document.

    1.e) 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?

There is strong consensus within the WG that dialog usage is an important issue in the SIP area.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

Nobody has done anything to stop this document.

    1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes, it does.

    1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

The document only has informative references.

    1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

    Several methods in the Session Initiation Protocol can create an
    association between endpoints known as a dialog.  Some of these
    methods can also create a different, but related, association within
    an existing dialog.  These multiple associations, or dialog usages,
    require carefully coordinated processing as they have independent
    life-cycles, but share common dialog state.  Processing multiple
    dialog usages correctly is not completely understood.  What is
    understood is difficult to implement.
    This memo argues that multiple dialog usages should be avoided.  It
    discusses alternatives to their use and clarifies essential behavior
    for elements that cannot currently avoid them.
    This is an informative document and makes no normative statements of
    any kind.


        *    Working Group Summary

There was strong consensus within the WG that this was an important issue that needed to be documented in an RFC.


        *    Protocol Quality

Jon Peterson is the Responsible Area Director. The WG chair shepherd
for the document is Gonzalo Camarillo.


Best regards,

Gonzalo