An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)
draft-ietf-ace-aif-07
Yes
(Benjamin Kaduk)
No Objection
John Scudder
Zaheduzzaman Sarker
(Alvaro Retana)
(Martin Vigoureux)
Note: This ballot was opened for revision 05 and is now closed.
Erik Kline
No Objection
Comment
(2022-03-07 for -06)
Not sent
* I support Rob's discuss/find.
Francesca Palombini
No Objection
Comment
(2022-03-10 for -06)
Sent
Thank you for the work on this document Many thanks to Marco Tiloca for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/P7tlVXlIMMJJ8cc9hBA1jMOqVZY/, to Alexey Melnikov for his media-type review: https://mailarchive.ietf.org/arch/msg/media-types/rxzyZhpOLwH1UuueYwlMSENSOak/, and to Carsten for addressing them. Francesca
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment
(2022-03-09 for -06)
Sent for earlier
I support Robert's DISCUSS. The shepherd writeup seems to have been done in something of a hurry, and I'd like to see that cleaned up if possible before publication. Specifically: The first question doesn't contain a complete answer. The Document Quality section is not answered at all. "No" is a curious answer to #13; it's saying references are not split into "Normative" and "Informative"? The answer to #14 is similarly curious. The answer to #18 is confusing; it appears to be a registry snapshot, not a confirmation that any new registries are properly defined. Lastly, #20 was not answered. The Abstract seems to suggest very broad application. Should there be a sentence in there that indicates the context of the work (specifically, ACE)? In Section 5.1, "Required Parameters" shouldn't be "none", but rather "N/A"; see Section 5.6 of RFC 6838 for more information. The second paragraph of Section 6 (about default-deny) strikes me as something that should really be up in Section 2 or Section 3; it's something fundamental and ought to be called out up front.
Roman Danyliw
No Objection
Comment
(2022-03-08 for -06)
Sent
** Section 5.2. The registration policy is Specification required [RFC8126]. The designated expert will engage with the submitter to ascertain the requirements of this document are addressed. To help the DE, is there a way to be clearer on what requirements need to be satisfied? Is it the bulleted list in the SecCons? Section 4? ** Section 6. I was under the impression that AIF didn’t have an explicit requirement to use CoAP. For example, draft-ietf-ace-mqtt-tls-profile appears to use the information model but isn’t restricted to CoAP. Therefore, is it more accurate to say: OLD The security considerations of [RFC7252] apply NEW When AIF is used with CoAP, the security considerations of [RFC7252] apply.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment
(2022-03-08 for -06)
Sent
Thank you for the work put into this document. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Loganaden Velvindron for the shepherd's write-up even if there is no justification for the intended status and little is written about WG consensus beyond "no objections". I hope that this helps to improve the document, Regards, -éric # COMMENTS I like when "internet of things" is used without its "IoT" acronym ;) ## Abstract In "This specification provides a generic information model and format" should this rather be "This specification provides a generic information and a data models" ? ## Section 2 Suggestion: to avoid the reader to stop wondering at figure 1, please introduce "Toid" and "Tperm" before the figure 1. ## Section 2.3 I took me several reading and parsing of this section to understand the need and the specification of "dynamic-GET". May I suggest a rewrite about: the issue that this section wants to address, be specific that this doc define "dynamic methods" (not defined anywhere else) ? See also Rob's comment. ## Section 3 In the first paragraph, should the plural form be used for 'information model' ? As two of them are defined before.
Benjamin Kaduk Former IESG member
Yes
Yes
(for -05)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Not sent
Lars Eggert Former IESG member
No Objection
No Objection
(2022-03-07 for -06)
Sent
The IANA review of this document seems to not have concluded yet. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditionally"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread". Thanks to David Schinazi for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/_BxkOEZJVOgcLQdyMj3dV0NYRB0). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.2. , paragraph 3, nit: - conditionalized access based on state outside the identification of - ---- Section 1. , paragraph 3, nit: > structure that can be used for many different applications and as a specific > ^^^^^^^^^^^^^^ Consider using "many". Section 1.1. , paragraph 4, nit: > ically secured (or transmitted in a secure way). This section discusses the i > ^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "securely" to avoid wordiness. Section 2. , paragraph 3, nit: > identified (e.g., as part of the armor around it). The generic model of such > ^^^^^^^^^^^^^^^^^^^ Consider using "the surrounding armor".
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Not sent
Robert Wilton Former IESG member
(was Discuss)
No Objection
No Objection
(2022-03-10 for -06)
Sent
Thanks for addressing my discuss and comments. Regards, Rob