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
- [Sat] WG Last Call for comments: draft-ietf-satp-… Wes Hardaker
- Re: [Sat] WG Last Call for comments: draft-ietf-s… ladler2
- Re: [Sat] WG Last Call for comments: draft-ietf-s… VENKATRAMAN RAMAKRISHNA
- Re: [Sat] WG Last Call for comments: draft-ietf-s… Thomas Hardjono
- Re: [Sat] WG Last Call for comments: draft-ietf-s… Rafael Belchior
- Re: [Sat] WG Last Call for comments: draft-ietf-s… VENKATRAMAN RAMAKRISHNA
- Re: [Sat] WG Last Call for comments: draft-ietf-s… Thomas Hardjono
- Re: [Sat] WG Last Call for comments: draft-ietf-s… ladler2
- Re: [Sat] WG Last Call for comments: draft-ietf-s… Thomas Hardjono
- Re: [Sat] WG Last Call for comments: draft-ietf-s… VENKATRAMAN RAMAKRISHNA
- Re: [Sat] WG Last Call for comments: draft-ietf-s… Thomas Hardjono
- Re: [Sat] WG Last Call for comments: draft-ietf-s… Martin Gfeller