SIP Call-Info Parameters for Labeling Calls
draft-ietf-sipcore-callinfo-spam-04

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alissa Cooper Discuss

Discuss (2019-10-02)
(1) It seems to me that there is a privacy consideration that is not discussed in this document, namely the unwanted exposure of the call types to third parties. If I'm receiving a lot of calls from the debt collection agency and my UA displays that information in my call log for anyone who might have access to my phone, or an eavesdropper can glean that information from intercepting my SIP signaling, as a user I probably want to be able to tell my SIP provider to disable this. Perhaps this capability to request that certain Call-Info headers not be sent is captured generically in RFC 3261 (I don't remember), in which case pointing that out here would be good. Or if not, I think something needs to be said about the ability for callees to turn off the transmission of these type labels.

(2) I'm a little uncomfortable with this document being the definitive source for call types for all phone systems everywhere, since presumably these types have other uses in telephony beyond the use envisioned by this spec. Is there another document that could be cited as the definitive source for these types?
Comment (2019-10-02)
Please respond to the Gen-ART review.

Magnus Westerlund Discuss

Discuss (2019-10-01)
Section 7:

Which ABNF is used here, please provide a reference. I also very much would appreciate that the normative reference for "iana-token" was provided in this section rather than 8.3.
Comment (2019-10-01)
Section 8.3:

So I am slightly worried that there are no recommendations on the criteria the expert should have for accepting or rejecting an registration request. Well there is always the possibility for appealing a registration request if it gets rejected. Considering that these labels are very much social constructs they will be culture dependent and what may be acceptable in one culture may not be in another. I would expect that being very liberal is the only way forward here. At the same time allowing many overlapping labels could enable attacks on the system.  Was these aspects discussed in the WG?

Adam Roach Yes

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2019-10-01)
Section 1.  Per the reference to “the historical precedent of the ‘blue pages’”, is that a references understandable outside of the US/Canada?

Section 1.  Per “In the United States, industry organizations have proposed …”, is there a citation for this activity?

Section 4.  Typo.  s/equipement/equipment/

Section 8.1.  ‘Confidence’ appears to be missing from the list of new parameters to register in "Header Field Parameters and Parameter Values" under “Call-Info”.

Section 8.3.  Per idnits, RFC 5226  is obsoleted by RFC 8126

Section 9.  Per “Thus, a UAS SHOULD NOT trust the information … unless … the UAS is protected by TLS [RFC8446]”, is this text explicitly saying only TLS v1.3 is trusted (i.e., TLS v1.2 or a future TLS v2 would not be trusted)?  I’d recommend indicating a TLS version number (e.g., TLS 1.2+ or per RFC7525)

Section 9.  Nit.  /the called party is mislead/the called party is misled/

Benjamin Kaduk No Objection

Comment (2019-10-02)
I agree with Alissa about the missing privacy considerations.

Section 1

   In many countries, an increasing number of calls are unwanted
   [RFC5039], as they might be fraudulent, telemarketing or the
   receiving party does not want to be disturbed by, say, surveys or
   solicitation by charities.

nit: the list structure is not parallel, as "fraudulent" and
"telemarketing" apply to the call themselves, but "the receiving party
does not want to be disturbed" describes the callee.

   if the registrar is part of a PBX.  Thus, the entity inserting the
   Call-Info header field and the UAS relying on it SHOULD be part of
   the same trust domain [RFC3324].  Conversely, the entity signing the

I'm not sure if this ("SHOULD") is an attribute that one or more parties
is expected to take action to ensure is the case, or merely a
description of what the scenario is already expected to be.

Section 4

   confidence  The 'confidence' parameter carries an estimated
      [...]
      specification.  If a 'type' is not specified, this parameter
      estimates the likelihood that the call is unwanted spam by the
      called party.  If the confidence level is not specified, the

The 'type' parameter is mandatory, so I don't see how this situation
could arise.

Section 5

   treated as a hint or estimate.  Each entity inserting type
   information will need to define its own policy as to the level of
   certainty it requires before it inserts type information.

It's probably okay to leave this unspecified, since the header is in
some sense largely for use between callees and their SIP providers, but
do we want to give some indication that these two parties could exchange
information about what policy is being used?

   business  Calls placed by businesses, i.e., an entity or enterprise
      entered into for profit.  This type is used if no other, more
      precise, category fits.

Aren't we supposed to have some reasonable level of confidence in
classification before applying any label at all?  It's not clear to me
that this text about catch-all/fallback usage is appropriate.

Section 7

If we felt like it, we could tighten up ci-confidence to not allow,
e.g., a percentage value of 999.

Section 9

   capability.  B2BUAs or proxies that maintain user registrations MUST
   remove any parameters defined in this document that were provided by
   untrusted third parties.

Is the intent to impose this requirement on all B2BUAs globally
(including those that do not otherwise implement this specification) or
just ones that are adding Call-Info header fields or something else?

   Thus, a UAS SHOULD NOT trust the information in the "Call-Info"
   header field unless the SIP session between the entity inserting the
   header field and the UAS is protected by TLS [RFC8446].

I agree with the secdir reviewer that we need to say more about how the
server is authenticated for this TLS connection.  If we describe this as
"SIPS" then the RFC 3261 requirement for "mutual TLS authentication"
(still underspecified, but no longer this document's responsibility)
kicks in.

Warren Kumari No Objection

Barry Leiba No Objection

Comment (2019-09-16)
I have a number of minor comments that I hope you'll consider.

— Section 3 —

   SIP request MAY contain several Call-Info header instances of purpose
   "info", either as a single header with a comma-separated list of
   header values or separate headers, or some combination.

Nit: Correctly used, “either” selects one of two choices, not from among three or more.  I suggest this:

NEW
   SIP request MAY contain several Call-Info header instances of purpose
   "info", as a single header with a comma-separated list of header
   values or as multiple headers, each with one or more header values.
END

   If the entity
   inserting the header field does not have information it wants to link
   to, it MUST use an empty data URL [RFC2397] as a placeholder, as in
   "data:,".  (The Call-Info header field syntax makes the URI itself
   mandatory.)

Nit: The parenthesized bit struck me as oddly placed; I suggest this:

NEW
   Because the Call-Info header field syntax makes the URI mandatory,
   if the entity inserting the header field does not have information it
   wants to link to, it MUST use an empty data URL (“data:,”) [RFC2397]
   as a placeholder.
END

— Section 4 —

   All of the parameters listed below are optional and may appear in any
   combination and order.  Their ABNF is defined in Section 7.  All
   except the 'type' parameter are optional.

The third sentence contradicts the first (I’m guessing it’s a paste error).  I suggest this:

NEW
   Call-Info header field parameters are listed below.  Their ABNF is
   defined in Section 7, and they may appear in any combination and
   order.  The ‘type’ parameter is REQUIRED, and all others are OPTIONAL.
END

Or, if I guessed wrong about the ‘type’ parameter, the last sentence would be “All parameters are OPTIONAL.”

   source  The source parameter identifies the entity, by host name,
      domain or IP address, that inserted the 'confidence', 'origin' and
      'type' parameters.  It uses the "host" ABNF syntax.

Where is the “host” ABNF syntax defined?  Perhaps a citation here would help.

— Section 5 —

   generally based on the caller's telephone number or possibly an
   assertion by a trusted caller, as the content cannot be not known.

What does “as the content cannot be not known” mean?  Can you please rephrase this?

— Section 8.1 —
The first entry in the table is incorrectly formatted: it has the reference field first instead of last.

— Section 9 —

   as otherwise spoofed calls would likely be mislabeled and
   thus increase the likelihood that the called party is mislead,

“misled”

   Thus, this information MUST
   only be added calls with an attestation level of "Full Attestation"
   [RFC8588] or for calls where the SIP entity inserting the header
   knows to have correct calling number information, e.g., because the
   call originated within the same PBX or the same carrier and the
   operating entity ensures that caller ID spoofing is highly unlikely
   within their realm of responsibility.

“only be added to calls”
“or to calls”
“knows it has correct calling number information”

Actually, the sentence is too long anyway, so I suggest splitting it.  How about this?:

NEW
   Thus, this information MUST
   only be added to calls with an attestation level of "Full Attestation"
   [RFC8588] or to calls where the SIP entity inserting the header
   knows it has correct calling number information. An example of how it
   might know that is if the call originated within the same PBX or the
   same carrier, and the operating entity ensures that caller ID spoofing
   is highly unlikely within their realm of responsibility.
END

Alexey Melnikov No Objection

Comment (2019-09-22)
Thank you for this document.

I agree with Barry’s comments. One extra nit from myself:

In 8.1.  SIP Call-Info Header Field Parameters:

The order of fields in the first registration is rotated by one field. I don’t think this was intended.

Alvaro Retana No Objection

Comment (2019-10-03)
I support Alissa's DISCUSS.

Martin Vigoureux No Objection

Comment (2019-09-30)
Please expand B2BUA on first use.

Éric Vyncke No Objection

Comment (2019-09-30)
Thank you for the work put into this document. Please find a couple of COMMENTs and NITs below.

Regards,

-éric

== COMMENTS ==

-- Section 1 --
C.1) I suggest to remove or explain "blue pages" as it probably a USA thing (I have no clue what are those pages being based in Belgium).

-- Section 4 --
C.2) the word "probability" is used with a range of 0 to 100. This is somehow confusing as the word "probability" has a mathematical definition which is not applicable here, "confidence" or "certainty' could be a better wording.

C.3) using an IP address as the source may not be very useful for most applications/users/consumers of this header. Why not having a FQDN as a MUST?

-- Section 5 --
C.4) In the first paragraph, I cannot figure out how to both have "Other strings may be used" and "Additional labels are registered with IANA." in the same paragraph.
	
-- Section 6.2 --
C.5) is there a reason why "http" is used rather than "https" ?

== NITS ==

-- Section 5 --
N.1) in the enumeration of labels, adding a ":" after the label would improve the readability.

-- Section 8.1 --
The table is misaligned.

Ignas Bagdonas No Record

Suresh Krishnan No Record

Mirja Kühlewind No Record