Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04

From: "Ben Campbell" <[email-masked]>
Date: Tue, 07 Mar 2017 17:42:32 -0600

Hi,

This is my AD evaluation of draft-ietf-sipcore-status-unwanted-04. I 
have a few substantive and and some editorial comments. I don't think 
any of these need block the IETF last call, which I will request 
shortly. These can be resolved along with any IETF LC comments.

Thanks!

Ben.

-----------------
- Substantive Comments:

-- section 4, first paragraph:

I'm struggling to understand what a sending a 666 when canceling a 
branch of a forked call would mean. Are we talking about a scenario 
where a forking proxy notes that one device responds with a 666, then 
the proxy sends that to the other branches? If so, some elaboration of 
the use case might be helpful.

-- Section 4, paragraph 3:
There's some imprecision in whether explicit user action is expected 
when deciding to send a 666. I think the intent is that explicit user 
action (e.g. a spam button) is just one of multiple ways a called UA 
could decide to do so. But the last sentence of the paragraph seems to 
indicate an expectation for explicit UI action, in spite of the earlier 
sentences that allowed otherwise. It's not clear to me if those previous 
sentences describe when to _send_ a 666, or just what one might do when 
receiving one.

-6, 3rd paragraph from end:
How can one reasonably know that an identity has been reassigned? I can 
see the case where the callee's service provider is the same as the 
caller's service provider, but that's a degenerate case. Are we 
expecting the calling SP to inform the callee SP out of band, and the 
callee SP to believe them? Given how poorly that seems to work in the 
context of email, I wonder if there's any useful advice to give here.

- Editorial Comments:

-- There's some general imprecision in the use of "UAC" and "UAS". I 
think the intent is to speak of the UAC and UAS in the context of the 
dialog-initiating transaction (at least when a dialog is involved), but 
it ends up with language of the form of "... when the UAS sends a BYE 
request...". Perhaps terms like "caller UA" and "callee UA" would be 
more clear? (Not that I particularly those, when caller and callee or 
called vary by a single letter.)

-- section 1, first paragraph, sentence starting with "This document 
addresses only the last mode..."
The sentence is convoluted. Can it be broken into  a few simpler 
sentences?

-- 4, 2nd paragraph:
Please avoid 2119 keywords (in this case MAY), in a non-exhaustive list 
of examples, as it implies that additional MAYs exist but are not 
explicitly mentioned. Consider something along the lines of "...MAY 
perform some action based on local policy, for example, add the party to 
a local blacklist, ..."

--4, 4th paragraph: I'm not sure I believe the sentence starting with 
"In other words" paraphrases any previous words :-)

--6: 2nd to last paragraph: A citation for call transfer might be nice. 
(Maybe the call flows RFC?)