Digest Fields
draft-ietf-httpbis-digest-headers-13

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-httpbis-digest-headers and RFC 9530, changed IESG state to RFC Published)

[Ballot comment]
# GEN AD review of draft-ietf-httpbis-digest-headers-12

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/hOSKIuNLtGQoGLri4c1auAF9kP4).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-httpbis-message-signatures-16`, but `-17` is
the latest available revision.

### Grammar/style

#### Section 3.2, paragraph 1
```
fication. How to deal with an ignored preferences is a scenario that should b
                          ^^^^^^^^^^^^^^^^^^^^^^
```
The plural noun "preferences" cannot be used with the article "an". Did you
mean "an ignored preference" or "ignored preferences"?

#### Section 6.1, paragraph 2
```
es of Content-Type, Content-Encoding etc). A signature that protects Integri
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### "B.6.", paragraph 7
```
Repr-Digest is designed to be independent from the use of one or more transf
                              ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

#### "B.11.", paragraph 6
```
e Digest field. This resulted in a mixed of formats such as base64, hex or d
                                  ^^^^^
```
The phrase "a mixed of" is not correct. Use a noun, not an adjective, between
"a" and "of".

#### "Appendix E.", paragraph 1
```
ncrypted content * Digest is independent from MESSAGING and HTTP/1.1 is not
                            ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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

[Ballot discuss]
I have a few DISCUSS questions about some of the security aspects of the draft,
that I would like the authors to at least consider.

It seems this new registry is getting pre-populated with a _lot_ of "insecure"
variants. Is there a strong reason why to not only add 1 insecure entry (eg crc32c) ?
New RFCs really should not be adding anything using MD5 or SHA1, even if we
allow/accept it is used insecure (see below for details).

The other question on the IANA Registry I have is the format and registration
policy. Recently, most security related IANA Registries try to use a RECOMMENDED
column that can only be set to Y using a registration policy of RFC Required.
Any other registration (eg via specification required or FCFS) cannot get
RECOMMENDED Y. Also, to change the RECOMMENDED column requires a standards track
RFC (via RFC Required policy). Is there a reason we cannot do the same here? I
also think a Designated Expert should not be able to change what is "standard"
or not, as the word "standard" strongly implies "standard track" or at the very
least "IETF consensus" which is not the same as a DE making a decision on their own.

This would also resolve my issue of specifying things as "standard" (when it
didn't come in via standards track RFC) and "insecure" (which really seems to
mean "secure for this type of usage, but not that type of usage), so I would
strongly prefer this indirection to be removed, and state a usage of "checksum
only" and "signed hash".

Finally, I think some more careful writing is needed around the case of
integrity vs integrity+signature and what it protects against. I don't
think "unintended or malicious data corruption" should be used as a type.
Either talk about "unintended" or talk about "malicious" - the two cannot
be used within a single concept unless you mandate integrity+signature.

If multiple hashes are included, what should happen when the most preferred hash
failed to verify? Should it be treated as failed or should it try other less
preferred but accepted hash algorithms? There should be text clarifying the
behaviour. Personally, I would prefer that only the most preferred hash is
checked and the other hashes are ignored, but perhaps I'm not fully aware of
common operational issues.

[Ballot comment]

        In between connections there is a possibility for unintended
        or malicious data corruption. An HTTP integrity mechanism can
        provide the means for endpoints, or applications using HTTP,
        to detect data corruption and make a choice about how to act on
        it. An example use case is to aid fault detection and diagnosis
        across system boundaries.

I think there is too much subtlety here between starting with "unintended
or malicious data corruption" and then follow that with "detect
data corruption".  It is clear that a hash can detect "unintended"
data corruption, but it is less clear it can detect "malicious" data
corruption, as a malicious actor will just update the digest value. And
the text is inconsistent with the Security Consideration in Section 6.1:

        Integrity fields are not intended to be a general protection
        against malicious tampering with HTTP messages.

        Integrity fields do not provide integrity for [...] fields.

Perhaps "integrity field" then deservers a better name? I would propose
"digest field" but I guess RFC 3230 took that one and this document is
trying to obsolete that. Why not "checksum field" or "hash field" ?

The short fix for the sentence above could be:

        Integrity fields do not provide authenticated integrity for [...]



        Requests to update or change the fields in an existing
        registration are permitted. For example, this could allow for the
        transition of an algorithm status from "standard" to "insecure"
        as the security environment evolves.

As stated in my DISCUSS, it feels odd that a DE can change what "standard" means.
And as stated in my DISCUSS, the term "insecure" feels weird to me.

        Integrity fields do not provide any mitigations for downgrade
        or substitution attacks (see Section 1 of [RFC6211]) of the
        hashing algorithm.

See also my DISCUSS. While one hash field does not, sending multiple
ones could defend it a bit.  If a sha: and sha-256: digest is sent,
and the receiver support sha-256, and the sha-256 hash is wrong but the
sha hash is fine, it should consider the integrity broken (assuming it
deems sha-256 more secure than sha-1).  However, such behaviour should
be defined in this document (eg what to do in the case of multiple
hashes. eg. Only pick up the most preferred one and ignore the rest,
so in the above example one wouldn't even look at the sha: hash at all
if the sha-256 hash failed).

Section 7.2:

Can we omit all the "insecure" entries from the registry ?  This draft is
something new, and whomever implements this should have at this point
sha-256 support available. Is there a performance issue? If there is a need
for something insecure and quick, can we limit this to 1 entry (eg crc32c)
and especially avoid MD5/SHA1 due to complications of those functions
getting blocked in crypto libraries and system wide crypto policies ?

        Also, the Content-MD5 is limited to one specific digest algorithm;
        other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate

Is there a reason not to use SHA-256 instead of SHA-1 in this example?
The use of SHA-1 (or MD5) would be good enough for the purpose of this
draft (ignoring signed hashes) but the MD5 or SHA-1 hash function might
be disallowed or removed from crypto library implementations. If the
difference in performance between SHA-1 and SHA-256 is not an issue, I
would like to see SHA-256 mentioned instead of SHA-1. (and as separate
issue, I would prefer not recommend or even define MD5 or SHA-1 in this
new Registry at all)

        whereas hashing algorithm keys are quoted

"hashing algorithm keys" is a strange term to me. It becomes clear a
few sentences down when we are talking about key/value pairs. Maybe
use "key value" and "hash value" (or qvalue as is used now?) when talking
about "keys" and "values"?

Section 4:

Why does Want-Repr-Digest: and Want-Content-Digest: need to have weights?
Are weight values used for anything else but a preference list? Eg why not
define Want-Repr-Digest: to have its most preferred algo listed first (left).

So instead of:

Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0

Why not:

Want-Repr-Digest: sha-512, sha-256, unixsum
(or even leave out unixsum is not supported or wanted)

The only argument I can see for weights is if you want to define multiple
hash algorithms with the exact same weight, which a left to right notation
wouldn't allow you do. But is that a feature that is really needed?

[Ballot comment]
Thank you to Peter Yee for the SECDIR review.

** Section 2.  Using multiple digests in a single Content-Digest is supported.  There is also guidance that “a recipient MAY ignore any or all of the digests”.  I read that text as “if presented multiple digests, a recipient can choose to look at only one or some subset of the digests.” Is that accurate?  Is there standardized behavior for when a recipient validates/checks both digests and only one is valid?

** Section 4.
  *  key conveys the hashing algorithm (see Section 5);

Shouldn’t this read as “hashing algorithm(s)” as it is possible to send more than one in the field?

** Section 4. 
  *  value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that
      conveys an ascending, relative, weighted preference.  It must be
      in the range 0 to 10 inclusive. 1 is the least preferred, 10 is
      the most preferred, and a value of 0 means "not acceptable".

-- Can multiple algorithms share the same preference value?  For example, could multiple algorithms be labeled “not acceptable”?

-- If yes, would their ordering determine preference?

** Section 6.1.  Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review.  Perhaps:

OLD
  Integrity fields are not intended to be a general protection against
  malicious tampering with HTTP messages. This can be achieved by
  combining it with other approaches such as transport-layer security
  or digital signatures (for example, HTTP Message Signatures
  [SIGNATURES]).


NEW
Integrity fields are not intended to be a general protection against malicious tampering with HTTP messages. In the absence of additional security mechanisms, an on-path, malicious actor can remove or recalculate and substitute a digest value.  This attack can be mitigated by combining mechanisms described in this document with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures [SIGNATURES]).

[Ballot comment]
I'm balloting NOOBJ largely on the basis that the document appears to be of high quality and would probably be clear and usable if only I had the necessary grounding in HTTP's more abstruse corners to make sense of it. (Thank you for the references and examples, those got me halfway there, perhaps. The other half is the part I'm taking on faith.)

I do have a few nits and questions --

## COMMENT

### Section 5, reserved token value

In your description of the Status template field, you have ""reserved" - for algorithms that use a reserved token value that cannot be expressed in Structured Fields". This is a well-formed sentence but I have no idea what it means. I made a desultory attempt to suss it out by searching the document for "token" and this was the only occurrence. If people who will actually be making use of the registry can be expected to make sense of it, then feel free to disregard my comment, of course.

### Section 5, "optionally the key"

A few lines further down you have "Reference(s): pointer(s) to the primary document(s) defining the technical details of the algorithm, and optionally the key". I couldn't work out what "the key" is in this context, that would be placed in the registry. The values you've seeded the registry with don't provide any examples, so I'm none the wiser for having checked there.

## NITS

### Section 6.5, e.g.

In "Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g., encoded) content is persisted.", do you actually mean "i.e." and not "e.g."?

### Appendix A, typo

/entires/1234 should be /entries/1234

[Ballot comment]
Hi,

Thanks for the this document.

A couple of minor comments, that are you welcome to act on, or ignore, at your desire:

1. I'm not an HTTP expert, hence I somewhat struggled with what the definition of an HTTP representation is, although the examples B.1 - B.3 helped.  Perhaps consider a forward reference to the B.1 - B.3 in section 1 or section 1.2.

2. I noted that the "Code Samples" section is marked as being removed from the final RFC, but I wondered why, and whether it wouldn't benefit for being included as informative (non-normative text).

Regards,
Rob

[Ballot comment]
This HTTP tourist was quite confused by the Repr-Digest field. Section 3.2 of RFC9110 says that a representation "consists of a set of representation metadata and a potentially unbounded stream of representation data". So what exactly is the input to the hash function for Repr-Digest? I was expecting to see some of the metadata fields somehow incorporated in the input, but the appendices seem to indicate that the input is just the full, not-range-limited content, in whatever encoding the sender selects.

An unambiguous statement of the Hash algorithm input in each case would be helpful, though maybe it's just because my comfort with the term "representation" is just from having read the definition, rather than working with it.

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

The IANA Functions Operator has completed its review of draft-ietf-httpbis-digest-headers-11. 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 four actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

four new registrations are to be made as follows:

Field Name: Content-Digest
Template:
Status: permanent
Reference: [ RFC-to-be; Section 2 ]
Comment:

Field Name: Repr-Digest
Template:
Status: permanent
Reference: [ RFC-to-be; Section 3 ]
Comment:

Field Name: Want-Content-Digest
Template:
Status: permanent
Reference: [ RFC-to-be; Section 4 ]
Comment:

Field Name: Want-Repr-Digest
Template:
Status: permanent
Reference: [ RFC-to-be; Section 4 ]
Comment:

As this document requests registrations in an Expert Review or 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, also in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

two, existing registrations will be changed as follows:

Field Name: Digest
Template:
Status: obsoleted
Reference: [RFC3230],[ RFC-to-be; Section 1.3 ]
Comment:

Field Name: Want-Digest
Template:
Status: obsoleted
Reference: [RFC3230],[ RFC-to-be; Section 1.3 ]
Comment:

As this also requests changes to registrations in an Expert Review or 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."

Third, a new registry is to be created called the Hash Algorithms for HTTP Digest Fields registry. The new registry will be located on a new registry page - IANA notes that the authors have suggested:

https://www.iana.org/assignments/http-digest-hash-alg/

The new registry will be managed via Specification Required as defined by RFC8126. There are initial registrations in the new registry as follows:

Algorithm Key Status Description Reference(s)
---------------+----------+----------------------------------------+------------------------------
sha-512 standard The SHA-512 algorithm. [RFC6234], [RFC4648], this document.
sha-256 standard The SHA-256 algorithm. [RFC6234], [RFC4648], this document.
md5 insecure The MD5 algorithm. It is vulnerable to [RFC1321], [RFC4648], this document.
collision attacks; see [NO-MD5] and [RFC3174], [RFC4648], [RFC6234] this document.
[CMU-836068]
sha insecure The SHA-1 algorithm. It is vulnerable to [RFC4648], [RFC6234], [UNIX], this document.
collision attacks; see [NO-SHA] and
[IACR-2020-014]
unixsum insecure The algorithm used by the UNIX "sum" [RFC4648], [RFC6234], [UNIX], this document.
command.
unixcksum insecure The algorithm used by the UNIX "cksum" [RFC4648], [RFC6234], [UNIX], this document.
command.
adler insecure The ADLER32 algorithm. [RFC1950], this document.
crc32c insecure The CRC32c algorithm. [RFC9260] appendix B, this document.

Fourth, IANA will deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry located at:

https://www.iana.org/assignments/http-dig-alg/

The IANA Functions Operator understands that these three actions are the only ones 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,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-03-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-digest-headers@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Digest Fields) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Digest Fields'
  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 2023-03-21. 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 defines HTTP fields that support integrity digests.
  The Content-Digest field can be used for the integrity of HTTP
  message content.  The Repr-Digest field can be used for the integrity
  of HTTP representations.  Want-Content-Digest and Want-Repr-Digest
  can be used to indicate a sender's interest and preferences for
  receiving the respective Integrity fields.

  This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP
  fields.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8792: Handling Long Lines in Content of Internet-Drafts and RFCs (Informational - Internet Engineering Task Force (IETF))

# Document Shepherd Writeup for draft-ietf-httpbis-digest-headers

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

  _This document enjoyed broad discussion and two Working Group Last Calls._

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  _There were some philosophical differences about how backwards-compatible we should be, but
  we came to consensus._

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.)

  _Not to my knowledge._

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

  _There are some early implementations underway, and more have expressed interest._

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

  _It's had involvement from security folks, but might benefit from the SecDir review as well._

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.

  _N/A_

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

  _N/A_

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.

  _HTTP examples have been validated._


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

  _Yes_

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

    _The Working Group believes that the relevant listed issues have been addressed._

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

    _Proposed Standard; because we believe there is consensus to publish it._

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

    _Yes; no relevant IPR has been disclosed._

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

    _Implicitly, yes._

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

    - There is a non-ASCII character in the reference for RFC9260. This should be resolved by the RFC Editor.

15. Should any informative references be normative or vice-versa?

    _No._

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

    _N/A._

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

    _RFCs 1321; 1950; 3174; 6234._

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

    _No._

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.

    _Yes; There is no apparent way to reflect this in datatracker; Yes._

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][12]).

    _I checked section 7 of the draft against its references; all looks to be in order._

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.

    - Hash Algorithms for HTTP Digest Fields Registry. The instructions are brief but clear. I'd suggest one or both of the authors.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup for draft-ietf-httpbis-digest-headers

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

  _This document enjoyed broad discussion and two Working Group Last Calls._

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  _There were some philosophical differences about how backwards-compatible we should be, but
  we came to consensus._

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.)

  _Not to my knowledge._

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

  _There are some early implementations underway, and more have expressed interest._

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

  _It's had involvement from security folks, but might benefit from the SecDir review as well._

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.

  _N/A_

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

  _N/A_

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.

  _HTTP examples have been validated._


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

  _Yes_

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

    _The Working Group believes that the relevant listed issues have been addressed._

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

    _Proposed Standard; because we believe there is consensus to publish it._

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

    _Yes; no relevant IPR has been disclosed._

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

    _Implicitly, yes._

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

    - There is a non-ASCII character in the reference for RFC9260. This should be resolved by the RFC Editor.

15. Should any informative references be normative or vice-versa?

    _No._

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

    _N/A._

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

    _RFCs 1321; 1950; 3174; 6234._

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

    _No._

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.

    _Yes; There is no apparent way to reflect this in datatracker; Yes._

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][12]).

    _I checked section 7 of the draft against its references; all looks to be in order._

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.

    - Hash Algorithms for HTTP Digest Fields Registry. The instructions are brief but clear. I'd suggest one or both of the authors.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html