Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Feb 2017 04:02:27 +0000

So, in terms of your proposed language, maybe something like: "...and
indicates that future attempts are likely to be similarly rejected.
While factors such as identity spoofing and call forwarding may make
authoritative identification of the calling party difficult or
impossible, the network can use such a rejection -- possibly combined
with a pattern of rejections by other callees and/or other information
-- as input to a heuristic algorithm for determining future call
treatment. The heuristic processing and possible treatment of
persistently unwanted calls are outside the scope of this document."

[TOLGA] I am fine with both this and the what Henning suggested -slightly favoring this version-. I would disfavor to include anything more complex/elaborate as far as issues/semantics regarding the network based analytics logic to process/act upon 666. The raison d'etre for this draft is specifying 666 rather than the logic what needs to be done about it and Adam's proposal is a good middle=path IMHO.

Thanks,
Tolga

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2017 10:31:29 -0500

On 2/12/17 11:02 PM, Asveren, Tolga wrote:

> [TOLGA] I am fine with both this and the what Henning suggested
> -slightly favoring this version-. I would disfavor to include anything
> more complex/elaborate as far as issues/semantics regarding the network
> based analytics logic to process/act upon 666. The raison d’etre for
> this draft is specifying 666 rather than the logic what needs to be done
> about it and Adam’s proposal is a good middle=path IMHO.

There is a fine line to walk here. I agree that we should not be getting 
into algorithmic details. But it is also important to specify enough so 
that there is general agreement on when it is appropriate to push the 
button that generates 666. If we end up in a situation where I need to 
temper my decision on whether to push the button based on which provider 
services the phone then we have failed.

I think the wordings being discussed here have fairly well struck that 
balance.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 13 Feb 2017 16:36:32 +0000

Not suggesting a change in the proposed text and it seems we are all in agreement here but just for the record: This specification is not intended for end-users but for SIP stack development on UE. So, "when it is appropriate to push the button" is something operators needs to educate end-users/end-users will figure out over time IMHO.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, February 13, 2017 10:31 AM
To: [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

On 2/12/17 11:02 PM, Asveren, Tolga wrote:

> more complex/elaborate as far as issues/semantics regarding the 
> network based analytics logic to process/act upon 666. The raison 
> d'etre for this draft is specifying 666 rather than the logic what 
> needs to be done about it and Adam's proposal is a good middle=path IMHO.

There is a fine line to walk here. I agree that we should not be getting into algorithmic details. But it is also important to specify enough so that there is general agreement on when it is appropriate to push the button that generates 666. If we end up in a situation where I need to temper my decision on whether to push the button based on which provider services the phone then we have failed.

I think the wordings being discussed here have fairly well struck that balance.

	Thanks,
	Paul

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2017 18:30:49 -0500

> Not suggesting a change in the proposed text and it seems we are all in agreement here but just for the record: This specification is not intended for end-users but for SIP stack development on UE.…

I agree, sort of. We aren't the right forum for telling users when to 
push the button. But we are providing a way (666 or not) to signal a 
single bit of information about this from the UA to the provider. And 
that single bit is intended to mean something. If it doesn't mean 
essentially the same thing from provider to provider then the meaning of 
the button will also vary from provider to provider. And *that* is a 
*bad* thing.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 14 Feb 2017 11:50:37 +0000

Yes it is undesirable but IMHO unavoidable as well. There would be operators using this feedback in various ways, e.g. feed into heuristics only for this user, for all users, blacklist directly for this user etc... Just think of what happens when an organization changes the e-mail spam tool they are using. It usually ends up being a nightmare for the first couple of weeks, both for users and administrator.

So, I think the currently suggested wording is a very good balance addressing concerns both about the "true meaning" and also "how it may be used".

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, February 13, 2017 6:31 PM
To: [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

> Not suggesting a change in the proposed text and it seems we are all in agreement here but just for the record: This specification is not intended for end-users but for SIP stack development on UE.…

I agree, sort of. We aren't the right forum for telling users when to push the button. But we are providing a way (666 or not) to signal a single bit of information about this from the UA to the provider. And that single bit is intended to mean something. If it doesn't mean essentially the same thing from provider to provider then the meaning of the button will also vary from provider to provider. And *that* is a
*bad* thing.

	Thanks,
	Paul

>> -slightly favoring this version-. I would disfavor to include 
>> anything more complex/elaborate as far as issues/semantics regarding 
>> the network based analytics logic to process/act upon 666. The raison

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Feb 2017 11:58:36 -0500

> Yes it is undesirable but IMHO unavoidable as well. There would be operators using this feedback in various ways, e.g. feed into heuristics only for this user, for all users, blacklist directly for…

Certainly there can be many different tools and algorithms that 
operators may choose among. But at the end of the day they are all doing 
so with the goal to achieve the same objective, when that objective is 
described at a high enough level of abstraction. When the user "pushes 
the button" he should understand that the purpose of doing so is to 
indicate that he wants this high level objective to be applied to this 
case. Since users frequently move among providers, and may not even know 
what provider is involved, it is important that all users have a common 
understanding of this objective.

Eventually users may come to choose a provider that does the best job of 
*achieving* the objective. But IMO it would be bad if choosing a 
provider has the effect of *changing* the objective.

> So, I think the currently suggested wording is a very good balance addressing concerns both about the "true meaning" and also "how it may be used".

I think so too.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Feb 2017 22:32:20 +0000

Thanks for all the comments. I suspect I missed something along the way, but -03 is now in the archives for your perusal.

Henning

From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Sunday, February 12, 2017 11:02 PM
To: SIPCORE <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

Thanks,
Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 16 Feb 2017 15:36:29 +0000

This version looks good to me. I don't have any objections/comments/suggestions.

Thanks,
Tolga

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 5:32 PM
To: Asveren, Tolga <[email-masked]>; SIPCORE <[email-masked]>
Subject: RE: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

Henning

From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Sunday, February 12, 2017 11:02 PM
To: SIPCORE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

Thanks,
Tolga

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Tue, 21 Feb 2017 12:20:05 +0000

-03 looks good to me too

Regards,
Peter

From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: 16 February 2017 15:36
To: Henning Schulzrinne; SIPCORE
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

Thanks,
Tolga

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 5:32 PM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; SIPCORE <[email-masked]<mailto:[email-masked]>>
Subject: RE: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

Henning

Thanks,
Tolga