Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Jan 2017 21:46:19 +0000

I have re-formulated the sentence in the manner suggested.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, December 22, 2016 1:24 PM
To: [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00

On 12/21/16 4:36 PM, Dale R. Worley wrote:

>    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.

IIUC these actions are not mutually exclusive. So I would:

s/or MAY report/and MAY report/

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Jan 2017 22:13:12 +0000

I have modified the wording as suggested. (Introduction has become moot due to earlier change suggestions.) 

For the "Security Considerations" comment, I reformulated to clarify that this is the party that is being protected by the blacklist. I don't think we'd necessarily want to inform the caller, although they may also get the 666 response. There are exceptions - I can imagine that some automated, legitimate robocalling operation could report statistics to the entity placing the calls, just like mass email senders presumably inform the human sender of spam reports ("5% of your messages were not delivered since they were rejected as spam"). But that seems beyond the scope of what the draft needs to discuss.

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Wednesday, December 21, 2016 4:37 PM
To: [email-masked]
Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00

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 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

_______________________________________________
sipcore mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=hWTNNu7TWkMZ4Qm1eQInwGVBt2OPXV9iF2iJm24XiBM&s=ZbB3Jap_Wj3g42vgW5IzVwq9VSHfdQy7R975GD3bnYU&e=