[Ace] [IANA #1303039] expert review for draft-ietf-ace-wg-coap-eap (core-parameters, CoAP Content-Formats)
Dear Authors/Chairs/ADs, Following up on this; please see below for comments from the expert. -- I believe the draft would need a few updates to clarify the new media type and the precise request. * application/coap-eap is registered but never used (i.e. referred to by name) from any other section. * I couldn't find an explicit format/syntax definition for this new media type. * Is it equal to the CBOR data format defined in Section 4? If so, then section 4 should mention at least the name of the new media type and section 8.5 ideally should give a quick pointer to section 4 for the format definition. * the text in 8.6 should better refer to Section 12.3 of [RFC 7252] for the registry; link to [RFC 6690] is not so useful here. The text says "Expert Review" but that's only for the 0-255 range. For this range some additional motivation is required why it needs to be there, and this is missing. For the 256- range the procedure is "IETF review" -> did you mean to select this range? It would be ok to continue the registration with the current draft, if the authors want to make text clarifications later on and not now. A number in the 256- is for sure ok (if that's intended), for example 260, but for 0-255 range some reason/rationale needs to be provided. -- Best regards, David Dong IANA Services Sr. Specialist On Fri Jan 12 17:27:37 2024, david.dong wrote: > Dear Authors/Chairs/ADs, > > Please see below for comments from the expert. > > -- > > I believe the draft would need a few updates to clarify the new media > type and the precise request. > > * application/coap-eap is registered but never used (i.e. referred to > by name) from any other section. > * I couldn't find an explicit format/syntax definition for this new > media type. > * Is it equal to the CBOR data format defined in Section 4? If so, > then section 4 should mention at least the name of the new media type > and section 8.5 ideally should give a quick pointer to section 4 for > the format definition. > * the text in 8.6 should better refer to Section 12.3 of [RFC 7252] > for the registry; link to [RFC 6690] is not so useful here. > The text says "Expert Review" but that's only for the 0-255 range. For > this range some additional motivation is required why it needs to be > there, and this is missing. > For the 256- range the procedure is "IETF review" -> did you mean > to select this range? > > It would be ok to continue the registration with the current draft, if > the authors want to make text clarifications later on and not now. > A number in the 256- is for sure ok (if that's intended), for > example 260, but for 0-255 range some reason/rationale needs to be > provided. > > -- > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Fri Jan 12 09:55:37 2024, esko.d...@iotconsultancy.nl wrote: > > Hello, > > > > I believe the draft would need a few updates to clarify the new media > > type and the precise request. > > > > * application/coap-eap is registered but never used (i.e. referred to > > by name) from any other section. > > * I couldn't find an explicit format/syntax definition for this new > > media type. > > * Is it equal to the CBOR data format defined in Section 4? If so, > > then section 4 should mention at least the name of the new media type > > and section 8.5 ideally should give a quick pointer to section 4 for > > the format definition. > > * the text in 8.6 should better refer to Section 12.3 of [RFC 7252] > > for the registry; link to [RFC 6690] is not so useful here. > >The text says "Expert Review" but that's only for the 0-255 range. > > For this range some additional motivation is required why it needs to > > be there, and this is missing. > >For the 256- range the procedure is "IETF review" -> did you > > mean to select this range? > > > > It would be ok to continue the registration with the current draft, > > if > > the authors want to make text clarifications later on and not now. > > A number in the 256- is for sure ok (if that's intended), for > > example 260, but for 0-255 range some reason/rationale needs to be > > provided. > > > > Regards > > Esko > > > > > > -Original Message- > > From: David Dong via RT > > Sent: Friday, January 12, 2024 02:10 > > Cc: Esko Dijk ; har...@projectcool.de; > > c...@tzi.org; ja...@iki.fi; jaime.jime...@ericsson.com; > > alexan...@ackl.io; ace@ietf.org > > Subject: [IANA #1303039] expert review for draft-ietf-ace-wg-coap-eap > > (core-parameters, CoAP Content-Formats) > > > > Dear Esko Dijk (cc: ace WG), > > > > As the designated expert for the CoAP Content-Formats registry, can > > you review the proposed registration in draft-ietf-ace-wg-coap-eap-09 > > for us? Please see: > > > > https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/ > > > > The due date is January 25. > > > > If this is OK, when the IESG approves the document for publication, > > we'll make the registration at: > > > > http
[Ace] [IANA #1297477] expert review for draft-ietf-ace-key-groupcomm (core-parameters, Custom Problem Detail Keys)
Hi Thomas and Carsten (cc: ace WG), As the designated experts for the Custom Problem Detail Keys registry, can you review the proposed registration in draft-ietf-ace-key-groupcomm-18 for us? This document has already been approved for publication by the IESG. Please see: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ The due date is February 1st, but as this document has already been approved for publication, could you please review at your earliest convenience? If this is OK, we'll make the registration at: https://www.iana.org/assignments/core-parameters/ Unless you ask us to wait for the other reviewers, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] [IANA #1284521] expert review for draft-ietf-ace-key-groupcomm (core-parameters, if=)
Hi Carsten, Jaime, and Christian (cc: ace WG), As the designated experts for the Interface Description (if=) Link Target Attribute Values registry, can you review the updated proposed registrations in draft-ietf-ace-key-groupcomm-18 for us? You have previously review draft-ietf-ace-key-groupcomm-17. The authors have added a new "ace.groups" proposed registration in addition to the previously reviewed "ace.group". Please see: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ The due date is February 2nd. If this is OK, when the IESG approves the document for publication, we'll make the registrations at: https://www.iana.org/assignments/core-parameters/ Unless you ask us to wait for the other reviewers, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist On Wed Nov 29 00:41:26 2023, c...@tzi.org wrote: > Hi Amanda, > > my apologies for the tardy response. > > The registration of this if= type is fundamentally appropriate. > However, there are some aspects of its description that could use > improvement. > > * The description uses the term ‘ace group’ to stand for ace.group. > That could be confusing, but probably will not lead to > interoperability problems. > > * The description could be pointing to Section 4.1 (of course, a > search will also find that section). > > * Section 4.1 defines a number of resources. Which of these is the > one that the link marked if= should point to? One might think that it > is the one named /ace-group as an example, and not the individual ones > named /ace-group/GROUPNAME. However, the examples in draft-tiloca- > core-oscore-discovery indicate otherwise. > It would be preferable to make the answer to this question explicit in > ace-key-groupcomm (an example for such a link in ace-key-groupcomm > would also help). > Deferring much of the actual definition of the if= type to draft- > tiloca-core-oscore-discovery while already registering it here does > not work very well for this specification reader. > > Grüße, Carsten > > > [1]: https://www.ietf.org/archive/id/draft-tiloca-core-oscore- > discovery-14.html > > On Nov 28, 2023, at 19:28, Amanda Baber via RT comm...@iana.org> wrote: > > > > Dear Carsten Bormann, Jaime Jimenez, and Christian Amsüss (cc: ace > > WG), > > > > This is a reminder that if we don't receive an approval from one of > > the experts by tomorrow, we'll have to mark this document "IANA NOT > > OK" and request a DISCUSS for Thursday's telechat. > > > > thanks, > > > > Amanda Baber > > IANA Operations Manager > > > > On Mon Nov 27 23:52:56 2023, david.dong wrote: > >> Dear Carsten Bormann, Jaime Jimenez, and Christian Amsüss (cc: ace > >> WG), > >> > >> Following up on this request; as the designated experts for the > >> Interface Description (if=) Link Target Attribute Values registry, > >> can > >> you review the proposed registration in draft-ietf-ace-key- > >> groupcomm- > >> 17 for us? > >> > >> This document is on the agenda for the upcoming November 30th IESG > >> telechat. > >> > >> Please see: > >> > >> https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ > >> > >> The due date was November 9th. > >> > >> If this is OK, when the IESG approves the document for publication, > >> we'll make the registration at: > >> > >> https://www.iana.org/assignments/core-parameters/ > >> > >> Unless you ask us to wait for the other reviewers, we’ll act on the > >> first response we receive. > >> > >> With thanks, > >> > >> David Dong > >> IANA Services Sr. Specialist > >> > >> On Tue Nov 21 17:55:47 2023, david.dong wrote: > >>> Dear Carsten Bormann, Jaime Jimenez, and Christian Amsüss (cc: ace > >>> WG), > >>> > >>> Following up on this request; as the designated experts for the > >>> Interface Description (if=) Link Target Attribute Values registry, > >>> can > >>> you review the proposed registration in draft-ietf-ace-key- > >>> groupcomm- > >>> 17 for us? This document is on the agenda for the upcoming November > >>> 30th IESG telechat. > >>> > >>> Please see: > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ > >>> > >>> The due date was November 9th. > >>> > >>> If this is OK, when the IESG approves the document for publication, > >>> we'll make the registration at: > >>> > >>> https://www.iana.org/assignments/core-parameters/ > >>> > >>> Unless you ask us to wait for the other reviewers, we’ll act on the > >>> first response we receive. > >>> > >>> With thanks, > >>> > >>> David Dong > >>> IANA Services Sr. Specialist > >>> > >>> On Tue Nov 14 18:07:19 2023, david.dong wrote: > Dear Carsten Bormann, Jaime Jimenez, and Christian Amsüss (cc: ace > WG), > > Following up on this request; as the designated experts for the > Interface Description (if=) Link Target Attribute Values registry, > can > you review the proposed registration in draft-ietf-ace-key- > groupcomm- > 17 for us? Please see: >
[Ace] Protocol Action: 'Key Provisioning for Group Communication using ACE' to Proposed Standard (draft-ietf-ace-key-groupcomm-18.txt)
The IESG has approved the following document: - 'Key Provisioning for Group Communication using ACE' (draft-ietf-ace-key-groupcomm-18.txt) as Proposed Standard This document is the product of the Authentication and Authorization for Constrained Environments Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ Technical Summary This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. Working Group Summary No controversies. Document Quality This draft in itself cannot be implemented. The API and message template formats that it defines have to be instantiated by its profiles (such as key-groupcomm-oscore), which can rather be implemented. The latest has been implemented in the java ACE implementation for Californium https://bitbucket.org/marco-tiloca-sics/ace-java/ Personnel The Document Shepherd for this document is Daniel Migault. The Responsible Area Director is Paul Wouters. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
