Shepherd writeup
draft-ietf-cose-hash-envelope

# Shepherd Writeup for [COSE Hash
Envelope](https://datatracker.ietf.org/doc/draft-ietf-cose-hash-envelope/)

## Document History

### 1. Was the document considered in any WG, and if so, why was it not adopted
as a work item there?

No. Although it was discussed with members of the SCITT WG it was always seen
as appropriate for the more generally useful layer of COSE.

### 2. Was there controversy about particular points that caused the WG to not
adopt the document?

No.

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

### 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 recommends) or elsewhere (where)?_

This is not a protocol document. However, I am aware that at least 2
implementations exist, from DataTrails and Microsoft.

## Additional Reviews

### 5. Do the contents of this document closely interact with technologies in
other IETF working groups or external organizations

_Would it therefore benefit from their review? Have those reviews occurred?
If yes, describe which reviews took place._

The document is foundational to certain use cases of SCITT, and I considered
that it might also be useful to RATS. I canvassed both WGs for feedback.

No particular feedback was given by RATS, but the SCITT WG expressed very
positive views.

### 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 document contains a request for 3 COSE Header Parameters.

### 7. If the document contains a YANG module, has the final version of the
module been checked with any of the recommended validation tools for syntax and
formatting validation?

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

I have taken the CDDL from the document (after the small change from v5 to v6)
and successfully validated and generated examples using Hannes Kimara's CDDLC
golang tooling.

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

The shepherd believes that the document is needed, clearly written, complete
and correctly designed. Subject to clarification of the CDDL issues it is
ready to be handed off to the responsible Area Director.

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

The document has been presented and discussed at multiple IETF meetings
and had protracted discussions around hash algorithm selection and
operator ordering. I believe these have all been settled.

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

The intended type is Proposed Standard, because the document describes a data
format for the purpose of interoperability, and uses BCP14 language.
Implementations have moved past the experimental stage. The Datatracker does
reflect the correct RFC status.

### 12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in BCP 79?

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

I have obtained confirmation by email from all authors that they have fulfilled
their IPR disclosure obligations, and also asked the WG list for more general
input. To the best of my knowledge, no disclosure is necessary for this
document.

### 13. Has each author, editor, and contributor shown their willingness to be
listed as such?

Yes.

### 14. Document any remaining I-D nits in this document.

_Simply running the idnits tool is not enough; please review the
"Content Guidelines" on authors.ietf.org. (Also note that the current
idnits tool generates some incorrect warnings; a rewrite is underway.)_

`idnits` reports:
`Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).`

Both warnings appear to be erroneous.

One comment refers to an out-of-date reference which seems harmless.

From a content guidelines perspective the document is mostly good. It is
correctly named, structured, and contains the required content. I note one
deviation from the recommendations of the Content Guidelines, in that the
author contact emails are all work emails, which are not stable over time.
Indeed, for 2 of the 3 authors those addresses were correct at the time of
writing but no longer are.

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

All normative references have been freely available for a long time.

### 17. Are there any normative downward references that are not already listed
in the DOWNREF registry?

There are no normative downward references in this document.

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

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

The publication of this document will not change the status of any existing
RFCs.

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

The document clearly identifies its ask to IANA for new COSE Header Params.
The request is necessary and minimal, and does not establish a new registry.

### 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._

There are no new registries.

Back