Re: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-sbom-access-03

Lars Eggert <lars@eggert.org> Mon, 24 April 2023 13:51 UTC

Return-Path: <lars@eggert.org>
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 BE019C152D8F; Mon, 24 Apr 2023 06:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 XP-3yq2fZ0Hr; Mon, 24 Apr 2023 06:51:05 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A168C15153F; Mon, 24 Apr 2023 06:51:02 -0700 (PDT)
Received: from smtpclient.apple (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 29D6F20886; Mon, 24 Apr 2023 16:50:53 +0300 (EEST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Lars Eggert <lars@eggert.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 24 Apr 2023 16:50:50 +0300
Message-Id: <1EEACBC2-F53F-4B88-B561-90ACAC7EAD61@eggert.org>
References: <163943295026.14606.17568188352214673806@ietfa.amsl.com>
Cc: gen-art@ietf.org, draft-ietf-opsawg-sbom-access.all@ietf.org, opsawg@ietf.org
In-Reply-To: <163943295026.14606.17568188352214673806@ietfa.amsl.com>
To: Russ Housley <housley@vigilsec.com>
X-MailScanner-ID: 29D6F20886.A90F7
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/fi_Ctt7LhutXUXeMqgnEeFEQmZY>
Subject: Re: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-sbom-access-03
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: Mon, 24 Apr 2023 13:51:07 -0000

Russ, thank you for your review. I have entered a No Objection ballot for this document.

Lars

> On 14. Dec 2021, at 00:02, Russ Housley via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-opsawg-sbom-access-03
> Reviewer: Russ Housley
> Review Date: 2021-12-13
> IETF LC End Date: unknown
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> 
> Note: I am not a good persone to review the YANG specification.  I
> assume one of the YANG Doctors will have a look at this document too.
> 
> 
> Major Concerns:
> 
> Section 1 says:
> 
>   To satisfy these two key use cases, objects may be found in one of
>   three ways:
> 
> This lead to some confusion for me.  Earlier in the document, it says:
> 
>   This specification does not allow for vulnerability information to be
>   retrieved directly from the endpoint.  That's because vulnerability
>   information changes occur at different rates to software updates.
> 
> After thinking about it, I realized that the objects do not include
> vulnerability information, but pointers to obtain vulnerability
> information.  Please reword to others do not need to give it the
> same amount of thought.
> 
> 
> Minor Concerns:
> 
> Section 1, first sentence: The reference to "A number of activities"
> is very vague.  It is not wrong.  Please be more specific, provide
> some references, or drop the vague reference altogether.
> 
> Section 1 says:
> 
>   In the second case, 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.
> 
> s/must/MUST/ ?
> 
> 
> Nits:
> 
> The terms "software" and "firmware" are used with essentially the same
> meaning in this document.  If there is a difference, it needs to be
> explained.  If they are the same in the context of this document, please
> say so.
> 
> Abstract, last sentence: please add "(MUD)" and also a pointer to
> RFC 8520.
> 
> Section 1, first sentence: The reference to "A number of activities"
> is very vague.  It is not wrong.  Please be more specific, provide
> some references, or drop the vague reference altogether.
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art