Putting in ::External Party while I check on the OSCORE profile and think about whether we want to wait for it and move the whole cluster into IESG evaluation together.

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

The IANA Functions Operator has completed its review of draft-ietf-ace-dtls-authorize-12. If any part of this review is inaccurate, please let us know.

IANA understands that the action requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: draft-ietf-ace-oauth-authz-35.

Section 8.8 of that document creates a new registry with the following fields:

Name The name of the profile, to be used as value of the profile attribute.

Description Text giving an overview of the profile and the context it is developed for.

CBOR Value CBOR abbreviation for this profile name.

Different ranges of values use different registration policies [RFC8126].

Integer values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required.
Integer values greater than 65535 are designated as "Expert Review".
Integer values less than -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the profile abbreviation, if one exists.

The current document requests the following registration:

Profile name: coap_dtls

Profile Description: Profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes.

Profile ID: TBD (suggested: 1)

Change Controller: IESG

Reference: [ RFC-to-be ]

Upon approval of draft-ietf-ace-oauth-authz IANA understands that a single, new registration will be made in the ACE Profile registry as follows:

Name: coap_dtls
Description: Profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes.
CBOR Value: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA understands that the authors have suggested a value of 1 for the CBOR Value.

The IANA Functions Operator understands that this is the only action 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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-07-20):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Jim Schaad <ietf@augustcellars.com>, ace-chairs@ietf.org, kaduk@mit.edu, ietf@augustcellars.com, ace@ietf.org, draft-ietf-ace-dtls-authorize@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-ace-dtls-authorize-12.txt> (Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'Datagram Transport Layer Security (DTLS) Profile for Authentication
  and Authorization for Constrained Environments (ACE)'
  <draft-ietf-ace-dtls-authorize-12.txt> 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 2020-07-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a profile of the ACE framework that allows
  constrained servers to delegate client authentication and
  authorization.  The protocol relies on DTLS version 1.2 for
  communication security between entities in a constrained network
  using either raw public keys or pre-shared keys.  A resource-
  constrained server can use this protocol to delegate management of
  authorization information to a trusted host with less severe
  limitations regarding processing power and memory.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3112/

(1) This document is labeled to be a Proposed Standard.  This is
what the the track of the document should be.

(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 ACE WG has created a framework for constrained servers
  to do authentication and authorization using OAuth.
  This document provides the details for how to use DTLS as
  the security for protecting and authentication the messages
  defined in the framework as well as the final client to
  resource server messages.

Working Group Summary

  The document did not raise any issues during development.
  Most of the issues were focused on the framework document.

Document Quality

  At least two implementations of prior versions of this document
  exist.  The process of doing these implementations and making
  sure that they were interoperable was influential in some of
  the content in the document.

Personnel

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

(3) In addition to validating my implementation of the specification
I checked the IANA considerations to make sure that they were complete,
checked all of the nits and did a read through to make sure all WGLC comments
were addressed.

(4) All of my concerns have been addressed during the WGLC process.

(5) Looking at the mechanism that is defined for resource server
key generation should be checked against the security considerations
and any problems.

(6) I have no specific concerns with this document.

(7) All authors have confirmed that all appropriate IPR disclosures have been made

** Stefanie ** YES * 5/2/19
** Olaf ** YES * 4/30/19
** Carsten **  YES * 4/29/19
** Goeran ** YES * 5/7/19
** Ludwig ** YES * 4/29/19

(8) An IPR disclosure has been filed on this by Ericsson.  This was
initially disclosed in a F2F meeting.  No WG discussion has occurred
on this disclosure.

(9) Most of the input and discussions on this draft has come from the
authors and the shepherd rather than the WG as a whole.

(10)  There has been no serious dissension on this draft.

(11) No known ID nits exist.

(12) No formal review is required.

(13) All references are appropriately identified

(14) All normative references are either in the same state as this
document or already finished.

(15) There are no downward normative references.

(16) This document indirectly updates draft-ace-oauth-authz as it
describes and defines a profile for use with that document.

(17) Read the document looking for any and all new things defined by
the text of he document checking against the text of the IANA considerations
section.  Only the one item to be registered needs to be done.  The majority
of all registrations are in the ACE OAuth Framework document.

(18) No new registries are created.

(19) There are no sections of the document that need automated validation.

(1) This document is labeled to be a Proposed Standard.  This is
what the the track of the document should be.

(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 ACE WG has crated a framework for constrained servers
  to do authentication and authroization using OAuth.
  This document provides the details for how to use DTLS as
  the security for protecting and authentication the messages
  defined in the framework as well as the final client to
  resource server messages.

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

  At least two implementations of prior versions of this document
  exist.  The process of doing these implementations and making
  sure that they were interpretable was influential in some of
  the content in the document.

Personnel

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

(3) In addition to validating my implementation of the specification
I checked the IANA considerations to make sure that they were complete,
checked all of the nits and did a read through to make sure all WGLC comments
were addressed.

(4) All of my concerns have been addressed during the WGLC process.

(5) Looking at the mechanism that is defined for resource server
key generation should be checked against the security considerations
and any problems.

(6) I have no specific concerns with this document.

(7) All authors have confirmed that all appropriate IPR discloures have been made

** Stefanie ** YES * 5/2/19
** Olaf ** YES * 4/30/19
** Carsten **  YES * 4/29/19
** Goeran ** YES * 5/7/19
** Ludwig ** YES * 4/29/19

(8) An IPR disclosure has been filed on this by Ericsson.  This was
initially disclosed in a F2F meeting.  No WG discussion has occurred
on this disclosure.

(9) Most of the input and discussions on this draft has come from the
authors and the shepherd rather than the WG as a whole.

(10)  There has been no serious dissension on this draft.

(11) No known ID nits exist.

(12) No formal review is required.

(13) All references are appropriately identified

(14) All normative references are either in the same state as this
document or already finished.

(15) There are no downward normative references.

(16) This document indirectly updates draft-ace-oauth-authz as it
describes and defines a profile for use with that document.

(17) Read the document looking for any and all new things defined by
the text of he document checking against the text of the IANA considerations
section.  Only the one item to be registered needs to be done.  The majority
of all registrations are in the ACE OAuth Framework document.

(18) No new registries are created.

(19) There are no sections of the document that need automated validation.

(1) This document is labeled to be a Proposed Standard.  This is
what the the track of the document should be.

(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 ACE WG has crated a framework for constrained servers
  to do authentication and authroization using OAuth.
  This document provides the details for how to use DTLS as
  the security for protecting and authentication the messages
  defined in the framework as well as the final client to
  resource server messages.

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

  At least two implementations of prior versions of this document
  exist.  The process of doing these implementations and making
  sure that they were interpretable was influential in some of
  the content in the document.

Personnel

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

(3) In addition to validating my implementation of the specification
I checked the IANA considerations to make sure that they were complete,
checked all of the nits and did a read through to make sure all WGLC comments
were addressed.

(4) All of my concerns have been addressed during the WGLC process.

(5) Looking at the mechanism that is defined for resource server
key generation should be checked against the security considerations
and any problems.

(6) I have no specific concerns with this document.

(7) All authors have confirmed that all appropriate IPR discloures have been made

** Stefanie ** YES * 5/2/19
** Olaf ** YES * 4/30/19
** Carsten **  YES * 4/29/19
** Goeran ** YES * 5/7/19
** Ludwig ** YES * 4/29/19

(8) An IPR disclosure has been filed on this by Ericsson.  This was
initially disclosed in a F2F meeting.  No WG discussion has occurred
on this disclosure.

(9) Most of the input and discussions on this draft has come from the
authors and the shepherd rather than the WG as a whole.

(10)  There has been no serious dissension on this draft.

(11) No known ID nits exist.

(12) No formal review is required.

(13) All references are appropriately identified

(14) All normative references are either in the same state as this
document or already finished.

(15) There are no downward normative references.

(16) This document indirectly updates draft-ace-oauth-authz as it
describes and defines a profile for use with that document.

(17) Read the document looking for any and all new things defined by
the text of he document checking against the text of the IANA considerations
section.  Only the one item to be registered needs to be done.  The majority
of all registrations are in the ACE OAuth Framework document.

(18) No new registries are created.

(19) There are no sections of the document that need automated validation.