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

[Ballot discuss]
Taking over Alissa's DICSUSS, as a reminder to check this when a new revision becomes available:

> (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?

[Ballot comment]
Transfering my discuss as I step down. Zahed will take this over.


Discuss:
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.

Comments:

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?

[Ballot comment]
I concur with most or all of Barry's suggested edits and encourage you to consider them when preparing a new version.  I also support Alissa's and Magnus' DISCUSS positions.

The third paragraph of Section 3 left me uncertain about whether all the references to "header" vs. "header field" were correct.  Might be worth another look.

In the lists in Sections 4 and 5, I suggest putting colons after each of the hanging labels.  Separating them from the prose by just a couple of spaces doesn't seem to be enough.

I'm curious about the second paragraph in Section 9; under what circumstances might one deviate from the SHOULD?

[Ballot comment]
I'll take over Adam's "Yes" position shortly, after I check on a process point.

I concur with most or all of Barry's suggested edits and encourage you to consider them when preparing a new version.  I also support Alissa's and Magnus' DISCUSS positions.

The third paragraph of Section 3 left me uncertain about whether all the references to "header" vs. "header field" were correct.  Might be worth another look.

In the lists in Sections 4 and 5, I suggest putting colons after each of the hanging labels.  Separating them from the prose by just a couple of spaces doesn't seem to be enough.

I'm curious about the second paragraph in Section 9; under what circumstances might one deviate from the SHOULD?

[Ballot 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.

[Ballot discuss]
(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?

[Ballot discuss]
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.

[Ballot comment]
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?

[Ballot comment]
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/

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot 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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sipcore-callinfo-spam-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Header Field Parameters and Parameter Values registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

four, new registrations will be made as follows;

Header Field: Call-Info
Parameter Name: confidence
Predefined Values: No
Reference: [ RFC-to-be ]

Header Field: Call-Info
Parameter Name: origin
Predefined Values: No
Reference: [ RFC-to-be ]

Header Field: Call-Info
Parameter Name: source
Predefined Values: No
Reference: [ RFC-to-be ]

Header Field: Call-Info
Parameter Name: type
Predefined Values: Yes
Reference: [ RFC-to-be ]

Second, in the SIP Feature-Capability Indicator Registration Tree registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new registration is to be made as follows:

Name: sip.call-info.spam
Description: This feature-capability indicator when used in a REGISTER response indicates that the server will add, inspect, alter and possibly remove the Call-Info header field parameters defined in the reference.
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the Call-Info Type registry. The new registry will be located on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

The new registry will be managed via Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Call-Info Type: business
Description: 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.
Reference: [ RFC-to-be ]

Call-Info Type: debt-collection
Description: Calls related to collecting of debt owed or alleged to be owed by the called party.
Reference: [ RFC-to-be ]

Call-Info Type: emergency-alert
Description: Calls that provide the recipient warnings and alerts regarding a pending or on-going emergency. (This call type is unrelated to emergency calls placed by individuals using emergency numbers such as 9-1-1 or 1-1-2.)
Reference: [ RFC-to-be ]

Call-Info Type: fraud
Description: The call is considered to be fraudulent.
Reference: [ RFC-to-be ]

Call-Info Type: government
Description: A call placed by a government entity, if no more specific label such as "health" or "debt-collection" is known or applies.
Reference: [ RFC-to-be ]

Call-Info Type: health
Description: Informational calls by health plans, health care clearinghouses or health care provider, where health care means care, services, or supplies related to the health of an individual.
Reference: [ RFC-to-be ]

Call-Info Type: informational
Description: Calls intended to convey information to the called party about a transaction such as package delivery, appointment reminder, or order confirmation.
Reference: [ RFC-to-be ]

Call-Info Type: not-for-profit
Description: A call placed by a not-for-profit organization, including for soliciting donations or providing information.
Reference: [ RFC-to-be ]

Call-Info Type: personal
Description: A non-business, person-to-person, call, e.g., from a residential line or personal mobile number.
Reference: [ RFC-to-be ]

Call-Info Type: political
Description: Calls related to elections or other political purposes.
Reference: [ RFC-to-be ]

Call-Info Type: public-service
Description: Calls that provide the recipient information regarding public services, e.g., school closings.
Reference: [ RFC-to-be ]

Call-Info Type: prison
Description: Calls from jails, prisons and other correctional facilities.
Reference: [ RFC-to-be ]

Call-Info Type: spam
Description: A call that is likely unwanted, if not otherwise classified.
Reference: [ RFC-to-be ]

Call-Info Type: spoofed
Description: The calling number for this call has been spoofed. (For example, the call has failed STIR validation [RFC8224] within the SIP service provider network or the telephone number is not a valid number or is known not to have been signed.)
Reference: [ RFC-to-be ]

Call-Info Type: survey
Description: A call that solicits the opinions or data of the called party.
Reference: [ RFC-to-be ]

Call-Info Type: telemarketing
Description: Calls placed in order to induce the purchase of a product or service to the called party.
Reference: [ RFC-to-be ]

Call-Info Type: trusted
Description: The call is being placed by a trusted entity and falls outside the other categories listed. This may include call backs, e.g., from a conferencing service, or messages from telecommunication carriers and utilities.
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-09-14):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, sipcore-chairs@ietf.org, draft-ietf-sipcore-callinfo-spam@ietf.org, sipcore@ietf.org, br@brianrosen.net, Brian Rosen
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SIP Call-Info Parameters for Labeling Calls) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core WG
(sipcore) to consider the following document: - 'SIP Call-Info Parameters for
Labeling Calls'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Called parties often wish to decide whether to accept, reject or
  redirect calls based on the likely nature of the call.  For example,
  they may want to reject unwanted telemarketing or fraudulent calls,
  but accept emergency alerts from numbers not in their address book.
  This document describes SIP Call-Info parameters and a feature tag
  that allow originating, intermediate and terminating SIP entities to
  label calls as to their type, confidence and references to additional
  information.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3324: Short Term Requirements for Network Asserted Identity (Informational - IETF stream)

This is my AD Evaluation of draft-ietf-sipcore-callinfo-spam-03. I have one major comment, and a few minor and editorial comments. I’d like to resolve the major comment prior to IETF last call.

*** Major Comments ***

The draft needs to better describe the trust model. Currently, it says that a UA must ignore any spam parameters unless the registrar included the Feature-Caps tag. That implies the UA trusts the SIP service to label spam; I’m not sure that will always be true.

Likewise, it’s not clear to me when the callee’s SIP service might trust spam labeling from the caller’s service or some intermediary between them. I expect that we will see bad actors label everything as “government” or “health”. There’s a mention of signing the parameters, but that’s dependent upon a hypothetical STIR extension that may or may not exist.

Perhaps the best we can do is say the callee’s service needs to use it’s own local policy to decide what to trust. Even then, do we expect at least TLS integrity protection of the spam parameters between the caller and callee services? Do we expect calling number authentication  (i.e. STIR)?

I don’t mean to say that I know what the right answers are here, but I think the security considerations need to at least document the assumptions and potential issues or vulnerabilities, especially if there’s a risk of attackers tampering with the labels.

*** Minor Comments ***

§2: Is there a reason not to use the new boilerplate from RFC 8174? There are a few lower case instances of “may”; these are ambiguous under the original 2119 boilerplate.

§3: I don’t think it is appropriate to use a normative MAY when talking about a hypothetical future passport extension that may or may not ever happen.

Also, the reference for passport (ppt) should be RFC 8225.

§4, definition of “reason”: The definition describes extended information, not the “reason” in the normal sense of the term. In particular, I would normally expect a reason phrase to be human-readable, which would have i18n considerations. Is it too late to call this something different?

§5:
-  definition of “informational”: It’s not clear to me if the calling party is supposed to believe that a business relationship exists, or if it “is believed to” have such a relationship by whatever inserts the label. If the latter, how would it know? (This relates to my major comments about the trust model).

- definition of “spoofed”: How does this interact with STIR?

§11.2: Depending on the resolution of my major comments, the reference to 4474bis (now RFC8224) may need to be normative.

*** Editorial Comments ***

§1, 1st paragraph, “but unwanted callers may not provide their true name or use a name that
misleads”: I suggest “... may not provide their true name or _may_ use a name that misleads...” to avoid ambiguity about whether the “not” applies to both alternatives or just the first.

§3:
- first paragraph, "This document describes a new set of optional parameters and usage
for the SIP [RFC3261] Call-Info header field, purpose "info", for
labeling the nature of the call.”: I suggest ‘...with a purpose of “info...” ‘

- Third paragraph, "MAY be several Call-Info header instances”: That “MAY” seems like a statement rather than permission.

§6.2: The heading says “INVITE request”, but the contents are not an INVITE request. I assume it’s intended to be a Caller-Info header field as it might appear in an INVITE request? If so, please say that explicitly.

1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard.  This is an extension to the SIP protocol and standards track is appropriate.  Standards Track is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
Called parties often wish to decide whether to accept, reject or
redirect calls based on the likely nature of the call.  For example,
they may want to reject unwanted telemarketing or fraudulent calls,
but accept emergency alerts from numbers not in their address book.
This document describes SIP Call-Info parameters and a feature tag
that allow originating, intermediate and terminating SIP entities to
label calls as to their type, confidence and references to additional
information.

Working Group Summary:
This document fits into the general area the stir working group has been addressing, but deal with the problem of how a user expresses their wishes to their service provider to handle incoming calls based on information mechanisms like stir would provide.  It is a simple extension to the existing Call-Info header and is a relatively uncomplicated document.  It had a relatively smooth path through the normal sipcore process and has generally been well received.

Document Quality:
Several of the core sip experts have reviewed the document, but only offered relatively minor suggestions, which were incorporated in the text. The shepherd considers this to be a high quality document.

Personnel:
Who is the Document Shepherd? Brian Rosen, sipcore co-chair
Who is the Responsible Area Director? Ben Campbell

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has read every version of this draft.  He believes the document is ready to publish

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
None needed

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosures have been filed on this document

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
This document has good consensus.  All of our regulars have read it, several have provided reviews.  It did not get a great deal of discussion, but chairs feel that is largely because it was a simple, uncomplicated mechanism

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
There are some very minor nits (lines too long, reference that needed to be updated,..). The shepherd will make sure these are addressed prior to publication

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
No special reviews needed.

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
None.  The current version references a draft which has now been published as  RFC8224
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This document does not change the status of any other document

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The document registers several new entries and creates a new registry.  The IANA instructions are clear. 
 
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
The new registry (Call-Info Types) will require a new Expert Reviewer.  The document author (Henning Shulzrinne) is the obvious choice for an expert.  The expert would not need much domain expertise to provide an adequate review, so finding an expert should be easy.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
There is a very small piece of ABNF in the document which has had adequate review, including by the document shepherd.  It fits well with existing sip ABNF.