Subject: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-spam-00

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 10 Oct 2016 14:38:07 +0000

1)	Section 1, 1st paragraph, uses the term "illegal telemarketing" but the abstract just says "telemarketing". I assume both legal and illegal telemarketing would fall in scope.

2)	Section 1, and section 3. I think any use of the term "emergency" needs to distance itself from any emergency call in for example "112" or "911" usage. I would not expect this capability to be used on such emergency calls, if there is additional data to be provided on such calls, then we have a defined way of doing that.

3)	Section 1: Text "The Call-Info header field MAY be signed
   using a future "ppt" extension to [I-D.ietf-stir-rfc4474bis].  To
   ensure that an untrusted originating caller does not mislead the
   called party, a new feature tag, sip.call-info.spam, indicates
   whether the terminating carrier will remove untrusted information."

I don't know whether it is intended to define this in the timeframe of this i-d. If yes, then I assume it will be replaced by a normative reference later in the document. If no, I suggest it is removed, as we should not really hint that future work plan that may or may not exist.

4)	Section 1: I would suggest avoing the use of normative language in section 1, which is labelled introduction, particularly as in this case it comes before section 2 which contains the RFC 2119 language. These requirements need to appear later in the document.

5)	Section 1: 

"   SIP entities MUST add a new Call-Info header field, rather than add
   parameters to an existing one.  There MAY be several Call-Info header
   fields in one request."

It is not clear to me whether multiple generators of Call-Info header field parameters in accordance with this draft along the call path would create multiple Call-Info header fields, or would be permitted to combine them into one Call-Info header field. Given that there is no indication of which entity generated the data, it probably does not matter that they have to be separate Call-Info header fields, only that they are distinct from other Call-Info header field usages.

6)	Section 3: Values with parameters and types. There are hints that certain parameters carry values, eg. "spam" with a percentage, but no indication of how the syntax of this works. 

7)	Section 3: There are other parameters and types that could well carry values, such as "business" which could be followed by a company name of business registration number. Obviously that may sometimes apppear in the From or Calling Party ID, but there may be instances where more specific and different information would be inserted there.

8) 	Section 3. "spam" appears both as a parameter in its own right, and as a "type" Under what conditions do you expect one versus the other to be used?

9)	Section 5: For types, Section 3 states "Additional labels are registered with IANA." However there seems to be no registration of the values defined under types.

10)	Section 6. The mechanism defined in the security considerations does not cater for spoofing by MITM attackers between the registrar and the UA. Additional security that uses the same security tunnel for both the REGISTER and the subsequent messages would be needed for that.

Keith