Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2024-05-02
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-05-02
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-05-02
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-04-26
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-04-25
11 (System) IANA Action state changed to In Progress
2024-04-25
11 (System) RFC Editor state changed to EDIT
2024-04-25
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-04-25
11 (System) Announcement was received by RFC Editor
2024-04-25
11 (System) Removed all action holders (IESG state changed)
2024-04-25
11 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-04-25
11 Cindy Morgan IESG has approved the document
2024-04-25
11 Cindy Morgan Closed "Approve" ballot
2024-04-25
11 Cindy Morgan Ballot approval text was generated
2024-04-25
11 Paul Wouters IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2024-04-09
11 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-11.txt
2024-04-09
11 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2024-04-09
11 Marco Tiloca Uploaded new revision
2024-04-04
10 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2024-04-04
10 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-04-04
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-04-03
10 Éric Vyncke
[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 …
[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.
2024-04-03
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-04-03
10 John Scudder
[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 …
[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.
2024-04-03
10 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2024-04-02
10 Roman Danyliw
[Ballot comment]
Thank you to Joel Halpern for the GENART review.

** References.  [RFC8392], [RFC5280] and [I-D.ietf-cose-cbor-encoded-cert] are being …
[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.
2024-04-02
10 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-04-02
10 Warren Kumari
[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 …
[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...
2024-04-02
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2024-04-02
10 John Scudder
[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 …
[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.
2024-04-02
10 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2024-03-30
10 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Wes Hardaker. Submission of review completed at an earlier date.
2024-03-30
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-03-29
10 Gunter Van de Velde
[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 …
[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.
2024-03-29
10 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-03-28
10 Orie Steele
[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 …
[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.
2024-03-28
10 Orie Steele Ballot comment text updated for Orie Steele
2024-03-27
10 Emmanuel Baccelli Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Emmanuel Baccelli. Sent review to list.
2024-03-26
10 Mahesh Jethanandani
[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 …
[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.
2024-03-26
10 Mahesh Jethanandani Ballot comment text updated for Mahesh Jethanandani
2024-03-26
10 Mahesh Jethanandani
[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 …
[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.
2024-03-26
10 Mahesh Jethanandani Ballot comment text updated for Mahesh Jethanandani
2024-03-26
10 Mahesh Jethanandani
[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 …
[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.
2024-03-26
10 Mahesh Jethanandani [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani
2024-03-26
10 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-03-25
10 Orie Steele
[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 …
[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.
2024-03-25
10 Orie Steele Ballot comment text updated for Orie Steele
2024-03-25
10 Orie Steele
[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.
""" …
[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.
2024-03-25
10 Orie Steele Ballot comment text updated for Orie Steele
2024-03-25
10 Orie Steele
[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 …
[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.
2024-03-25
10 Orie Steele [Ballot Position Update] New position, Yes, has been recorded for Orie Steele
2024-03-08
10 Francesca Palombini [Ballot comment]
I am an author of this one.
2024-03-08
10 Francesca Palombini [Ballot Position Update] New position, Recuse, has been recorded for Francesca Palombini
2024-03-06
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Emmanuel Baccelli
2024-03-06
10 Éric Vyncke Requested Telechat review by IOTDIR
2024-03-04
10 Shuping Peng Request for Telechat review by ARTART Completed: Ready. Reviewer: Shuping Peng. Sent review to list.
2024-03-03
10 Barry Leiba Request for Telechat review by ARTART is assigned to Shuping Peng
2024-03-03
10 Jürgen Schönwälder Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Jürgen Schönwälder. Sent review to list.
2024-02-29
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Wes Hardaker
2024-02-27
10 Carlos Pignataro Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder
2024-02-26
10 Cindy Morgan Placed on agenda for telechat - 2024-04-04
2024-02-25
10 Paul Wouters Ballot has been issued
2024-02-25
10 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2024-02-25
10 Paul Wouters Created "Approve" ballot
2024-02-25
10 Paul Wouters IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-02-25
10 Paul Wouters Ballot writeup was changed
2023-12-19
10 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2023-12-19
10 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-12-18
10 David Dong IANA Experts State changed to Reviews assigned from Need IANA Expert(s)
2023-11-29
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2023-11-29
10 Göran Selander New version available: draft-ietf-core-oscore-edhoc-10.txt
2023-11-29
10 Göran Selander New version accepted (logged-in submitter: Göran Selander)
2023-11-29
10 Göran Selander Uploaded new revision
2023-11-16
09 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Wes Hardaker. Submission of review completed at an earlier date.
2023-11-15
10 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Wes Hardaker.
2023-11-15
09 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Wes Hardaker.
2023-11-14
09 Shuping Peng Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Shuping Peng. Sent review to list.
2023-11-13
09 Jürgen Schönwälder Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Jürgen Schönwälder. Sent review to list.
2023-11-13
09 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-11-12
09 Joel Halpern Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list.
2023-11-09
09 David Dong IANA Experts State changed to Need IANA Expert(s)
2023-11-09
09 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2023-11-09
09 David Dong
(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 …
(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
2023-10-27
09 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2023-10-26
09 Meral Shirazipour Assignment of request for Last Call review by GENART to Meral Shirazipour was rejected
2023-10-26
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2023-10-26
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Wes Hardaker
2023-10-25
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2023-10-24
09 Barry Leiba Request for Last Call review by ARTART is assigned to Shuping Peng
2023-10-23
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-10-23
09 Cindy Morgan
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 …
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))



2023-10-23
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-10-23
09 Cindy Morgan Last call announcement was changed
2023-10-22
09 Paul Wouters Last call was requested
2023-10-22
09 Paul Wouters Ballot approval text was generated
2023-10-22
09 Paul Wouters Ballot writeup was generated
2023-10-22
09 Paul Wouters IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-10-22
09 Paul Wouters Last call announcement was generated
2023-10-13
09 (System) Changed action holders to Paul Wouters (IESG state changed)
2023-10-13
09 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-10-13
09 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-09.txt
2023-10-13
09 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2023-10-13
09 Marco Tiloca Uploaded new revision
2023-10-06
08 (System) Changed action holders to Paul Wouters, Francesca Palombini, Marco Tiloca, Rikard Höglund, Stefan Hristozov, Göran Selander (IESG state changed)
2023-10-06
08 Paul Wouters IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2023-08-30
08 Francesca Palombini Shepherding AD changed to Paul Wouters
2023-08-16
08 Carsten Bormann
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*
[...]

## Document History

1. Does the working group (WG) consensus …
# 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/
2023-08-16
08 Carsten Bormann
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*
[...]

## Document History

1. Does the working group (WG) consensus …
# 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/
2023-08-09
08 Carsten Bormann
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*
[...]

## Document History

1. Does the working group (WG) consensus …
# 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/

2023-08-09
08 Carsten Bormann
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*
[...]

## Document History

1. Does the working group (WG) consensus …
# 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/

2023-08-09
08 Carsten Bormann Responsible AD changed to Francesca Palombini
2023-08-09
08 Carsten Bormann IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-08-09
08 Carsten Bormann IESG state changed to Publication Requested from I-D Exists
2023-08-09
08 Carsten Bormann Document is now in IESG state Publication Requested
2023-08-09
08 Carsten Bormann
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*
[...]

## Document History

1. Does the working group (WG) consensus …
# 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/

2023-08-08
08 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-08.txt
2023-08-08
08 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2023-08-08
08 Marco Tiloca Uploaded new revision
2023-07-11
07 Carsten Bormann Tag Revised I-D Needed - Issue raised by WGLC cleared.
2023-07-11
07 Carsten Bormann IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2023-03-21
07 Marco Tiloca Added to session: IETF-116: core  Tue-0400
2023-03-13
07 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-07.txt
2023-03-13
07 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2023-03-13
07 Marco Tiloca Uploaded new revision
2023-03-02
06 Carsten Bormann Changed consensus to Yes from Unknown
2023-03-02
06 Carsten Bormann Intended Status changed to Proposed Standard from None
2023-03-02
06 Carsten Bormann Tag Revised I-D Needed - Issue raised by WGLC set.
2023-03-02
06 Carsten Bormann IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-02-14
06 Carsten Bormann WGLC with CC to LAKE
2023-02-14
06 Carsten Bormann Notification list changed to cabo@tzi.org because the document shepherd was set
2023-02-14
06 Carsten Bormann Document shepherd changed to Carsten Bormann
2023-02-14
06 Carsten Bormann IETF WG state changed to In WG Last Call from WG Document
2022-11-23
06 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-06.txt
2022-11-23
06 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2022-11-23
06 Marco Tiloca Uploaded new revision
2022-11-01
05 Marco Tiloca Added to session: IETF-115: core  Mon-1300
2022-10-24
05 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-05.txt
2022-10-24
05 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2022-10-24
05 Marco Tiloca Uploaded new revision
2022-07-19
04 Marco Tiloca Added to session: IETF-114: core  Tue-1500
2022-07-11
04 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-04.txt
2022-07-11
04 Marco Tiloca New version accepted (logged-in submitter: Marco Tiloca)
2022-07-11
04 Marco Tiloca Uploaded new revision
2022-04-25
03 Marco Tiloca Added to session: interim-2022-core-05
2022-03-07
03 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-03.txt
2022-03-07
03 (System) New version accepted (logged-in submitter: Marco Tiloca)
2022-03-07
03 Marco Tiloca Uploaded new revision
2021-10-26
02 Marco Tiloca Added to session: interim-2021-core-13
2021-10-25
02 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-02.txt
2021-10-25
02 (System) New version accepted (logged-in submitter: Marco Tiloca)
2021-10-25
02 Marco Tiloca Uploaded new revision
2021-07-27
01 Marco Tiloca Added to session: IETF-111: core  Wed-1200
2021-07-12
01 Göran Selander New version available: draft-ietf-core-oscore-edhoc-01.txt
2021-07-12
01 (System) New version approved
2021-07-12
01 (System) Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , Marco Tiloca , Rikard Hoeglund , Stefan Hristozov
2021-07-12
01 Göran Selander Uploaded new revision
2021-04-13
00 Marco Tiloca Changed document external resources from:

[]

to:

github_repo https://github.com/core-wg/oscore-edhoc (Working Group Repo)
2021-04-01
00 Marco Tiloca This document now replaces draft-palombini-core-oscore-edhoc instead of None
2021-04-01
00 Marco Tiloca New version available: draft-ietf-core-oscore-edhoc-00.txt
2021-04-01
00 (System) WG -00 approved
2021-04-01
00 Marco Tiloca Set submitter to "Marco Tiloca ", replaces to draft-palombini-core-oscore-edhoc and sent approval email to group chairs: core-chairs@ietf.org
2021-04-01
00 Marco Tiloca Uploaded new revision