Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)
draft-ietf-sipping-consent-reqs-04

[Ballot comment]
Revision -04, which just came out, addressed the Comments from Elwyn Davies (GEN-ART) and the Discuss issues of Sam Hartman.  The editor worked
out the revisions with Elwyn and Sam.  Sam just cleared.  Checking
with that WG is fine.

[Ballot comment]
Revision -04, which just came out, addressed the Comments from Elwyn Davies (GEN-ART) and the Discuss issues of Sam Hartman.  Sam has just cleared.

[Ballot discuss]
As described in section 2, the spam problem does not need this
solution.  There's nothing stopping the UA from rejecting an invite
without involvig the user or failing to display a message.  The
concern about DOS and excessive network traffic does seem to mandate
this solution, but the concerns about spam need to be restated in such
a way that they actually motivate the requirements.

I also have a question about section 3.  Is the intent that all SIP
communications in the future require consent or is this only sometimes
applied?

[Ballot comment]
I think that all the points made in the following Gen-ART review by Elwyn Davies are of interest, especially the point that consents should not themselves be available as a DOS mechanism.

----------

- How much knowledge of the network and relay state does a given
user/user agent need to install consents on all relevant relays?
Caveat: I am not a SIP expert so I may have some misunderstandings
here.  As I understand it, a user device will register for a session
with a given relay/proxy that it knows about.  In the context of REQ 6,
how is the device to know that the relevant consents are installed on
this relay as the device might have a choice of relays?
- The document doesn't put any requirements on the transition to the
consent based system.  If I understand correctly the introduction of the
consent based system would effectively reverse the default assumption
from (e.g.) 'INVITE delivered by default' to 'INVITE not delivered by
default'.  Introducing this change will be challenging, both in terms of
how to handle existing users and providing an effective initial
configuration for new users.
- The document doesn't mention the need for strict authorization of
messages setting up or revoking consent permissions which I believe is
essential.  This should probably be in the context of a discussion of
how to avoid the consent mechanism itself becoming the focus of DoS
attacks, and then some requirements stemming from this.  This might also
consider whether these messages *must* originate from the user/user
agent to which the permission applies or whether third parties with
appropriate authorization can provide the permissions.
- In the context of REQ 8 (need for future proofing), I suspect that a
requirement for an 'emergency override' needs to be provided for so that
in future suitably authorized requests could ignore a prior consent denial.
- Some thought needs to be given to requirements on logging of requests
which are rejected as a result of non-consent.  This may be relevant to
legal requirements on interception of communication and it might also be
interesting for users to be able to examine the log of users who tried
to call them but were rejected - this is particularly relevant as the
proposal defaults to rejecting calls for which explicit consent has not
been given.

Minor points:
REQ 5: If a user revokes permission for a user with whom a call is
pending or in progress, should this have the effect of terminating the call?

REQ 6: This should also apply to grants: I think this is saying that all
grant and revoke messages should be idempotent.

REQ 8: '...shall work for all .. future SIP methods': I know what is
meant but this is impossible to guarantee and probably an undesirable
constraint on future developments. How about something like 'should be
designed, so far as is possible, to work with any future SIP methods and
place minimal constraints on such methods.'

Editorial nit:
The term 'screen pop' used twice in s2 is very colloquial.  I would
suggest 'visual alert' instead. How about replacing:
  For INVITE requests, this usually involves
  "ringing the phone", or creating a screen pop.
with
  For INVITE requests, this usually involves
  delivering an audible alert (e.g., "ringing the phone"), or
  a visual alert (e.g., creating a screen pop-up window).