Subject: [sipcore] Warren Kumari's Yes on draft-ietf-sipcore-rejected-08: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 12 Jun 2019 10:06:50 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-sipcore-rejected-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I generally approach SIP documents with a sense of foreboding — they are often
long, expect a large amount of knowledge outside my area of expertise, and
require lots of reference chasing — but this was a really good read. It
describes the problem well, it lays out the protocol clearly, and contains
enough humor / snark to make reading it actually enjoyable.

Nits:
"Another value of the 607 rejection is presuming the proxy forwards
the response code to the User Agent Client (UAC), the calling UAC or
intervening proxies will also learn the user is not interested in
receiving calls from that sender."
I found this sentence really hard to parse -- I think adding a comma after "is"
fixes it.

"An algorithm can be vulnerable to an algorithm subject to the base rate
fallacy [BaseRate] rejecting the call." Unparsable -- duplication? Perhaps just
" An algorithm can be vulnerable to the base rate fallacy [BaseRate] rejecting
the call."?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jun 2019 14:25:00 -0400

> I found this sentence really hard to parse -- I think adding a comma after "is"

I still find that hard to follow. Here is another possibility:

If the 607 rejection is forwarded all the way to the User Agent Client 
(UAC) then, like 608, it informs the UAC and any other intervening 
proxies that the user is not interested in receiving calls from that sender.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Wed, 19 Jun 2019 22:54:11 -0400

Your suggestion for my bizarre Base Rate Fallacy language makes is much clearer and also fixes similar issues raised by others. Thanks!

> On Jun 12, 2019, at 1:06 PM, Warren Kumari via Datatracker <[email-masked]> wrote:
>