The Session Initiation Protocol (SIP) Pending Additions Event Package
draft-ietf-sipping-pending-additions-05
Yes
(Jon Peterson)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Ross Callon)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 05 and is now closed.
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu 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
Lisa Dusseault Former IESG member
No Objection
No Objection
(2008-03-04)
Unknown
What is the purpose of registering the two XML schemas? - urn:ietf:params:xml:schema:consent-status - urn:ietf:params:xml:schema:resource-lists-diff it doesn't seem to provide any utility.
Magnus Westerlund Former IESG member
No Objection
No Objection
(2008-03-03)
Unknown
Section 5.1.9 states for congestion avoidance event notifications should not be sent more often then every 5 seconds. How well figured out is this number? Is this another SIP overload resulting mechanism? Will a general SIP overload mechanism effect also these notification transactions? I only want to make sure that this isn't digging a deeper hole for the guys that trying to get out of the existing SIP overload one.
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2008-03-03)
Unknown
From David Black's Gen-ART review. In Secction 5.1.2: > > A SUBSCRIBE for Pending Additions events MAY contain a body. This > body would serve the purpose of filtering the subscription. The > definition of such a body is outside the scope of this specification. > How is that supposed to be interoperable? A better approach would be to prohibit bodies now and allow a future specification to define them.
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2008-03-05)
Unknown
I suspect the RFC Editor would catch all of these, but I noticed a few nits. I have suggested changes, but please review to be sure I interpreted things correctly! Section 3, last sentence: s/experimented/experienced/ Section 8, para 2 first sentence: s/even package/event package/ Section 8, para 4 first sentence: s/confidentially/confidentiality/