Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt

From: [email-masked]
Date: Mon, 12 Dec 2016 13:50:24 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
	Filename        : draft-ietf-sipcore-status-unwanted-00.txt
	Pages           : 6
	Date            : 2016-12-12

Abstract:
   This document defines the 666 (Unwanted) SIP response code, allowing
   called parties to indicate that the call was unwanted.  The
   terminating SIP entity may use this information to adjust future call
   handling behavior for this called party or more broadly.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Dec 2016 15:13:43 -0500

I reviewed this new version. I have a couple of suggestions for small 
wording changes:

* Section 1:

The wording of the following:

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

is odd. AFAIK, the "called party" here is a person who interacts with 
the called UA to indicate that the call is unwanted. The called party 
doesn't use the 666 response code - the called UA uses it, based on some 
(unspecified) stimulus provided by the called party. Or the called UA, 
acting as an automata, may generate the response without a stimulus from 
the called party.

I suggest the following to replace the above:

    ... The called user agent (UAS), based on input from the called
    party or internal logic, uses this code to indicate that this call
    and future calls from the same caller are unwanted.

* Section 2:

This section has some text having a similar issue:

    None of the existing 4xx, 5xx or 6xx response codes allow the called
    party to convey that they not only reject this call, e.g., using 480
    (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere),
    603 (Decline) or 606 (Not Acceptable), but that the caller is
    unwanted.

I suggest:

    None of the existing 4xx, 5xx or 6xx response codes signify that
    calls from this caller are unwanted by the called party.

Otherwise I like it.

	Thanks,
	Paul

On 12/12/16 4:50 PM, [email-masked] wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Alberto Llamas <[email-masked]>
Date: Wed, 14 Dec 2016 09:25:52 +0100

Hello,

Wouldn't be useful to include a desirable UAC behavior when serial/parallel
forking?. Something like if the UAC receive the unwanted message when doing
serial or parallel forking is recommended  the UAC  stop the forking
process?

Regards,

-- 
Alberto Llamas
Telecommunications Engineer
Digium Certified Asterisk Professional (dCap)

---

From: Brett Tate <[email-masked]>
Date: Wed, 14 Dec 2016 07:35:23 -0500

> Wouldn't be useful to include a desirable UAC behavior when
> serial/parallel forking?. Something like if the UAC receive
> the unwanted message when doing serial or parallel forking
> is recommended  the UAC  stop the forking process?

Concerning "UAC stop the forking process", I assume that you referring to
the proxies that process the 666 response.  It looks like RFC 3261 section
16.7 already covers it.

RFC 3261 section 16.7: "If a 6xx response is received, it is not immediately
forwarded, but the stateful proxy SHOULD cancel all client pending
transactions as described in Section 10, and it MUST NOT create any new
branches in this context."

---

From: Alberto Llamas <[email-masked]>
Date: Wed, 14 Dec 2016 14:29:41 +0100

Hello Brett,

Thanks for the reply and yes, my concern is covered  by  RFC 3261 section
16.7

Regards,

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Dec 2016 21:28:53 +0000

Thank you for the comments. -01 will include the text suggestions you made.

I would like to "ship" -01 before the holidays, so please wrap up your holiday comment gifts and express-mail them so that only robocallers will find coal in their stockings.

Henning

________________________________
From: sipcore <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Tuesday, December 13, 2016 3:13:43 PM
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt

* Section 1:

* Section 2:

I suggest:

Otherwise I like it.

        Thanks,
        Paul

On 12/12/16 4:50 PM, [email-masked] wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=0RGC_RjQLE0D4e1MF8JTEvWKRNFsrY_6wj__iKqw8lQ&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=v2Iwj1kwSfluBGM44GaF1yEWLsRiOymrdGvqmN07_P8&e=
>
>
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=qnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=
>

_______________________________________________
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=ra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 19 Dec 2016 21:43:59 +0000

Greetings

Small issue with Paul's comments.

The user needs to make a "clear" decision on 666 being sent. So the user pressing a button is clear, whether pre/post answer, but an application scenario is not

Need to fully understand the consequences of initiating trace back and a fraud report

Regards

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

Henning

________________________________
From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, December 13, 2016 3:13:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt

* Section 1:

* Section 2:

I suggest:

Otherwise I like it.

        Thanks,
        Paul

On 12/12/16 4:50 PM, [email-masked]<mailto:[email-masked]> wrote:
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore