Re: [Last-Call] Artart last call review of draft-ietf-ace-aif-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Carsten,

All updates look good to me. Thanks for addressing my comments.

Best,
/Marco

On 2022-03-03 13:02, Carsten Bormann wrote:
Hi Marco,

thank you for this very actionable review!

Changes are in https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabo%2Face-aif%2Fpull%2F7&data=04%7C01%7Cmarco.tiloca%40ri.se%7C044602d05e2b4b81f7d308d9fd0dafed%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819057505343778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tJEKNK5am2qXhVCqZLy5yzVAbcYNRqpCx0gyGNny9N8%3D&reserved=0
(and in https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabo%2Face-aif%2Fpull%2F5&data=04%7C01%7Cmarco.tiloca%40ri.se%7C044602d05e2b4b81f7d308d9fd0dafed%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819057505343778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hX26UY66r3j2Kb7H%2FERkUTrATFPGj8PXtIoakxv8v8g%3D&reserved=0, see below).
I plan to wait for comments on these PRs and then to submit an updated I-D.

On 2022-02-22, at 19:56, Marco Tiloca via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Marco Tiloca
Review result: Ready with Nits

Thanks for this good document! Please, find below a few minor comments.

Best,
/Marco

[Section 2.2]

* The first paragraph has the only occurrence of "AIF object". I suppose that's
what you call "list of pairs" in Section 2, right before Figure 1.

   If so, it may help to define "AIF object" there in Section 2, or to rather
   replace it with something like "list of (Toid, Tperm) pairs" here in Section
   2.2.
Indeed, the term “AIF Object” may be confusing to people used to the JSON terminology, where “Object” refers to a map.  Replaced it with “AIF data item”, as already used in two other places.

* In the second paragraph, an access is possibly subject to conditions, not
dictating them. Thus, shouldn't the right word be "conditionalized" rather than
"conditionalizing" ?

[Section 3]
Well, it is the information model that further conditionalizes here.  Simplified this to

This simple information model also does not allow expressing
conditionalized access based on state outside the identification of
objects (e.g., "opening a door is allowed if that is not locked").

* s/e.g., 35 for Dynamic-DELETE/e.g., 35 would be the number for Dynamic-DELETE
Well, 35 actually *is* the number for Dynamic-DELETE.  Now:

   been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is the
   number for Dynamic-DELETE as the number for DELETE is 3).


[Sections 4, 5.1 and 5.2]

* In Section 4 and later on when registering the two media-types in Section
5.1, "local-uri" is used as default value for the Toid parameter.

   However, the new sub-registry defined in Section 5.2 (and where Toid values
   have to be taken from) is populated with an entry with value "local-part".
   Shouldn't they all indicate the same value?
Yes, Klaus Hartke noticed this, too, PR #5.

   Also, perhaps it is better to name it "URI-local-part".
Good idea, added to PR #5.

[Section 5.2]

* Suggested rephrasing:

   For both media-types application/aif+cbor and application/aif+json, IANA is
   requested to create a sub-registry within [IANA.media-type-sub-parameters]
   for the two media-type parameters Toid and Tperm, populated with:
s/both/the/, otherwise changed as proposed

[Section 6]

* The first bullet point has the only occurrence of "AIF information". Perhaps
this is another name for what you called "AIF object" in Section 2.2? (see
previous comment for similar considerations)
Went to “AIF data item” again.

* The second bullet point says: "and that all parties understand Toid/Tperm
pairs to signify the same operations."

   Suggested rephrasing: "and that all parties have the same understanding of
   each Toid/Tperm pair in terms of specified resources and operations on those"
Nice!  Changed.
I changed “resources” to “objects (resources)”, because the objects of the access control matrix don’t actually need to be resources.

[Nits]

* Section 1.1
--- s/This memo uses terms from [RFC7252]/This specification uses terms from
CoAP [RFC7252]
Good idea.
I also expanded the Internet Security Glossary.

* Section 2.2
--- s/, however,/. However,

* Section 6
--- s/and provides (2) any/and (2) provides any

Thank you!

Grüße, Carsten


--
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Attachment: OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux