As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is requested to be a Proposed Standard.  The header of the
document correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The OAuth authentication and Authorization for Constrained Devices
  provides a message format and framework for moving keys and tokens
  between authority servers, clients, and resource servers.
  This document provides a set of security services so that the
  communication and authorizations can be performed.

Working Group Summary

  Once the CoRE document dealing with OSCORE there was
  only one issue of significance.  That issue was how to deal
  with re-use of tokens in order to make sure that the same
  transport key was not going to be regenerated.  This has
  been addressed.

Document Quality

  The document has been fairly extensively vetted.  There are
  at least two implementations of a version of the document
  prior to the WGLC being done.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have read and implemented the protocol in the document.  I have done a full
read through the document prior to releasing it as well as double checking
my implementation against the current document.

(4) I have no concerns with the review of this document.  It is expected
that an updated interop test will be run at the Prague Hackathon.

(5) There are no portions of this document that need extra review.

(6) Given the current state of the OSCORE document, some attention may need
to be focused on the method used to add randomness to the key derivation process.
I believe that what is done is sufficient, but others may want to look at it.

(7)  All authors have confirmed that all IPR disclosures have been made.
Ludwig 2/25/19
Francesca 1/31/19
Goeran 2/25/19
Martin 2/16/19

(8) No IPR disclosures have been filed on this document.

(9) This document represents a strong consensus of a small group of people.
Most of the reviews came from me and the authors.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found in the document.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I checked that all items that were setup as being defined in the text
also occurred in the registration sections.  Went through and verified that
the template for registering new OSCORE Security Context Parameters made sense.

(18) This document creates one new registry:

OSCORE Security Context Parameters Registry - This registry is setup to
require expert review.  This registry is similar but not identical in usage
to the currently existing COSE_Key registry.  As such a combination of
current DEs for that registry and authors for the OSCORE document
(draft-ietf-core-object-security) would be recommended to act as the DEs
for ths registry.

(19) There are no external reviews or automated checks needed.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is requested to be a Proposed Standard.  The header of the
document correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The OAuth authentication and Authorization for Constrained Devices
  provides a message format and framework for moving keys and tokens
  between authority servers, clients, and resource servers.
  This document provides a set of security services so that the
  communication and autthorizations can be performed.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  The document has been fairly extensively vetted.  There are
  at least two implementations of a version of the document
  prior to the WGLC being done.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have read and implemented the protocol in the document.  I have done a full
read through the document prior to releasing it as well as double checking
my implementation againist the current document.

(4) I have no concerns with the review of this document.  It is expected
that an updated interop test will be run at the Prague Hackathon.

(5) There are no portions of this document that need extra review.

(6) Given the current state of the OSCORE document, some attention may need
to be focused on the method used to add randomness to the key derivation process.
I believe that what is done is sufficent, but others may want to look at it.

(7)  All authors have confirmed that all IPR disclosures have been made.
Ludwig 2/25/19
Francesca 1/31/19
Goeran 2/25/19
Martin 2/16/19

(8) No IPR disclosures have been filed on this document.

(9) This document represents a strong consensus of a small group of people.
Most of the reviews came from me and the authors.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found in the document.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I checked that all items that were setup as being defined in the text
also occured in the registration sections.  Went through and verified that
the template for registering new OSCORE Security Context Parameters made sense.

(18) This document creates one new registry:

OSCORE Security Context Parameters Registry - This registry is setup to
require expert review.  This registry is similar but not identical in usage
to the currently existing COSE_Key registry.  As such a combination of
current DEs for that registry and authors for the OSCORE document
(draft-ietf-core-object-security) would be recommended to act as the DEs
for ths registry.

(19) There are no external reviews or automated checks needed.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is requested to be a Proposed Standard.  The header of the
document correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The OAuth authentication and Authorization for Constrained Devices
  provides a message format and framework for moving keys and tokens
  between authority servers, clients, and resource servers.
  This document provides a set of security services so that the
  communication and autthorizations can be performed.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  The document has been fairly extensively vetted.  There are
  at least two implementations of a version of the document
  prior to the WGLC being done.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have read and implemented the protocol in the document.  I have done a full
read through the document prior to releasing it as well as double checking
my implementation againist the current document.

(4) I have no concerns with the review of this document.  It is expected
that an updated interop test will be run at the Prague Hackathon.

(5) There are no portions of this document that need extra review.

(6) Given the current state of the OSCORE document, some attention may need
to be focused on the method used to add randomness to the key derivation process.
I believe that what is done is sufficent, but others may want to look at it.

(7)  All authors have confirmed that all IPR disclosures have been made.
Ludwig 2/25/19
Francesca 1/31/19
Goeran 2/25/19
Martin 2/16/19

(8) No IPR disclosures have been filed on this document.

(9) This document represents a strong consensus of a small group of people.
Most of the reviews came from me and the authors.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found in the document.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I checked that all items that were setup as being defined in the text
also occured in the registration sections.  Went through and verified that
the template for registering new OSCORE Security Context Parameters made sense.

(18) This document creates one new registry:

OSCORE Security Context Parameters Registry - This registry is setup to
require expert review.  This registry is similar but not identical in usage
to the currently existing COSE_Key registry.  As such a combination of
current DEs for that registry and authors for the OSCORE document
(draft-ietf-core-object-security) would be recommended to act as the DEs
for ths registry.

(19) There are no external reviews or automated checks needed.