Re: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02

Martin Gfeller <mgf@acm.org> Fri, 22 March 2024 12:52 UTC

Return-Path: <m.c.gfeller@gmail.com>
X-Original-To: sat@ietfa.amsl.com
Delivered-To: sat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D25C151538 for <sat@ietfa.amsl.com>; Fri, 22 Mar 2024 05:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.409
X-Spam-Level:
X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6cYcj3AvB73 for <sat@ietfa.amsl.com>; Fri, 22 Mar 2024 05:52:08 -0700 (PDT)
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF4AC14F694 for <sat@ietf.org>; Fri, 22 Mar 2024 05:52:08 -0700 (PDT)
Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-512f892500cso2471528e87.3 for <sat@ietf.org>; Fri, 22 Mar 2024 05:52:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711111926; x=1711716726; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=90Q/882vVqrjpAu5k5XlST9wOm29W/lRB3ZznT1Ydm4=; b=JjqnYwAsj5Rml9/0NyYyv4AynzaCKHq2RpVuRzDJUHGPLOID5pBGO8VhXWFk2sysVI 5GsxoNsPgpIT0A/tGqq+qzXGz43SlAXvpGPD5MgiTu+DC6pbvwD/4QNPPFVPEouZZqZF bBxqMyOqc/uud0kNNx2tg2nDSO1jXzVu/2/50YpswA/n721KEXWizqYAFFr/cPr8iq25 h234e4B340bL4xrqXh1ZbANGBvc0PqGjowDWM0DngKN2qGkZnDecovaW5AkvzwGhazof 7GPGVPT9z0lHDQoLHwbUcoIMxiaY5A2y10OZtfGx2ddVOjOPWhTlartSQGX4VoyciZH8 wF9Q==
X-Gm-Message-State: AOJu0YxLdgyrsmqn2t19DqeMBMWi0AhCih2yAj/VEsoQqQrdf6sK7bzI bF1KmCg84yHo4XE0ojzo/tcOU+AiuR28U8ozorQco5awzSlPAXSc9fFvIKlLknK/lJhB6gCXDJ8 B5evDe9lKV5wbp7bF1+hIyar+2E/HkwCalQ==
X-Google-Smtp-Source: AGHT+IF5oFdP0u8qmXM9op98gwY8d2dDBN/yJV1fIqIdmqwQKtFscRjmOw3zmsO20Q3EyV6KG/k+fbW1z8fabn48ycE=
X-Received: by 2002:a19:691d:0:b0:513:a738:20f1 with SMTP id e29-20020a19691d000000b00513a73820f1mr1936608lfc.25.1711111925915; Fri, 22 Mar 2024 05:52:05 -0700 (PDT)
MIME-Version: 1.0
From: Martin Gfeller <mgf@acm.org>
Date: Fri, 22 Mar 2024 13:51:54 +0100
Message-ID: <CAOYrHJMXX1Ux_okwu_39idY0QfWHS3XoEUCOG_REZhNCpKqQ4A@mail.gmail.com>
To: sat@ietf.org
Content-Type: multipart/alternative; boundary="00000000000083ec3806143f4afd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sat/11VOEYSgdDcB3sbxJ3M70CVYSTs>
Subject: Re: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02
X-BeenThere: sat@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "The purpose of this mailing-list is to discuss the secure asset transfer \(SAT\) protocol and related aspects." <sat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sat>, <mailto:sat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sat/>
List-Post: <mailto:sat@ietf.org>
List-Help: <mailto:sat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sat>, <mailto:sat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 12:52:09 -0000

Dear Thomas and Wes

I have the following comments / questions, most likely based on my
incomplete understanding:

2. Terminology - Resource Domain:

 > The collection of resources and entities participating within an asset
network.  The domain denotes a boundary for permissible or authorized
actions on resources.

I find this a bit hard to understand - participating in what exactly?
Boundary means that actions cannot reach into another domain?

Resource Domain is not used thereafter (or I didn't find it).  The
following two definitions, interior and exterior resources are way easier
to grasp.


2. Terminology - Application Context-ID and 5.5 Stage 0

In 5.5 Stage 0, it is explained that the apps "may establish some shared
transfer context information (e.g.  Context-ID)", but I didn't find any
information on why this is required or beneficial.
Why not something like "Shared transfer context information (in particular,
IDs) may be established between applications if required for a particular
use case or application."


5.4 Event log-data ...:

> The log-data generated by a gateway should be considered as an interior
resource
> accessible to other authorized gateways within the same network.


> The mechanism used to provide gateway crash-recovery is dependent on
> the specific network.  For interoperability purposes the information
> contained in the log and the format of the log-data should be
> standardized.


The log-data is declared internal to a network, yet it asks for
standardization, without mentioning which standard should be followed.
Perhaps "should use standards established within the network"
would suffice, without mentioning interoperability at all.

14.1 Normative References

[ISO] Why not reference it as [ISO22739], although the reference isn't used
in the body? There is a new version ISO 22739:2024.


Best regards,
Martin

-----Original Message-----
From: sat <sat-bounces@ietf.org<mailto:sat-bounces@ietf.org>> On Behalf Of
Wes Hardaker
Sent: Saturday, March 9, 2024 9:08 AM
To: sat@ietf.org<mailto:sat@ietf.org>
Subject: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02


Greetings all,

The authors have requested that draft-ietf-satp-architecture-02 be placed
into WG last call and after a review by the chairs we agree it's ready to
progress forward.  I have some personal comments that I'll submit during
last call, but nothing substantive or process-problematic that should hold
up it progressing.  Thus, we have changed the document's status to being in
WG LC and have set a deadline of 4 weeks from now.  Thus, WG LC will end on
April 6th, AOE (anywhere on earth).

We encourage all participants of the WG to read the document,  suggest any
changes you feel are needed from simple editorial suggestions to calling
out major issues you find with the document.  WG participants should also
express their opinions about whether or not the document is ready to
progress and you support it's publication.

All comments should be sent to the mailing list.

--
Wes Hardaker
USC/ISI