Ben,
Thanks for your review!
Wrt. authorization, the document does make it clear that bulk revocation
requires explicit authorization (search for "authorization"). The
document does not say how to achieve this, but I would assume a global
configuration flag or a list of authorized peers. We could add this to
the document, if you think it helps.
When it comes to non-bulk revocation messages, I'm not sure their
requirements are any different from the rest of the signaling. First,
the protocol intrinsically enables only the revocation of sessions
created by the two parties. Secondly, existing messages can already be
used to create and delete sessions from clients -- binding revocation
simply adds a capability to do that from the server side as well.
Additional requirements for authorization mechanisms could be added
here, but I'm not sure its needed.
Jari
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf