[sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-callinfo-spam-04: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-callinfo-spam-04: No Objection

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-callinfo-spam/



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

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.