Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR)
draft-ietf-stir-identity-header-errors-handling-08

[Ballot comment]
Thank you for the work on this document.

Many thanks to Martin Dürst for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Jqiy69abgnAMBuSH7oLpt1Ae62I/, and to the author for addressing his comments.

[Ballot comment]
# Sec AD review of draft-ietf-stir-identity-header-errors-handling-07

CC @paulwouters

See https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions
for more information about how to handle DISCUSS and COMMENT positions.

This review uses the format specified in https://github.com/mnot/ietf-comments/
which allows automated tools to process items (eg to produce github issers)

## Comments

### "ppi" parameter

```
  The association of a Reason header field
  and error to a specific Identity header field is accomplished by
  adding a PASSporT identifier, "ppi", parameter containing the
  PASSporT string as an identifier for the identity header and
  corresponding PASSporT that generated the error to the Reason header
  field.  The "ppi" parameter for the Reason header field is
  RECOMMENDED in particular [...]
```
It feels like the "is accomplished" really means the "ppi" parameter MUST
be used, yet further on it states the "ppi parameter" is only RECOMMENDED ?
Should this RECOMMENDED not be REQUIRED? Also the construct of
"RECOMMENDED in particular" is a little odd.

Why not:

For a SIP INVITE containing multiple Identity header fields, the
"ppi" parameter for the Reason header field is REQUIRED.


### 7 lines is a lot for a single sentence

```
  In cases where local policy dictates that a call should continue
  regardless of any verification errors that may have occured,
  including 4XX errors described in [RFC8224] Section 6.2.2, then the
  verification service MUST NOT send the 4XX as a response, but rather
  include the error response code and reason phrase in a Reason header
  field, defined in [RFC3326], in the next provisional or final
  responses sent to the authentication service.
```

This sentence does not parse (due to the ", then the"). It is also 7 lines
long so it would improve readability to split this in various sentences.

[Ballot comment]
Thanks for this short, readable, and to the point document.

I did find a couple of nits. In both cases I leave it to you to decide if a change is called for, no need to reply.

1. In Section 5, I had trouble with this sentence:

"As implied and defined in [RFC8224], error codes associated with STIR targeted at authentication services that produced a specific identity header field represent a single error occurring with the verification and processing of that identity header field."

I'm willing to believe that for someone expert in STIR, SIP, et al, that sentence might be parsable into something that makes sense. It defied me, though, so I mention it in case you want to re-word it.

2. In Section 6, isn't this a comma splice and it should really be two sentences?

"As mentioned previously, the potential use of multiple Reason header fields defined in [RFC3326] is updated in [I-D.ietf-sipcore-multiple-reasons] allowing multiple Reason header fields with the same protocol value, for this specification "STIR" should be used for any STIR error defined in [RFC8224] or future specifications."

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-stir-identity-header-errors-handling-07

CC @evyncke

Thank you for the work put into this document.

Please find below one nit.

Special thanks to Ben Campbell for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## NITS

### Placement of ';' in the examples

Just to exhibit my lack of SIP/STIR knowledge, I was wondering about the placement of ';' in the different examples, e.g.,
```
Reason: STIR ;cause=436 ;text
Reason: STIR ;cause=438 ; text
```

I guess that this is not a SIP violation but it looks weird to the reader.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

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

The IANA Functions Operator has completed its review of draft-ietf-stir-identity-header-errors-handling-05. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there are two actions which we must complete.

First, in the Reason Protocols registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

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

a new registration is to be made as follows:

Protocol Value: STIR
Protocol Cause: STIR Error Code
Reference: [RFC8224]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

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

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

a new registration is to be made as follows:

Header Field: Reason
Parameter Name: ppi
Predefined Values: No
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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-11-03):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, draft-ietf-stir-identity-header-errors-handling@ietf.org, stir-chairs@ietf.org, stir@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Identity Header Errors Handling) to Proposed Standard


The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document: - 'Identity Header Errors
Handling'
  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
last-call@ietf.org mailing lists by 2022-11-03. 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


  This document extends STIR and the Authenticated Identity Management
  in the Session Initiation Protocol (SIP) error handling procedures to
  include the mapping of verification failure reasons to STIR defined
  4xx codes so the failure reason of an Identity header field can be
  conveyed to the upstream authentication service when local policy
  dictates that the call should continue in the presence of a
  verification failure.  This document also defines procedures that
  enable a failure reason to be mapped to a specific Identity header
  for scenarios that use multiple Identity header fields where some may
  have errors and others may not and the handling of those situations
  is defined.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
  There was general agreement among a fairly small group of STIR participants.
  This group included people with SIP and STIR implementation experience.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  There was no significant controversy. There were some architectural questions
  and some questions about potential privacy leaks that that were worked
  through to consensus. One participant questioned whether the mechanism
  could be deployed in practice, but most active participants did not see a
  problem.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 one has threatened an appeal or expressed extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
  The shepherd is not aware of existing implementations. However, this work is
  likely to be adopted by the ATIS/SIP Forum IP-NNI task force, which will
  likely result in wide-spread implementation in the voice service provider
  community.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
  This work, like all work in STIR, is closely related to SIP, which is
  maintained by SIPCORE. However, there is enough cross-participation between
  the groups that a separate review in SIPCORE is probably not needed. There
  is a companion draft to this work in SIP
  [draft-ietf-sipcore-multiple-reasons].
 
6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
  The only additional expert review required is for registration of a new
  "Reason Protocol" in the IANA Session Initiation Protocol (SIP) Parameters
  registry. The registration procedure is "Specification Required"

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
  The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
  The draft does not use formal languages.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
  In the shepherd's opinion, this document is ready to be handed off to the AD.
  The shepherd found a small number of non-substantive nits that have been
  shared with the author and do not need to block progress. They can wait
  for the next update opportunity.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
   
    The shepherd finds no such issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent
   
    The intended status is Proposed Standard. It describes an extension for
    error reporting for STIR, which is comprises multiple Proposed Standards.
    This is correctly reflected in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
    The author has explicitly confirmed that all IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.  There are none.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
   
    This draft has a single author, whose willingness to be listed is implied
    by the submission of the draft. But the author has explicitly confirmed,
    anyway.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
   
    The document shepherd review of the document did not find any
    issues related to the Guidelines to Authors of Internet-Drafts.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
    All references are properly normative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    All references are IETF RFCs or drafts

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
    The only unpublished dependency is draft-ietf-sipcore-multiple-reasons,
    which has already been submitted to the IESG.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
   
    This draft does not affect the status of any existing RFC.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
    The shepherd has reviewed the IANA considerations and confirms all the
    above.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
   
    This draft does not create new registries.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
  There was general agreement among a fairly small group of STIR participants.
  This group included people with SIP and STIR implementation experience.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  There was no significant controversy. There were some architectural questions
  and some questions about potential privacy leaks that that were worked
  through to consensus. One participant questioned whether the mechanism
  could be deployed in practice, but most active participants did not see a
  problem.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 one has threatened an appeal or expressed extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
  The shepherd is not aware of existing implementations. However, this work is
  likely to be adopted by the ATIS/SIP Forum IP-NNI task force, which will
  likely result in wide-spread implementation in the voice service provider
  community.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
  This work, like all work in STIR, is closely related to SIP, which is
  maintained by SIPCORE. However, there is enough cross-participation between
  the groups that a separate review in SIPCORE is probably not needed. There
  is a companion draft to this work in SIP
  [draft-ietf-sipcore-multiple-reasons].
 
6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
  The only additional expert review required is for registration of a new
  "Reason Protocol" in the IANA Session Initiation Protocol (SIP) Parameters
  registry. The registration procedure is "Specification Required"

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
  The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
  The draft does not use formal languages.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
  In the shepherd's opinion, this document is ready to be handed off to the AD.
  The shepherd found a small number of non-substantive nits that have been
  shared with the author and do not need to block progress. They can wait
  for the next update opportunity.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
   
    The shepherd finds no such issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent
   
    The intended status is Proposed Standard. It describes an extension for
    error reporting for STIR, which is comprises multiple Proposed Standards.
    This is correctly reflected in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
    The author has explicitly confirmed that all IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.  There are none.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
   
    This draft has a single author, whose willingness to be listed is implied
    by the submission of the draft. But the author has explicitly confirmed,
    anyway.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
   
    The document shepherd review of the document did not find any
    issues related to the Guidelines to Authors of Internet-Drafts.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
    All references are properly normative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    All references are IETF RFCs or drafts

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
    The only unpublished dependency is draft-ietf-sipcore-multiple-reasons,
    which has already been submitted to the IESG.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
   
    This draft does not affect the status of any existing RFC.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
    The shepherd has reviewed the IANA considerations and confirms all the
    above.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
   
    This draft does not create new registries.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
  There was general agreement among a fairly small group of STIR participants.
  This group included people with SIP and STIR implementation experience.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  There was no significant controversy. There were some architectural questions
  and some questions about potential privacy leaks that that were worked
  through to consensus. One participant questioned whether the mechanism
  could be deployed in practice, but most active participants did not see a
  problem.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 one has threatened an appeal or expressed extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
  The shepherd is not aware of existing implementations. However, this work is
  likely to be adopted by the ATIS/SIP Forum IP-NNI task force, which will
  likely result in wide-spread implementation in the voice service provider
  community.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
  This work, like all work in STIR is closely related to SIP, which is
  maintained by SIPCORE. However, there is enough cross-participation between
  the groups that a separate review in SIPCORE is probably not needed. There
  is a companion draft to this work in SIP
  [draft-ietf-sipcore-multiple-reasons].
 
6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
  The only additional expert review required is for registration of a new
  "Reason Protocol" in the IANA Session Initiation Protocol (SIP) Parameters
  registry. The registration procedure is "Specification Required"

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
 
  The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
  The draft does not use formal languages.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
  In the shepherd's opinion, this document is ready to be handed off to the AD.
  The shepherd found a small number of non-substantive nits that have been
  shared with the author and do not need to block progress. They can wait
  for the next update opportunity.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
   
    The shepherd finds no such issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent
   
    The intended status is Proposed Standard. It describes an extension for
    error reporting for STIR, which is comprises multiple Proposed Standards.
    This is correctly reflected in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
    The author has explicitly confirmed that all IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.  There are none.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
   
    This draft has a single author, whose willingness to be listed is implied
    by the submission of the draft. But the author has explicitly confirmed,
    anyway.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
   
    The document shepherd review of the document did not find any
    issues related to the Guidelines to Authors of Internet-Drafts.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
    All references are properly normative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    All references are IETF RFCs or drafts

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
    The only unpublished dependency is draft-ietf-sipcore-multiple-reasons,
    which has already been submitted to the IESG.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
   
    This draft does not affect the status of any existing RFC.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
    The shepherd has reviewed the IANA considerations and confirms all the
    above.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
   
    This draft does not create new registries.