[Ace] Review on draft-bormann-core-ace-aif-07

Jim Schaad <ietf@augustcellars.com> Mon, 25 May 2020 20:46 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: draft-bormann-core-ace-aif@ietf.org
CC: 'Ace Wg' <ace@ietf.org>
Date: Mon, 25 May 2020 13:46:38 -0700
Message-ID: <031c01d632d5$98158ba0$c840a2e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
Thread-Index: AdYySg6qaQ1K2nGySeOKYIC/kF1pfw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2VX2gLdAzjPs9aSkZmP7ZBK3tsY>
Subject: [Ace] Review on draft-bormann-core-ace-aif-07
Precedence: list

* Section 2 - I would like more clarification on the subject as being
derived implicitly from the armor and is a single entity rather than
multiple entities.   If we think that we want to do multiple subjects then
that needs to be discussed.

* Section 2.1 - The model does not current deal with the question of queries
and how they would be permitted for a non-query object.

*  How do we ant to look at doing the generalization for the structure
provided.  There are two things to look at:

1.  The object identifier:  It makes sense for a good many things for this
to be an absolute-path.  However for other things this would be some type of
identifier.  With both the GroupKDC and with MQTT this identifier is a
string.  In the MQTT case the string has defined wild card behavior.  Part
of the question is how much does the object naming scheme need to be
identified to the client, the AS and the RS.  

2.  The permissible actions:  For a coap addressed device, it makes sense
for this to be based on the set of coap verbs and the compressed bit string
makes a great deal of sense.  However for both GroupKDC and MQTT these verbs
are not the same and thus cannot be compressed in the same manner. 

What I would like to see is a structure defined that can be used in a number
of situations, but which the details are going to be very object dependent.


authorization-info = [ * authorization]

authorization = [
   object: object-identifier,
   permissions: [* permission-name] | uint .bits methods
]

permission-name = tstr

One option would be to allow the methods to be object dependent this means
that you could have  "methods = &( PUBLISH: 0, SUBSCRIBE: 1)" for the MQTT
case.  The advantage of this is that it provides better compressions, but it
also means that one needs to know what the enumeration is for each different
type of object.  I don't know if this means that one needs to start having a
registry to deal with people adding verbs to a particular interface.  I also
don't know what it would mean if they were interface specific and an object
supported two different interfaces.

Nits:
Section 2 - para 2 s/on object/an object/

Jim

[Ace] Review on draft-bormann-core-ace-aif-07 Jim Schaad