Requirements for SIP-Based Session Peering
RFC 6271

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

(Gonzalo Camarillo) Yes

(Cullen Jennings) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-10-06 for -)
No email
send info
Minor editorial nit.  In section A.1, this sentence doesn't parse:

   o  IP Network Connectivity:
      Session peers should define how the IP network connectivity
      between their respective SBEs and DBEs.

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2009-10-07 for -)
No email
send info
  WGs are ephemeral - continously refering to the originating SPEERMINT
  WG in the title and body of the document will read strangely in a few

(Adrian Farrel) No Objection

Comment (2009-10-08 for -)
No email
send info
Thank you for numbering the requirements. This will make life so much easier in future documents.


The Introduction is a bit confusing I see:

   It is assumed that these sessions
   use the Session Initiation Protocol (SIP) protocol to enable peering
   between two or more actors.


   It is not the goal of this document to mandate any particular use of
   IETF protocols by SIP Service Providers in order to establish session
   peering.  Instead, the document highlights what requirements should
   be met and what protocols may be used to define the solution space.

That appears to be a conflict.

Also I suggest s/may/might/ in the last line to allow possibility rather than permission.

(Russ Housley) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2009-10-27 for -)
No email
send info
From review of Section 4 by Peter Saint-Andre:

Requirement #13

      It should be possible to send a presence document with a list of
      watchers on the other community that should receive the presence
      document notification.  This will enable sending less presence
      document notifications between the communities while avoiding the
      need to share privacy information of presentities from one
      community to the other.

This requirement says nothing about security. Presumably, information
about the recipients of a given notification might also be private and
therefore worthy of protection, just as under Requirement #12.

(Tim Polk) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2009-10-07)
No email
send info
Nit: typo: "if user consent is not give,": give should be given