Skip to main content

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