Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Tue, 3 Jan 2017 12:07:28 +0000

Hello All, 
A few comments on draft-ietf-sipcore-status-unwanted-00:
The text in the Abstract clause "The terminating SIP entity may use this information to adjust future call handling behavior for this called party or more broadly." mentions only the terminating SIP entity and the Introduction clause says "Carriers and other service providers may want to help their subscribers avoid receiving such calls ". Does this draft prohibit any intermediary SIP entity adjusting its call handling behaviour? Also, it might help for the draft to allow general adjustment of future handling of calls from the calling party. 

What is meant in this draft by "caller"? Is it the originating identity used for the particular rejected call, or is it any identity owned by the person who made the call? I think the draft should be clear on this.

Is this draft scoped specifically to what draft-ietf-stir-rfc4474bis-15.txt refers to as "Telephone Numbers"? I don't see anything in the draft about SIP URIs. I think the scope regarding caller identities should be clear.

And a couple of editorials:
Clause 5.1 says " This document register a new SIP response code."
Clause 6 contains the word "reservible"

Regards,
Peter

From: sipcore [mailto:[email-masked]] On Behalf Of Andy Hutton
Sent: 21 December 2016 15:24
To: Adam Roach
Cc: SIPCORE
Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Minor WGLC comment.

The abstract states "The terminating SIP entity may use this information....".

But this is not I believe referring to the actual terminating SIP entity which is the called users device but is referring to some preceding SIP entity probably the service provider.

Regards
Andy 

On Mon, Dec 12, 2016 at 9:05 PM, Adam Roach <[email-masked]> wrote:
[as chair]

I've seen significant support for adoption of draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no objections. Our revised charter that includes scope for this kind of item has been approved. The document is now adopted by SIPCORE. I have asked the author to submit subsequent versions of the document as draft-ietf-sipcore-status-unwanted.

Given the relatively uncomplicated mechanism being described and the requests for expedited processing, we will be starting our working group last call on the document today. In recognition that the upcoming winter holidays will take some portion of many participants' attention, and that many people will observe a New Year's Holiday on January 2nd, we will run this last call for three weeks, ending on January 3rd. Please review the document and provide comments on before that date.

/a

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Jan 2017 10:48:07 -0600

This is a reminder that the WGLC for this document ends today. If you 
have not had time to read and comment on it, please do so in the next 
few hours. The document is fairly short, and should take very little 
time to review.

Even comments like "I have read the document and believe it is ready for 
publication" would be useful.

/a

On 12/12/16 15:05, Adam Roach wrote:
> [as chair]
>
> I've seen significant support for adoption of 
> draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no 
> objections. Our revised charter that includes scope for this kind of 
> item has been approved. The document is now adopted by SIPCORE. I have 
> asked the author to submit subsequent versions of the document as 
> draft-ietf-sipcore-status-unwanted.
>
> Given the relatively uncomplicated mechanism being described and the 
> requests for expedited processing, we will be starting our working 
> group last call on the document today. In recognition that the 
> upcoming winter holidays will take some portion of many participants' 
> attention, and that many people will observe a New Year's Holiday on 
> January 2nd, we will run this last call for three weeks, ending on 
> January 3rd. Please review the document and provide comments on before 
> that date.
>
> /a
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 3 Jan 2017 17:26:47 +0000

I read the document and have only a single doubt:

Would it be better to use "may" instead of "MAY" in 4. (except for the sentence about Reason header)? This section is about non-SIP-protocol specific behavior (except the Reason header usage), which is local and does not need to be/is not standardized. Not using RFC2119 keywords seems more appropriate IMHO -but it is not a big deal either way-.

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Tuesday, January 03, 2017 11:48 AM
> To: 'SIPCORE' <[email-masked]>
> Subject: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-
> unwanted
> 
> This is a reminder that the WGLC for this document ends today. If you have
> not had time to read and comment on it, please do so in the next few hours.
> The document is fairly short, and should take very little time to review.
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 3 Jan 2017 19:27:54 +0000

One more question/comment:

Is there a particular reason why 666 shouldn't be applicable to MESSAGE method?

Thanks,
Tolga

> From: Asveren, Tolga
> Sent: Tuesday, January 03, 2017 12:27 PM
> To: 'Adam Roach' <[email-masked]>; 'SIPCORE' <[email-masked]>
> Subject: RE: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-
> unwanted
> 
> Would it be better to use "may" instead of "MAY" in 4. (except for the
> sentence about Reason header)? This section is about non-SIP-protocol
> specific behavior (except the Reason header usage), which is local and does
> not need to be/is not standardized. Not using RFC2119 keywords seems
> more appropriate IMHO -but it is not a big deal either way-.
> 
> Thanks,
> Tolga
> 
> > have not had time to read and comment on it, please do so in the next few
> hours.
> > Even comments like "I have read the document and believe it is ready
> > for publication" would be useful.
> >
> > /a
> >
> > > item has been approved. The document is now adopted by SIPCORE. I
> > > have asked the author to submit subsequent versions of the document
> > > as draft-ietf-sipcore-status-unwanted.
> > >

---

From: "Vijay K.Gurbani" <[email-masked]>
Date: Tue, 3 Jan 2017 14:12:04 -0600

> publication" would be useful.

Adam, Henning: Document is in good shape.  One small nit:

   - S4: s/and reservible./and reversible./

     (I think you mean an action that can be reversed, instead of an
     action that can be reserved.)

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
Email: [email-masked] / [email-masked]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Jan 2017 20:44:49 +0000

I believe
https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-00
addresses this issue. (There's only one MAY, in connection with the Reason header.) If not, please point out what I missed...

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Tuesday, January 03, 2017 12:27 PM
To: Adam Roach <[email-masked]>; 'SIPCORE' <[email-masked]>
Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted

Thanks,
Tolga

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Jan 2017 20:56:05 +0000

Tolga,

I believe it should indeed apply to MESSAGE as well. MESSAGE makes a cameo appearance in the introduction ("typically INVITE or MESSAGE").

Should there be an explicit restriction to methods? I checked the IANA registration and the related RFCs of a few non-3261 response codes, and they generally don't specify the methods they are used with. One reason would be to avoid having to update all the documents defining status codes if SIPCORE adds another SIP method.

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Tuesday, January 03, 2017 2:28 PM
To: Adam Roach <[email-masked]>; 'SIPCORE' <[email-masked]>
Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted

Thanks,
Tolga

> specific behavior (except the Reason header usage), which is local and 
> does not need to be/is not standardized. Not using RFC2119 keywords 
> seems more appropriate IMHO -but it is not a big deal either way-.
> 
> Thanks,
> Tolga
> 
> > This is a reminder that the WGLC for this document ends today. If 
> > you have not had time to read and comment on it, please do so in the 
> > next few
> hours.
> > > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and 
> > > no objections. Our revised charter that includes scope for this 
> > > kind of item has been approved. The document is now adopted by 
> > > SIPCORE. I have asked the author to submit subsequent versions of 
> > > the document as draft-ietf-sipcore-status-unwanted.
> > >
> > > Given the relatively uncomplicated mechanism being described and 
> > > the requests for expedited processing, we will be starting our 
> > > working group last call on the document today. In recognition that 
> > > the upcoming winter holidays will take some portion of many participants'
> > > attention, and that many people will observe a New Year's Holiday 
> > > on January 2nd, we will run this last call for three weeks, ending 
> > > on January 3rd. Please review the document and provide comments on
> > before
> > > that date.
> > >
> > > /a
> > >
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > ilman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM
> > 5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=1TnbdxFZGrU6_AsNQJD_xJ6RP5OKuGq
> > H2wITUbdg4Gs&s=PDIm8MQuwX-JVCng-BEDirWcio4ELjzyIl0OmPl2rgU&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=1TnbdxFZGrU6_AsNQJD_xJ6RP5OKuGqH2wITUbdg4Gs&s=PDIm8MQuwX-JVCng-BEDirWcio4ELjzyIl0OmPl2rgU&e=

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 3 Jan 2017 20:47:06 +0000

Yup, blame auto-correct :-)

Fixed.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Vijay K.Gurbani
Sent: Tuesday, January 03, 2017 3:12 PM
To: Adam Roach <[email-masked]>; Henning Schulzrinne <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted

Cheers,

---

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

Please see inline.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dawes, Peter, Vodafone Group
Sent: Tuesday, January 03, 2017 7:07 AM
To: Andy Hutton <[email-masked]>; Adam Roach <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Hello All,

No prohibition is implied; I will align the wording in the abstract with those in the introduction. I think, in general, for any SIP response code, any SIP entity that receives the code can do what it needs/wants to do (subject to its role in the call flow). I’m not quite sure what you mean by “general adjustment”. Re-reading the sentence, this could be improved to include both the called and calling party: “SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.” Is that clearer?

Please see above; any wording suggestions are welcome.

No, I don’t think this needs to be restricted to phone numbers. As long as the calling party can be identified (tel or SIP URI), I see no reason to restrict it. I will note that this does not depend on the SIP URI. There’s the operational problem of mapping multiple renderings of the same number to be the same “party”, but I don’t think the draft needs to go there, as this seems like an implementation choice. Using the canonicalization procedure in RFC4474bis Section 8.3 is likely a good idea. Should this be called out?

Reading the relevant sections of 4474bis reminds me that anonymous SIP URIs should probably not be included in any URI-specific call handling. I’ve added a sentence identifying the issue, without any normative statements.

Both fixed.

=

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Tue, 3 Jan 2017 16:52:12 -0600

I'm good with all the discussed changes and have just a nit in the "IANA 
Considerations" section:

s/method and response-code sub-registry/"Response Codes" sub-registry

Thanks!

Jean, as an individual

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 03 Jan 2017 21:59:47 -0500

Andy Hutton <[email-masked]> writes:
> But this is not I believe referring to the actual terminating SIP entity
> which is the called users device but is referring to some preceding SIP
> entity probably the service provider.

I suspect that a better wording would be "The terminating SIP service
...".

> Is there a particular reason why 666 shouldn't be applicable to

It should be applicable to any out-of-dialog request (whether or not it
is dialog-forming).

I can imagine a 666 response to SUBSCRIBE as well.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 4 Jan 2017 08:44:38 +0000

Mea culpa (I was deceived by the draft name in the Subject line).

Yes, the new version looks good.

Thanks,
Tolga

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2017 3:45 PM
> To: Asveren, Tolga <[email-masked]>; Adam Roach
> <[email-masked]>; 'SIPCORE' <[email-masked]>
> addresses this issue. (There's only one MAY, in connection with the Reason
> header.) If not, please point out what I missed...
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 4 Jan 2017 08:46:09 +0000

Agreed, the new version looks good to me. I also don't see the need to restrict use of "unwanted" to a specific method. People/Industry is usually more creative than we may imagine and who knows for what other method types it could be utilized.

Thanks,
Tolga

> Sent: Tuesday, January 03, 2017 3:56 PM
> I believe it should indeed apply to MESSAGE as well. MESSAGE makes a
> cameo appearance in the introduction ("typically INVITE or MESSAGE").
> 
> Should there be an explicit restriction to methods? I checked the IANA
> registration and the related RFCs of a few non-3261 response codes, and
> they generally don't specify the methods they are used with. One reason
> would be to avoid having to update all the documents defining status codes if
> SIPCORE adds another SIP method.
> 
> Henning
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAU
> Gr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=1
> TnbdxFZGrU6_AsNQJD_xJ6RP5OKuGqH2wITUbdg4Gs&s=PDIm8MQuwX-
> JVCng-BEDirWcio4ELjzyIl0OmPl2rgU&e=

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 4 Jan 2017 12:13:23 +0000

I like your suggested wording “SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.” for the Abstract clause.

My concerns about the meaning of “caller” are taken care of by the revised wording above and by the comment from Paul Kyzivat to change the wording in Section 2 from “that the caller is unwanted” to “ that calls from this caller are unwanted by the called party.”

I am not an implementer, but it makes sense to me to point out the canonicalization procedure in RFC4474bis Section 8.3 to try to avoid the same number being stored in multiple formats. I guess it could be mentioned in Section 4 “Behavior of SIP Entities”.

Thanks,
Peter

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: 03 January 2017 21:40
To: Dawes, Peter, Vodafone Group
Cc: SIPCORE
Subject: RE: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Please see inline.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dawes, Peter, Vodafone Group
Sent: Tuesday, January 03, 2017 7:07 AM
To: Andy Hutton <[email-masked]<mailto:[email-masked]>>; Adam Roach <[email-masked]<mailto:[email-masked]>>
Cc: SIPCORE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Hello All,

Both fixed.

=

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Jan 2017 16:44:59 +0000

I have added a non-normative reference to RFC 4474bis canonicalization.

Since a lot of the wording has been tweaked, I will submit a draft new version shortly, so that everyone can make sure that I didn’t miss their intent or suggestion.

Henning

From: Dawes, Peter, Vodafone Group [mailto:[email-masked]]
Sent: Wednesday, January 04, 2017 7:13 AM
To: Henning Schulzrinne <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: RE: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Thanks,
Peter

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Jan 2017 16:40:21 +0000

Inline.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Tuesday, January 03, 2017 10:00 PM

Andy Hutton <[email-masked]<mailto:[email-masked]>> writes:

> The abstract states "The terminating SIP entity may use this

> information....".

> But this is not I believe referring to the actual terminating SIP

> entity which is the called users device but is referring to some

> preceding SIP entity probably the service provider.

I suspect that a better wording would be "The terminating SIP service ...".

The current wording is "SIP entities", simply because (on second thought) that even the originating carrier may use the 666 response information, e.g., to determine that one of its customers is violating its terms of service.

"Asveren, Tolga" <[email-masked]<mailto:[email-masked]>> writes:

> Is there a particular reason why 666 shouldn't be applicable to

> MESSAGE method?

It should be applicable to any out-of-dialog request (whether or not it is dialog-forming).

Dale

Added "out-of-dialogue" qualification.

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 5 Jan 2017 09:38:43 +0000

Thanks, I have read revision -01 and my comments are resolved. As a wording suggestion for the last paragraph in section 6, I think adding the words “of response code 666” as below makes the meaning clearer:

“For both individually-authenticated and unauthenticated calls,

   recipients of response code 666 may want to distinguish responses sent before and after

   the call has been answered, ascertaining whether either response

   timing suffers from a lower false-positive rate.”

Regards,

Peter

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: 04 January 2017 16:45
To: Dawes, Peter, Vodafone Group
Cc: SIPCORE
Subject: RE: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Henning

To: Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>

Thanks,
Peter

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jan 2017 23:26:14 +0000

Added the phrase.

________________________________
From: Dawes, Peter, Vodafone Group <[email-masked]>
Sent: Thursday, January 5, 2017 4:38 AM
To: Henning Schulzrinne
Cc: SIPCORE
Subject: RE: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted

Thanks, I have read revision -01 and my comments are resolved. As a wording suggestion for the last paragraph in section 6, I think adding the words "of response code 666" as below makes the meaning clearer:

"For both individually-authenticated and unauthenticated calls,

   timing suffers from a lower false-positive rate."

Regards,

Peter