A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies
RFC 6795

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

(Jon Peterson) Yes

(Robert Sparks) Yes

(Jari Arkko) No Objection

Comment (2008-10-23 for -)
No email
send info
Review by Christian Vogt:

Overall, this document is clearly ready for publication.  It is
well-written, unambiguous, and to-the-point.  I have one technical
comment below that I believe should be addressed, plus an editorial.

Technical

- The document assumes in some places that a policy server can
  coordinate the lifetime of a policy subscription with the lifetime
  of a session.  E.g., section 3.4 ("Subscription Duration") seems to
  make this assumption.  However, there is no way for a policy server
  to determine the lifetime of a session.  Although a subscription
  request may contain an estimate for the session subscription, this
  estimate may, of course, be off from the real session lifetime.

  The question is whether the lack of coordination between policy server
  and session peers can result in issues.  I don't believe it can, but
  the document should explain why.  Note that means for such
  coordination do exist:  A possible coordination mechanism would have
  been to use short subscription lifetimes that session peers
  periodically refresh until their session terminates.

Editorial

- Section 3.2 ("Event Package Parameters") identifies the package
  parameters for the newly defined event package.  Right now, the
  section refers to a set of other sections where the use of a given
  parameter is defined.  It may, however, be useful for the reader to
  get a one-sentence summary of the purpose of a given parameter
  already in section 3.2.  Suggest to augment section 3.2 in this
  manner.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) (was Discuss) No Objection

Comment (2010-03-21 for -)
No email
send info
Some of the security considerations seem to depend on
draft-ietf-sipping-media-policy-dataset (e.g. what parts of the
session description shouldn't be sent to the policy server -- or
viewed from another angle, what information the policy server can't
use in formulating its policy decision), and perhaps these drafts
should have been reviewed together...

(Russ Housley) (was Discuss) No Objection

Comment (2010-03-03 for -)
No email
send info
  Section 4 says: "If the user agent has a TLS certificate ...".
  This should say: "If the user agent has an X.509 certificate
  suitable for use with TLS ...".

(Cullen Jennings) No Objection

(Chris Newman) No Objection

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

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection