IETF Logo Mail Archive

Re: [Gen-art] [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03

Eliot Lear <lear@lear.ch> Tue, 04 January 2022 17:25 UTC

Return-Path: <lear@lear.ch>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B883A1F79; Tue, 4 Jan 2022 09:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Level:
X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgaFm-4mTsul; Tue, 4 Jan 2022 09:25:13 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB873A1F31; Tue, 4 Jan 2022 09:24:26 -0800 (PST)
Received: from [192.168.0.228] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 204HOLoQ2483092 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 4 Jan 2022 18:24:21 +0100
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1641317062; bh=t2e6WRBEBA42ucM8uTUqIIGiEb+Xb7gcWetNZQhCIWg=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=lIciSzkwQQqTNpwBqUaY9KPhcI35R5SKWS3kLvD0elmy50DHOR56ARiPWySjnqtfO /wEkSSuKEZRXny7sSu5sVU3CEo3asgU71rYMqMN4JTqBo28O2n2wOgpFmh9Ct8rvcX MqMZDxk02E5Brzn09vleMPq7KypgHAsqJe8DtQgI=
Message-ID: <3f03fe08-75eb-429e-13d2-5628bf7ba57b@lear.ch>
Date: Tue, 04 Jan 2022 18:24:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
To: tom petch <ietfc@btconnect.com>, "gen-art@ietf.org" <gen-art@ietf.org>, Russ Housley <housley@vigilsec.com>
Cc: "draft-ietf-opsawg-sbom-access.all@ietf.org" <draft-ietf-opsawg-sbom-access.all@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
References: <AM7PR07MB6248972EC0B8A9E75D42C9E3A04A9@AM7PR07MB6248.eurprd07.prod.outlook.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <AM7PR07MB6248972EC0B8A9E75D42C9E3A04A9@AM7PR07MB6248.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------MzdoEJ4zYN02Sua3FRFwy8K9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/j1laWkQSw9MV9w4ytWK_LpYpoJE>
Subject: Re: [Gen-art] [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jan 2022 17:25:24 -0000

On 04.01.22 18:02, tom petch wrote:
>
> *From:* Eliot Lear
> *Sent:* Tuesday, January 04, 2022 16:28
> *To:* tom petch; gen-art@ietf.org; Russ Housley
> *Cc:* draft-ietf-opsawg-sbom-access.all@ietf.org; opsawg@ietf.org
> *Subject:* Re: [OPSAWG] some YANG thoughts on 
> draft-ietf-opsawg-sbom-access-03
>
> Hi Tom,
>
> Thanks for your review.  Please see below.
>
> <tp>
>
> On security, YANG Guidelines, RFC8407, says that there MUST be 
> Security Considerations and that they MUST be patterned on the latest 
> template. No exemption for read only or grouping only!
>
Any risk is with the data being referred to, not the reference.  We can 
say that.



> For example, I note that you refer to HTTP whereas the template only 
> uses HTTPS, underpinned by TLS.  It is fine to say that the data is 
> read only.  It is also fine to say that the data is in the public 
> domain and so privacy is not a concern.

That really can't be helped because some of the underlying systems 
involved may not support TLS.  Integrity must be handled at different 
layer, and if confidentiality is important, that will have to be 
expressed there as well.  This really is an operational reality.  Again, 
this is a discovery mechanism that describes how to locate the data and 
what protocols to use.  We are not specifying the protocols or formats.


Eliot

v2.23.0 | Report a Bug | By Email