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

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba 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 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