Re: [Ace] Lars Eggert's No Objection on draft-ietf-ace-aif-06: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Lars,

my apologies for again using an older word.

> On 2022-03-07, at 10:38, Lars Eggert via Datatracker <[e-mail]> wrote:
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-ace-aif-06: No Objection
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The IANA review of this document seems to not have concluded yet.

This is just due to the updated I-D revision, IIUC.
The expert reviews are in.

> 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".

Fixed in https://github.com/cabo/ace-aif/commit/816eccf
(We actually don’t need to emphasize the “time-honored” aspect here; “capability list” is just terminology that some readers that care about authorization will know.)

> 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.

Just a data point — languagetool had pointed me to each of these and I had already decided to stay with the original words.  There should be a “<sic>…</sic>” in RFCXML :-).  (It also pointed me to a dozen other places that I did change.)

Grüße, Carsten