A Framework for Session Initiation Protocol (SIP) Session Policies
RFC 6794

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

(Cullen Jennings) (was Yes) Discuss

Discuss (2010-03-24 for -** No value found for 'p.get_dochistory.rev' **)
Was waiting for response from RIM about IPR

(Robert Sparks) (was No Objection) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2010-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Lisa Dusseault) (was Discuss) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

Comment (2009-01-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Lisa's discuss: the draft seems to combine three quite
separate things under the heading of "policy":

1. UAC retrieving information about what policies are being  
enforced. This is clearly useful so that UAC can avoid violating 
them, or can present more  meaningful information why session  
failed. But it's also optional -- if the codec preferred by UAC
is also allowed by the policy, then knowing the policy doesn't
give you much extra. Or it could just do trial-and-error.

2. UAC retrieving settings, such as TURN server addresses. This
seems quite different from "policies" (although like #1, it's
something the UAC could also get by some other means, like
manual local configuration).
   
3. UAC signalling various intermediaries (via the policy server) 
to set up state (like pinholes). This isn't just "retrieving
policies" (or settings) any more -- this is a signaling protocol,
and seems architecturally significantly different from #1 and #2.

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2010-12-23)
No email
send info
The following was a part of my DISCUSS:

8)
In Section 5:

   Instead of removing a policy server URI, an attacker can also modify
   the policy server URI and point the UA to a compromised policy
   server.  To prevent such an attack from being effective, it is
   RECOMMENDED that a UA authenticates policy servers.

What are the reasons to violate the RECOMMENDED (i.e. why is this not a MUST)?

(Chris Newman) No Objection

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

Comment (2009-01-07)
No email
send info
The document states "[This specification] specifies a model, the overall architecture and
new protocol mechanisms ..." in the introduction.  Similar words are in the abstract.  However,
I can't find a model anywhere.

(Dan Romascanu) No Objection

Comment (2009-01-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the issues raised by Lisa in her DISCUSS. 

I am also concerned by the statement in the protocol quality section of the annoucement that there are no implementations known for the mechanisms defined here. Actually in reality today SBCs implement session policies without mechanisms such as this. I am wondering whether Experimental would not have a more apropriate status for this document, but I will not block its approval on these reasons.

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2011-01-03)
No email
send info
1. I support Alexey's DISCUSSes.

2. [addressed by -08]

(Mark Townsley) No Objection

(Sean Turner) No Objection

Comment (2010-09-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
1) Please expand TLS on 1st use.

2) Add reference to TLS (i.e., [RFC5246]) in sections 4.4.1, 4.4.2, and 5 (x2).  Also, add [RFC5246] as an informative reference.

(David Ward) No Objection

(Gonzalo Camarillo) Recuse