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

Eliot Lear <lear@lear.ch> Tue, 04 January 2022 16:28 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 CC89E3A1E0A; Tue, 4 Jan 2022 08:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.604
X-Spam-Level:
X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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 rsXvcnijwQ7r; Tue, 4 Jan 2022 08:28:27 -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 187103A1E09; Tue, 4 Jan 2022 08:28:26 -0800 (PST)
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-18) with ESMTPSA id 204GSL5i2482410 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 4 Jan 2022 17:28:22 +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=1641313702; bh=bIeAe8q717ixh4d+k6k3X+sl/MWxxQn5WxOtWZleI2U=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=AN/penxL7NB+oxpeUg03TOPbtu4WsAbcqlcNDVr+rbEQjCEnGbInq7uOtik7ax1X9 4jYN0qML2zoXEtqcJrzjOG+3ZGyjlreYQfeNUVlZKVYS+pHY8Gqw6VEs7BBwfE3emD u0+G8kdd5qZYxvGirYrfN8Exhew6hWishsmGhr34=
Message-ID: <8ccdcce6-2be7-6eeb-a816-0b2e36eabd20@lear.ch>
Date: Tue, 04 Jan 2022 17:28:20 +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: <163943295026.14606.17568188352214673806@ietfa.amsl.com> <AM7PR07MB62488F5123CDBDBBA79100CBA0759@AM7PR07MB6248.eurprd07.prod.outlook.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <AM7PR07MB62488F5123CDBDBBA79100CBA0759@AM7PR07MB6248.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------rIOox3s0UYUNHU0Zw07lyPIm"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/B3Xej4523eUajbppJlIcXiWUKxQ>
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 16:28:32 -0000

Hi Tom,

Thanks for your review.  Please see below.

On 14.12.21 11:15, tom petch wrote:
> From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Russ Housley via Datatracker <noreply@ietf.org>
> Sent: 13 December 2021 22:02
> Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03
>
> Reviewer: Russ Housley
> Review result: Almost Ready
> <snip>
>
>
> 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.
>
> <tp>
>
> You could say that there is no YANG Module as YANG Modules must be registered with IANA and the IANA Considerations in this I-D do not do so:-)
>
> So
> IANA Considerations must register the module as per YANG Guidelines
Added.
>
> Security Considerations must use the template referenced by YANG Guidelines

This one's a little weird, since we are augmenting the MUD module, which 
isn't intended to be retrieved via NETCONF, and nothing here is intended 
to be writeable.  I could add read-only to all of this stuff.


>
> The title in the revision reference clause bears little relationship to that of the I-D
Corrected.
>
> YANG prefix must be unique and should be easy to use; I think that 'mud-transparency' is about 12 characters longer than I would class as easy to use (e.g. mudtx)
Sold.
>
> URL is insecure and to an obsolete web site (tools)
>
> No mention of NMDA or lack of support thereof

Text welcome for this.


>
> Lots of abbreviations not expanded on first use
>
> In our modern pageless format, Section one would be easier to refer to with more subsections such as one for terminology with expanded abbreviations

Generally we should expand abbreviations on first use.  I will clean 
those up.


>
> Why have a grouping and a uses which for me makes the module harder to understand?  It is not as if this grouping is going to be imported in lots of places AFAICT.

It may.  That is why it's a grouping.

Again, thanks for the review.

Eliot