[OPSAWG] draft-ietf-opsawg-sbom-access
Eliot Lear <lear@lear.ch> Fri, 28 April 2023 10:44 UTC
Return-Path: <lear@lear.ch>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813CC151539 for <opsawg@ietfa.amsl.com>; Fri, 28 Apr 2023 03:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 OlKPMRuXhRXF for <opsawg@ietfa.amsl.com>; Fri, 28 Apr 2023 03:44:17 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 40A09C1516F2 for <opsawg@ietf.org>; Fri, 28 Apr 2023 03:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1682678645; bh=nyy5XSAvi1q4JJNYrSTO3tSEoZoDhvNf0pGiW9EsPp8=; h=Date:To:From:Subject:From; b=DWbs0yjWjhFfnvAFrFicFZO0j4t3tz7ovYC27koWUMltZgGC2kn2EdgZeS95NOkL1 NfDkQYp7Ai53GKPACSs/21zvIFT2NpiJwPrxF+mh91B2r0FU9r0gkc30KcBdT0jM5I nUhNpGQmdzEer79iJeFP2yWOcISOlmABGHnUMRKI=
Received: from [IPV6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 33SAi4ZI336031 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for <opsawg@ietf.org>; Fri, 28 Apr 2023 12:44:05 +0200
Message-ID: <7aa5c179-1fab-77ff-123e-35562d84fa64@lear.ch>
Date: Fri, 28 Apr 2023 12:44:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: "opsawg@ietf.org" <opsawg@ietf.org>
From: Eliot Lear <lear@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/UfUZT-doqgQhbQNM2tacQNSWisw>
Subject: [OPSAWG] draft-ietf-opsawg-sbom-access
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2023 10:44:21 -0000
During the IESG evaluation, I received a query from the AD about using leaf-lists instead of leafs for SBOM and vulnerability data. Before we publish this document, I think it's probably worth reviewing those nodes. Right now, everything is a leaf. For SBOMs at least, to me this makes sense, since the SBOM should be a description of the system to which the schema refers. Having multiple descriptions introduces the need for potential conflict resolution between those descriptions, and complicates processing in a way that could cause interoperability problems. For vulnerability information, I feel differently. It may be desirable to update the description by vulnerability, rather than to have one large file of vulnerabilities. It may also be undesirable, in that it means you have to get description updates when vulnerabilities are updated, rather than just updating one file. But I see no harm in allowing both methods. Therefore, my suggestion is that we change vuln-url to be a leaf-list. Are there any objections? Eliot
- [OPSAWG] draft-ietf-opsawg-sbom-access Eliot Lear
- Re: [OPSAWG] draft-ietf-opsawg-sbom-access Dick Brooks
- Re: [OPSAWG] draft-ietf-opsawg-sbom-access Eliot Lear
- Re: [OPSAWG] draft-ietf-opsawg-sbom-access Dick Brooks