[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....