Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-oscore-edhoc-11

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-core-oscore-edhoc and RFC 9668, changed IESG state to RFC Published)

[Ballot comment]
Thanks for the work and thanks to Emmanuel Baccelli for the IoT directorate review at:
https://datatracker.ietf.org/doc/review-ietf-core-oscore-edhoc-10-iotdir-telechat-baccelli-2024-03-27/

Strong suggestion to the authors: please reply to Emmanuel's review.

[Ballot comment]
Thanks for the discussion. On that basis (and also IANA feedback) I'm clearing my DISCUSS. See also my reply to the DISCUSS email thread.

[Ballot comment]
Thank you to Joel Halpern for the GENART review.

** References.  [RFC8392], [RFC5280] and [I-D.ietf-cose-cbor-encoded-cert] are being used to references to create registry in Section 8.3.  They should be normative references.

[Ballot comment]
I support John Scudder's DISCUSS position -- the Specification Required with Standards Action and a Designated Expert" isn't on the menu[0], and it's unclear what it means.

Also, much thanks to Jürgen Schönwälder for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-core-oscore-edhoc-10-opsdir-telechat-schoenwaelder-2024-03-03/), and to the authors for addressing it.

W
[0]: While reading John DISCUSS, I ended up with a hankering for ice-cream with whipped-cream, chocolate sauce, sprinkles and a cherry...

[Ballot discuss]
Thanks for this document, which in general I found clear. I have one concern, which I hope will not be too annoying.

Regarding the IANA section, I see that the "OSCORE Security Context Parameters" registry has a range whose policy is given as "Standards Action With Expert Review" so one might argue this ship has sailed... but the more I dig into that registry and RFC 9203, the less I understand, so I think it's worth clarifying this now instead of propagating confusion. (To continue the "ship has sailed" metaphor, I am concerned the ship is lost at sea and we just haven't realized it yet.)

"Standards Action With Expert Review" isn't one of the defined RFC 8126 policies, which is OK of course, but if not using one of the defined policies, I think it's important to be explicit and clear about exactly what the semantics of your non-standard policy are. Or, in the words of RFC 8216 §4,

                                                  Newly minted policies,
  including ones that combine the elements of procedures associated
  with these terms in novel ways, may be used if none of these policies
  are suitable; it will help the review process if an explanation is
  included as to why that is the case.

In your §8.4 you have,

  Specifications are required for the "Standards Action With Expert
  Review" range of point assignment.

You didn't have to invent a nonstandard policy for that -- Standards Action already has a strong requirement for specification.

That's the only point in your document I see that's specific to "Standards Action With Expert Review". Am I supposed to assume that this policy inludes all the restrictions and requirements of the RFC 8126 style "Standards Action", adding the designated expert as an additional gatekeeper, in addition to the SA gatekeepers, those being (at least) the WG chairs, WGLC, IETF LC, and IESG review? Does RFC 7120 style Early Allocation apply? A plain reading of RFC 7120 implies it does not:

              The early allocation mechanisms are applied only to
  spaces whose allocation policy is "Specification Required" (where an
  RFC is used as the stable reference), "RFC Required", "IETF Review",
  or "Standards Action".

That is to say, "Standards Action with Expert Review" is on its face, not the same as "Standards Action". On the other hand, if RFC 7120 should somehow apply, what is the role of the designated expert? Note that RFC 7120 doesn't say anything about designated experts, the parties involved are the authors, WG chairs, and AD(s).

It seems to me that if you insist on using this variant policy, instead of just "Standards Action" with no sprinkles or whipped cream, then you should explicitly say what aspects of "Standards Action" you expect it to inherit. Or, you could go with just "Designated Expert" with no "Standards Action" chocolate sauce, and include in the instructions to the expert for that range, that "values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream" plus maybe something about following an RFC 7120-like procedure for early allocation, if desired.

[Ballot comment]
idnits spits up a downref (ref. 'I-D.ietf-core-target-attr').
Not sure if in the reference section an IANA registry reference is better informational then normative reference.

[Ballot comment]
Thanks to Shuping Peng for the ART-ART review.
Thanks to Carsten Bormann for the shepherd writeup.

In Section 2

"""
The Content-Format of the request can be set to application/cid-edhoc+cbor-seq.
"""

SHOULD ? or MUST ?.. same question for the use of "can" in the following sections.

In Section 3.2.1

"""
The application/cid-edhoc+cbor-seq media type does not apply to this message, whose media type is unnamed.
"""

I think this is intending to say "application/cid-edhoc+cbor-seq" SHOULD NOT be used for this message... but this could be clearer if a media type was named.

[Ballot comment]
Thanks to Juergen for his OPSDIR review.

I am no security expert, and therefore relying on the SECDIR review from Wes to ballot my position.

Just one nit. If there are no IANA considerations, it should probably just state that, rather than to go onto giving RFC Editor instructions in the section. But I imagine IANA will take one look at the section, and just ignore it, while the RFC Editors wonder why the instruction for them were left in the IANA Considerations section.

[Ballot comment]
Thanks to Juergen for his OPSDIR review.

Just one nit. If there are no IANA considerations, it should probably just state that, rather than to go onto giving RFC Editor instructions in the section. But I imagine IANA will take one look at the section, and just ignore it, while the RFC Editors wonder why the instruction for them were left in the IANA Considerations section.

[Ballot comment]
Thanks to Juergen for his OPSDIR review.

Just one nit. If there are no IANA considerations, it should probably just state that, rather than to go onto giving RFC Editor instructions in the section. But I imagine IANA will take one look at the section, and just ignore it.

[Ballot comment]
Thanks to Shuping Peng for the ART-ART review.
Thanks to Carsten Bormann for the shepherd writeup.

In Section 2

"""
The Content-Format of the request can be set to application/cid-edhoc+cbor-seq.
"""

SHOULD ? or MUST ?.. same question for the use of "can" in the following sections.

In Section 3.2.1

"""
The application/cid-edhoc+cbor-seq media type does not apply to this message, whose media type is unnamed.
"""

I think this is intending to say "application/cid-edhoc+cbor-seq" SHOULD NOT be used for this message... but this could be clearer if a media type was named.

In Section 8.4

Please consider explicit guidance regarding if IDs meet the specification required range criteria.

[Ballot comment]
Thanks to Shuping Peng for the ART-ART review.

In Section 2

"""
The Content-Format of the request can be set to application/cid-edhoc+cbor-seq.
"""

SHOULD ? or MUST ?.. same question for the use of "can" in the following sections.

In Section 3.2.1

"""
The application/cid-edhoc+cbor-seq media type does not apply to this message, whose media type is unnamed.
"""

I think this is intending to say "application/cid-edhoc+cbor-seq" SHOULD NOT be used for this message... but this could be clearer if a media type was named.

In Section 8.4

Please consider explicit guidance regarding if IDs meet the specification required range criteria.

[Ballot comment]
In Section 2

"""
The Content-Format of the request can be set to application/cid-edhoc+cbor-seq.
"""

SHOULD ? or MUST ?.. same question for the use of "can" in the following sections.

In Section 3.2.1

"""
The application/cid-edhoc+cbor-seq media type does not apply to this message, whose media type is unnamed.
"""

I think this is intending to say "application/cid-edhoc+cbor-seq" SHOULD NOT be used for this message... but this could be clearer if a media type was named.

In Section 8.4

Please consider explicit guidance regarding if IDs meet the specification required range criteria.

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

IANA has completed its review of draft-ietf-core-oscore-edhoc-09. If any part of this review is inaccurate, please let us know.

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

First, in the CoAP Option Numbers registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

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

the existing temporary registration for:

Number: 21
Name: EDHOC

will be made permanent and have its reference changed to [ RFC-to-be ].

Second, in the Target Attributes registry also in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

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

eight new registrations are to be made as follows:

Attribute Name: ed-i
Brief Description: Hint: support for the EDHOC Initiator role
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-r
Brief Description: Hint: support for the EDHOC Responder role
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-method
Brief Description: A supported authentication method for EDHOC
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-csuite
Brief Description: A supported cipher suite for EDHOC
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-cred-t
Brief Description: A supported type of authentication credential for EDHOC
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-idcred-t
Brief Description: A supported type of authentication credential identifier for EDHOC
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-ead
Brief Description: A supported External Authorization Data (EAD) item for EDHOC
Change Controller: IETF
Reference: [ RFC-to-be ]

Attribute Name: ed-comb-req
Brief Description: Hint: support for the EDHOC+OSCORE request
Change Controller: IETF
Reference: [ RFC-to-be ]

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

Third, a new registry is to be created called the EDHOC Authentication Credential Types registry. The new registry is to be located in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group located at:

https://www.iana.org/assignments/edhoc/

The values in the registry can be an unsigned integer or a negative integer.

The registration rules for the new registry are as follows:

Integer values from -24 to 23 are designated as "Standards Action With Expert Review".
Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required".
Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".

There are four initial registrations in the new registry:

Value Description Reference
-----+-----------+-----------------
0 CBOR Web Token (CWT) containing a COSE_Key in a [RFC8392]
'cnf' claim and possibly other claims. CWT is
defined in RFC 8392.
1 CWT Claims Set (CCS) containing a COSE_Key in a [RFC8392]
'cnf' claim and possibly other claims. CCS is
defined in RFC 8392.
2 X.509 certificate [RFC5280]
3 C509 certificate [I-D.ietf-cose-cbor-encoded-cert]

We understand 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 Sr. Specialist

The following Last Call announcement was sent out (ends 2023-11-13):

From: The IESG
To: IETF-Announce
CC: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-oscore-edhoc@ietf.org, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using EDHOC with CoAP and OSCORE) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Using EDHOC with CoAP and
OSCORE'
  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-11-13. 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


  The lightweight authenticated key exchange protocol EDHOC can be run
  over CoAP and used by two peers to establish an OSCORE Security
  Context.  This document details this use of the EDHOC protocol, by
  specifying a number of additional and optional mechanisms.  These
  especially include an optimization approach for combining the
  execution of EDHOC with the first OSCORE transaction.  This
  combination reduces the number of round trips required to set up an
  OSCORE Security Context and to complete an OSCORE transaction using
  that Security Context.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-oscore-edhoc/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-core-target-attr: CoRE Target Attributes Registry (None - Internet Engineering Task Force (IETF))

# 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 is broad agreement that this document should go forward, and a core group of people who have satisfied themselves about the technical details.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
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][3] recommends) or elsewhere
  (where)?
 
The number of implementations is limited, as the underlying EDHOC protocol (LAKE WG) has only just reached the IESG and needs to be implemented first.
Since EDHOC has recently made an on-wire change that also required to make a change in the implementation, there is a certain reluctance to commit to implementations before the document is approved.
There is a common sentiment that implementing this protocol will be a matter of course in the emerging CoAP/EDHOC implementations.
An early example for this is the following implementation that includes the OSCORE-EDHOC protocol:

* https://github.com/rikard-sics/californium/tree/edhoc

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

OSCORE-EDHOC is based on and closely interacts with EDHOC, a protocol of the LAKE WG.  There is a good overlap between the LAKE WG members and CoRE, so no additional reviews were deemed necessary.

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 makes registrations in the [Target Attributes registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group (IANA.core-parameters)][r1].  The shepherd believes the registration requirements are fulfilled, but no DE has been appointed for that registry yet as the [document][r2] establishing the registry is still in processing.

[r1]: https://www.ietf.org/archive/id/draft-ietf-core-target-attr-05.html#name-structure-of-entries
[r2]: https://datatracker.ietf.org/doc/draft-ietf-core-target-attr/

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.
 
Besides the author's checks, the shepherd has checked the examples (no other FDT in the document).

## 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 on all counts.

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?

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?
   
This is intended as a Proposed Standard document, as it documents a protocol intended as a standard for interoperability.

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.
   
Confirmations by the authors (copied to core@ietf.org):
* [x] Francesca Palombini
* [x] Marco Tiloca
* [x] Rikard Höglund
* [x] Stefan Hristozov
* [x] Göran Selander

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.
   
Yes (via 12 and recent activity in WG meetings and on the list).

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.)
   
Downref to draft-ietf-core-target-attr, which will likely be approved before this document.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
All documents listed as normative are appropriately so.
There are three documents listed as informative that are only used as references in registrations in the [EDHOC Authentication Credential Types Registry][r3] created in this document; this can be debated either way (clearly they don't require "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work", but they aren't really "for information" only either).  (We often have this uncertainty where a document creates an extension point and exercises that right away [RFC9170]...)

[r3]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-edhoc-authentication-creden

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
(See 14 above.)

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?
   
(See 14 above.)

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

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]).
   
Yes on all counts.
See also 21 below.

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.
   
[Section 8.4][r4] provides extensive instructions to the DE of the new registry.

The DEs for this registry should probably be the same as for other registries in the registry group, e.g., EDHOC authors (which overlap with the authors of OSCORE-EDHOC).

[r4]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-expert-review-instructions

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# 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 is broad agreement that this document should go forward, and a core group of people who have satisfied themselves about the technical details.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
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][3] recommends) or elsewhere
  (where)?
 
The number of implementations is limited, as the underlying EDHOC protocol (LAKE WG) has only just reached the IESG and needs to be implemented first.
Since EDHOC has recently made an on-wire change that also required to make a change in the implementation, there is a certain reluctance to commit to implementations before the document is approved.
There is a common sentiment that implementing this protocol will be a matter of course in the emerging CoAP/EDHOC implementations.
An early example for this is the following implementation that includes the OSCORE-EDHOC protocol:

* https://github.com/rikard-sics/californium/tree/edhoc

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

OSCORE-EDHOC is based on and closely interacts with EDHOC, a protocol of the LAKE WG.  There is a good overlap between the LAKE WG members and CoRE, so no additional reviews were deemed necessary.

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 makes registrations in the [Target Attributes registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group (IANA.core-parameters)][r1].  The shepherd believes the registration requirements are fulfilled, but no DE has been appointed for that registry yet as the [document][r2] establishing the registry is still in processing.

[r1]: https://www.ietf.org/archive/id/draft-ietf-core-target-attr-05.html#name-structure-of-entries
[r2]: https://datatracker.ietf.org/doc/draft-ietf-core-target-attr/

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.
 
Besides the author's checks, the shepherd has checked the examples (no other FDT in the document).

## 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 on all counts.

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?

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?
   
This is intended as a Proposed Standard document, as it documents a protocol intended as a standard for interoperability.

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.
   
Ongoing:
* [x] Francesca Palombini
* [x] Marco Tiloca
* [x] Rikard Höglund
* [x] Stefan Hristozov
* [x] Göran Selander

We regulary discuss IPR issues in the core WG.
At this time, Stefan appears to be on vacation until 2023-08-18, so we'll update this writeup once we have his formal response as well.  Rikard is also on vacation, and Francesca is on leave but occasionally reading her mail.
So this will likely be filled in the next couple of weeks, during which other processing can happen in parallel.

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.
   
Yes (via 12 and recent activity in WG meetings and on the list).

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.)
   
Downref to draft-ietf-core-target-attr, which will likely be approved before this document.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
All documents listed as normative are appropriately so.
There are three documents listed as informative that are only used as references in registrations in the [EDHOC Authentication Credential Types Registry][r3] created in this document; this can be debated either way (clearly they don't require "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work", but they aren't really "for information" only either).  (We often have this uncertainty where a document creates an extension point and exercises that right away [RFC9170]...)

[r3]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-edhoc-authentication-creden

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
(See 14 above.)

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?
   
(See 14 above.)

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

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]).
   
Yes on all counts.
See also 21 below.

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.
   
[Section 8.4][r4] provides extensive instructions to the DE of the new registry.

The DEs for this registry should probably be the same as for other registries in the registry group, e.g., EDHOC authors (which overlap with the authors of OSCORE-EDHOC).

[r4]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-expert-review-instructions

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# 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 is broad agreement that this document should go forward, and a core group of people who have satisfied themselves about the technical details.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
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][3] recommends) or elsewhere
  (where)?
 
The number of implementations is limited, as the underlying EDHOC protocol (LAKE WG) has only just reached the IESG and needs to be implemented first.
Since EDHOC has recently made an on-wire change that also required to make a change in the implementation, there is a certain reluctance to commit to implementations before the document is approved.
There is a common sentiment that implementing this protocol will be a matter of course in the emerging CoAP/EDHOC implementations.
An early example for this is the following implementation that includes the OSCORE-EDHOC protocol:

* https://github.com/rikard-sics/californium/tree/edhoc

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

OSCORE-EDHOC is based on and closely interacts with EDHOC, a protocol of the LAKE WG.  There is a good overlap between the LAKE WG members and CoRE, so no additional reviews were deemed necessary.

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 makes registrations in the [Target Attributes registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group (IANA.core-parameters)][r1].  The shepherd believes the registration requirements are fulfilled, but no DE has been appointed for that registry yet as the [document][r2] establishing the registry is still in processing.

[r1]: https://www.ietf.org/archive/id/draft-ietf-core-target-attr-05.html#name-structure-of-entries
[r2]: https://datatracker.ietf.org/doc/draft-ietf-core-target-attr/

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.
 
Besides the author's checks, the shepherd has checked the examples (no other FDT in the document).

## 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 on all counts.

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?

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?
   
This is intended as a Proposed Standard document, as it documents a protocol intended as a standard for interoperability.

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.
   
Ongoing:
* [x] Francesca Palombini
* [x] Marco Tiloca
* [ ] Rikard Höglund
* [ ] Stefan Hristozov
* [x] Göran Selander

We regulary discuss IPR issues in the core WG.
At this time, Stefan appears to be on vacation until 2023-08-18, so we'll update this writeup once we have his formal response as well.  Rikard is also on vacation, and Francesca is on leave but occasionally reading her mail.
So this will likely be filled in the next couple of weeks, during which other processing can happen in parallel.

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.
   
Yes (via 12 and recent activity in WG meetings and on the list).

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.)
   
Downref to draft-ietf-core-target-attr, which will likely be approved before this document.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
All documents listed as normative are appropriately so.
There are three documents listed as informative that are only used as references in registrations in the [EDHOC Authentication Credential Types Registry][r3] created in this document; this can be debated either way (clearly they don't require "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work", but they aren't really "for information" only either).  (We often have this uncertainty where a document creates an extension point and exercises that right away [RFC9170]...)

[r3]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-edhoc-authentication-creden

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
(See 14 above.)

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?
   
(See 14 above.)

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

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]).
   
Yes on all counts.
See also 21 below.

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.
   
[Section 8.4][r4] provides extensive instructions to the DE of the new registry.

The DEs for this registry should probably be the same as for other registries in the registry group, e.g., EDHOC authors (which overlap with the authors of OSCORE-EDHOC).

[r4]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-expert-review-instructions

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# 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 is broad agreement that this document should go forward, and a core group of people who have satisfied themselves about the technical details.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
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][3] recommends) or elsewhere
  (where)?
 
The number of implementations is limited, as the underlying EDHOC protocol (LAKE WG) has only just reached the IESG and needs to be implemented first.
Since EDHOC has recently made an on-wire change that also required to make a change in the implementation, there is a certain reluctance to commit to implementations before the document is approved.
There is a common sentiment that implementing this protocol will be a matter of course in the emerging CoAP/EDHOC implementations.
An early example for this is the following implementation that includes the OSCORE-EDHOC protocol:

* https://github.com/rikard-sics/californium/tree/edhoc

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

OSCORE-EDHOC is based on and closely interacts with EDHOC, a protocol of the LAKE WG.  There is a good overlap between the LAKE WG members and CoRE, so no additional reviews were deemed necessary.

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 makes registrations in the [Target Attributes registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group (IANA.core-parameters)][r1].  The shepherd believes the registration requirements are fulfilled, but no DE has been appointed for that registry yet as the [document][r2] establishing the registry is still in processing.

[r1]: https://www.ietf.org/archive/id/draft-ietf-core-target-attr-05.html#name-structure-of-entries
[r2]: https://datatracker.ietf.org/doc/draft-ietf-core-target-attr/

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.
 
Besides the author's checks, the shepherd has checked the examples (no other FDT in the document).

## 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 on all counts.

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?

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?
   
This is intended as a Proposed Standard document, as it documents a protocol intended as a standard for interoperability.

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.
   
Ongoing:
* [ ] Francesca Palombini
* [x] Marco Tiloca
* [ ] Rikard Höglund
* [ ] Stefan Hristozov
* [x] Göran Selander

We regulary discuss IPR issues in the core WG.
At this time, Stefan appears to be on vacation until 2023-08-18, so we'll update this writeup once we have his formal response as well.  Rikard is also on vacation, and Francesca is on leave but occasionally reading her mail.
So this will likely be filled in the next couple of weeks, during which other processing can happen in parallel.

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.
   
Yes (via 12 and recent activity in WG meetings and on the list).

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.)
   
Downref to draft-ietf-core-target-attr, which will likely be approved before this document.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
All documents listed as normative are appropriately so.
There are three documents listed as informative that are only used as references in registrations in the [EDHOC Authentication Credential Types Registry][r3] created in this document; this can be debated either way (clearly they don't require "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work", but they aren't really "for information" only either).  (We often have this uncertainty where a document creates an extension point and exercises that right away [RFC9170]...)

[r3]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-edhoc-authentication-creden

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
(See 14 above.)

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?
   
(See 14 above.)

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

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]).
   
Yes on all counts.
See also 21 below.

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.
   
[Section 8.4][r4] provides extensive instructions to the DE of the new registry.

The DEs for this registry should probably be the same as for other registries in the registry group, e.g., EDHOC authors (which overlap with the authors of OSCORE-EDHOC).

[r4]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-expert-review-instructions

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# 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 is broad agreement that this document should go forward, and a core group of people who have satisfied themselves about the technical details.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
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][3] recommends) or elsewhere
  (where)?
 
The number of implementations is limited, as the underlying EDHOC protocol (LAKE WG) has only just reached the IESG and needs to be implemented first.
Since EDHOC has recently made an on-wire change that also required to make a change in the implementation, there is a certain reluctance to commit to implementations before the document is approved.
There is a common sentiment that implementing this protocol will be a matter of course in the emerging CoAP/EDHOC implementations.
An early example for this is the following implementation that includes the OSCORE-EDHOC protocol:

* https://github.com/rikard-sics/californium/tree/edhoc

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

OSCORE-EDHOC is based on and closely interacts with EDHOC, a protocol of the LAKE WG.  There is a good overlap between the LAKE WG members and CoRE, so no additional reviews were deemed necessary.

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 makes registrations in the [Target Attributes registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group (IANA.core-parameters)][r1].  The shepherd believes the registration requirements are fulfilled, but no DE has been appointed for that registry yet as the [document][r2] establishing the registry is still in processing.

[r1]: https://www.ietf.org/archive/id/draft-ietf-core-target-attr-05.html#name-structure-of-entries
[r2]: https://datatracker.ietf.org/doc/draft-ietf-core-target-attr/

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.
 
Besides the author's checks, the shepherd has checked the examples (no other FDT in the document).

## 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 on all counts.

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?

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?
   
This is intended as a Proposed Standard document, as it documents a protocol intended as a standard for interoperability.

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.
   
Ongoing:
* [ ] Francesca Palombini
* [x] Marco Tiloca
* [ ] Rikard Höglund
* [ ] Stefan Hristozov
* [x] Göran Selander

We regulary discuss IPR issues in the core WG.
At this time, Stefan appears to be on vacation until 2023-08-18, so we'll update this writeup once we have his formal response as well.  Rikard is also on vacation, and Francesca is on leave but occasionally reading her mail.
So this will likely be filled in the next couple of weeks, during which other processing can happen in parallel.

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.
   
Yes (via 12 and recent activity in WG meetings and on the list).

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.)
   
Downref to draft-ietf-core-target-attr, which will likely be approved before this document.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
All documents listed as normative are appropriately so.
There are three documents listed as informative that are only used as references in registrations in the [EDHOC Authentication Credential Types Registry][r3] created in this document; this can be debated either way (clearly they don't require "must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work", but they aren't really "for information" only either).  (We often have this uncertainty where a document creates an extension point and exercises that right away [RFC9170]...)

[r3]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-edhoc-authentication-creden

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
(See 14 above.)

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?
   
(See 14 above.)

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

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]).
   
Yes on all counts.
See also 21 below.

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.
   
[Section 8.4][r4] provides extensive instructions to the DE of the new registry.

The DEs for this registry should probably be the same as for other registries in the registry group, e.g., EDHOC authors (which overlap with the authors of OSCORE-EDHOC).

[r4]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-08.html#name-expert-review-instructions

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/