[Cbor] Roman Danyliw's Discuss on draft-ietf-cbor-file-magic-11: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 20 April 2022 02:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: cbor@ietf.org
Delivered-To: cbor@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2937F3A189D; Tue, 19 Apr 2022 19:03:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cbor-file-magic@ietf.org, cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, christian@amsuess.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <165042018713.9385.10789424906577326164@ietfa.amsl.com>
Date: Tue, 19 Apr 2022 19:03:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/II4V1WJ8txMEowbOF14nJ0tX8MI>
Subject: [Cbor] Roman Danyliw's Discuss on draft-ietf-cbor-file-magic-11: (with DISCUSS and COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2022 02:03:07 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-cbor-file-magic-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 2.1.

(a) "In both enveloping methods, CBOR Protocol designers need to obtain a CBOR
tag for each kind of object that they might store on disk.  ... The IANA policy
for 4-byte CBOR Tags is First Come First Served, ..."

(b) "This tag needs to be allocated by the author of the CBOR Protocol."

Both of these statements are made in this section and they appear to conflict. 
(a) appears to be saying that CBOR tags will be allocated from the FCFS IANA
registry to the protocol designer.  However, later in the section (b) says that
the author is allocating the tags.  If the author performing the
allocation/assignment, it would seem to be coming from the registry per (a).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank to Chris Wood for the SECDIR review.  Please review the editorial
suggestions posed there.

** Section 2.2
   This method wraps the CBOR value as tags usually do.  Applications
   that need to send the CBOR value across a constrained link may wish
   to remove the two tags if the use is implicitly understood.

Is this behavior akin to not using this enveloping method?

** Section 3.3
   If the Protocol expects to use other tags values at the top-level,
   then the use of the tag wrapped format may be easier to explain in
   the protocol description.

(As also pointed by Chris Wood in the SECDIR review) This text would benefit
from refinement.  Specifically:

-- what does it mean to be “easier to explain in the protocol description”?

-- how does a top-level tag that isn’t one of the two approaches posed here
work with the rest of the behavior in this document?

** Section 4.  Consider adding the following generic text on relying on “magic
values”:

End-point assessment technologies should not solely rely on the meta data
approaches described in this document to decide whether to inspect a given file.

Depending on operating systems configurations and related properties of the
execution environment, use of these meta data approaches could influence the
default application used to process a file, regardless of whether this file in
fact contains CBOR.