[sipcore] Comments on draft-ietf-sipcore-status-unwanted-00

[[e-mail] (Dale R. Worley)]

All of these comments are editorial.

1.  Introduction

   The called party or a automata acting on her behalf uses this
   to indicate that future calls from the same caller are also unwanted.

s/a automata/an automaton/

4.  Behavior of SIP Entities

   The response code MAY also be used in Reason header fields [RFC3326],
   typically when the UAS issues a BYE request terminating an incoming
   call.

This doesn't fully explain the intended behaviors.  Better would be a
description like:

   The response code 666 MAY be used in a failure response for an
   INVITE, MESSAGE, or other request to indicate that the offered
   communication is unwanted.

   The response code MAY also be used as the value of the "cause"
   parameter of a "SIP" reason-value in a "Reason" header field
   [RFC3326] in a BYE request terminating an incoming call that is
   unwanted.

--

   The service provider delivering calls to
   the user issuing the response may, for example, add the calling party
   to a personal blacklist specific to the called party, or may use the
   information as input when computing the likelihood that the calling
   party is placing unwanted calls ("crowd sourcing"), might initiate a
   traceback request, or could report the calling number to government
   authorities.

This list has 4 items:

   may, for example, add the calling party to a personal blacklist
   specific to the called party,

   or may use the information as input when computing the likelihood
   that the calling party is placing unwanted calls ("crowd
   sourcing"),

   might initiate a traceback request,

   or could report the calling number to government authorities.

There is a lack of parallelism in that clauses use "may", "might", and
"could" to indicate possbility.  There are two uses of "or".  The
first item contains commas, but the items are not separated by
semicolons.  Reformulating this by (1) consistently using MAY, (2)
using one "or" before the last item, and (3) moving the "for example"
to before the list (thus escaping the rule regarding semicolons):

   The service provider delivering calls to the user issuing the
   response, for example, MAY add the calling party to a personal
   blacklist specific to the called party, MAY use the information as
   input when computing the likelihood that the calling party is
   placing unwanted calls ("crowd sourcing"), MAY initiate a traceback
   request, or MAY report the calling number to government
   authorities.

--

   The same
   user interface action might also trigger addition of the number to a
   local, on-device blacklist or graylist, e.g., causing such calls to
   be flagged or alert with a different ring tone.

This construction parallels "to be flagged" with "alert with a
different ring tone".  Probably s/alert/alerted/ so that the
parallelism is "to be (flagged | alerted with a different ring tone)".

--

   We define a SIP feature-capability [RFC6809], sip.666, that allows
   the registrar to indicate that it supports this particular response
   code.

Except that the registrar doesn't support the response code, really.
It's the proxy that does lookups in the location service that the
registrar maintains.  So perhaps:

   We define a SIP feature-capability [RFC6809], sip.666, that allows
   the registrar to indicate that the corresponding proxy supports
   this particular response code.

6.  Security Considerations

   Thus, any additions to a personal
   list of blocked numbers should be observable by the subscriber, e.g.,
   on a web page or by regular email notification, and reservible.

s/reservible/reversible/

The meaning of "the subscriber" is unclear.  Is it "the recipient" or
"the caller"?

Dale