Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-06
Yes
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Sam Hartman)
No Objection
(Chris Newman)
(David Ward)
(Jari Arkko)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 06 and is now closed.
Cullen Jennings Former IESG member
Yes
Yes
()
Unknown
Dan Romascanu Former IESG member
Yes
Yes
()
Unknown
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Lisa Dusseault Former IESG member
Yes
Yes
(2007-06-05)
Unknown
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).
Sam Hartman Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2007-06-05)
Unknown
This document reads more like a BCP than an Informational; especially Section 6. Was there consensus against making it a BCP?
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2007-06-06)
Unknown
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).
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2007-06-06)
Unknown
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.