[OPSAWG] Warren Kumari's No Objection on draft-ietf-opsawg-sbom-access-15: (with COMMENT)
Warren Kumari via Datatracker <noreply@ietf.org> Wed, 26 April 2023 00:32 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF305C151983; Tue, 25 Apr 2023 17:32:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-sbom-access@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, henk.birkholz@sit.fraunhofer.de, bill.wu@huawei.com, bill.wu@huawei.com, henk.birkholz@sit.fraunhofer.de, ops-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <168246915176.4422.14143513950445519246@ietfa.amsl.com>
Date: Tue, 25 Apr 2023 17:32:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Kjw8XsufpVecdtjz2_7YTjBpnro>
Subject: [OPSAWG] Warren Kumari's No Objection on draft-ietf-opsawg-sbom-access-15: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 26 Apr 2023 00:32:32 -0000
Warren Kumari has entered the following ballot position for draft-ietf-opsawg-sbom-access-15: No Objection 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-opsawg-sbom-access/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document, and also much thanks to Henk for the OpsDir review - https://datatracker.ietf.org/doc/review-ietf-opsawg-sbom-access-03-opsdir-early-comstedt-2021-12-19/ I found it an easy read, and only have a few nits to offer: 1: "A number of activities have been working to improve visibility to what software is running on a system, and what vulnerabilities that software may have[EO2021]." Missing space before the [EO2021] reference. 2: "... two classes of questions *at scale*:" I think that you should drop the "emphasis" - I really don't think that it helps readability, and looks "odd". I often use this form for emphasis, but I really don't think that it should be used in an RFC. 3: "Examples of these interfaces might be an HTTP [RFC7231],[RFC9110], or COAP [RFC7252] endpoint for retrieval." Missing space after [RFC7231] -- hey, I *did* mention that this is all nits (and also that I *emphasize text*). 4: "Using the second method, when a device does not have an appropriate retrieval interface, but one is directly available from the manufacturer, a URI to that information MUST be discovered." I don't really understand the uppercase MUST here; it's unclear who / what the MUST is directed at. 5: "To address either risk, any change in a URL, and in particular to the authority section, should be treated with some suspicion. One mitigation would be to test any cloud-based URL against a reputation service." I don't really have any useful text to suggest, but I find the wording of "To address either risk, ..., should be treated with some suspicion" to be strange. I don't really view treating something with suspicion as addressing a risk. I *do* know what you are trying to say, but I don't really think that this accomplishes it. I'm also not really sure why the second sentence only views 'cloud-based' URLs as different to non-cloud-based ones - why is foo.bar.example.com more or less sketchy if it is on AWS then on a physical server? And I think that the hand-wavy "check it against some sort of reputation thing" is sufficiently underspecified that it's not helpful. Please notes that these really are just intended to be nits / attempts to help improve the document; I seem to be having a hard time with my tone in this writeup and apologize if it came out as snarky....
- [OPSAWG] Warren Kumari's No Objection on draft-ie… Warren Kumari via Datatracker
- Re: [OPSAWG] Warren Kumari's No Objection on draf… Eliot Lear