[art] Artart last call review of draft-ietf-ace-aif-05

Marco Tiloca via Datatracker <noreply@ietf.org> Tue, 22 February 2022 18:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B323A130E; Tue, 22 Feb 2022 10:56:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Marco Tiloca via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: ace@ietf.org, draft-ietf-ace-aif.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164555618912.17476.10903961003636458894@ietfa.amsl.com>
Reply-To: Marco Tiloca <marco.tiloca@ri.se>
Date: Tue, 22 Feb 2022 10:56:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/P7tlVXlIMMJJ8cc9hBA1jMOqVZY>
Subject: [art] Artart last call review of draft-ietf-ace-aif-05
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Feb 2022 18:56:30 -0000

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.

* 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]

* s/e.g., 35 for Dynamic-DELETE/e.g., 35 would be the number for Dynamic-DELETE

[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?

   Also, perhaps it is better to name it "URI-local-part".

[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:

[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)

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

[Nits]

* Section 1.1
--- s/This memo uses terms from [RFC7252]/This specification uses terms from
CoAP [RFC7252]

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

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