The Session Initiation Protocol (SIP) Pending Additions Event Package
RFC 5362

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

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

Comment (2008-03-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Sam Hartman) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2008-03-03)
No email
send info
  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.

(Cullen Jennings) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2008-03-05)
No email
send info
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/

(Dan Romascanu) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection

Comment (2008-03-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.