Re: [Ace] AD review of draft-ietf-ace-aif-04

[Carsten Bormann <[e-mail]>]

Hi Ben,

thank you for the additional comments.

I have prepared another small pull request with resulting changes at 

https://github.com/cabo/ace-aif/pull/2

>>> 
>>> Abstract, Introduction
>>> 
>>> Seeing ~identical abstract and introduction always makes me wonder if
>>> there's a way to pare down the abstract and/or flesh out the introduction
>>> further.  (I didn't get very far in my wonderment today, to be clear.)
>> 
>> I don’t see immediate opportunities for such changes, so I haven’t tried.
> 
> Looking at it again, there may be opportunity to pare down the Abstract.
> E.g.,
> 
> Providing securely protected information about which entities are
> authorized to perform what operations on which other entities is a crucial
> component of producing an overall system that is secure.  This exchange of
> authorization information is especially critical in highly automated
> systems with large number of entities, such as the "Internet of Things".
> 
> This document provides a generic information model and format for
> representing such authorization information, as well as a specific
> instantiation of that format for use with REST resources identified by URI
> path.


This specification does nothing to “securely protect” the authorization information, so I’m not sure the abstract should lead in with that.

Based on your text, I came up with:

>> Information about which entities are authorized to perform what
>> operations on which constituents of other entities is a crucial
>> component of producing an overall system that is secure.  Conveying
>> precise authorization information is especially critical in highly
>> automated systems with large numbers of entities, such as the
>> "Internet of Things".
>> 
>> This specification provides a generic information model and format for
>> representing such authorization information, as well as two variants
>> of a specific instantiation of that format for use with REST resources
>> identified by URI path.
>> 


>>> Also, in the first sentence we say "Constrained Devices [...] need
>>> security."  I see that we go on to focus on the authorization aspect of such
>>> security functionality, but I think it would be good to have some more
>>> adjectives qualifying "security", which in isolation can mean very different
>>> things to different readers.
>> 
>> Hmm, the whole point of the rest of the first paragraph is to specify what kind of security is addressed here.
> 
> I was thinking to add a few more words, like "need security protections in
> order to operate correctly and prevent misuse to attack other systems".

Again, I’m not so sure about focusing on protections here; I shortened this to adding

 in order to operate correctly and prevent misuse

>>> 
>>> Section 5.2
>>> 
>>>  IANA is requested to create a registry for AIF with two sub-
>>>  registries for Toid and Tperm, populated with:
>>> 
>>> Should the sub-registries for Toid and Tperm be on the Media Type
>>> Sub-Parameter Registries page
>>> (https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml)
>>> rather than on a dedicated AIF page?
>> 
>> I think we are better off not burying the information there.
> 
> I am not so sure.
> 
> To me, the core question is whether these registries are used for anything
> other than media-type parameters.  What such other usage do you envision?

Looking at this again, I now agree that using the existing registry page is appropriate.  It is still somewhat hidden, but the specification will point to it (as it will to the media type registration, which is not less hidden).

> It's only February! ;)

I think the authors of lwig-cellular [1] thought that it was only January, too…

Thank you for all the improvements!

Grüße, Carsten

[1]: https://www.rfc-editor.org/cluster_info.php?cid=C280