Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02
Eliot Lear <lear@lear.ch> Sun, 03 October 2021 08:48 UTC
Return-Path: <lear@lear.ch>
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 90D023A0AA9; Sun, 3 Oct 2021 01:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level:
X-Spam-Status: No, score=-0.891 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.001, 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 TSwrZWje3_fd; Sun, 3 Oct 2021 01:48:20 -0700 (PDT)
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 95E853A0BCD; Sun, 3 Oct 2021 01:48:15 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1938mARI3897912 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 3 Oct 2021 10:48:11 +0200
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=1633250893; bh=dq4J4mWpcZl7j8EP0pq32O8NEdSbum9Dux75mCF0rUQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=sSVAar/NEsk1ch63l08mJbPvx/OoVmJdntVV6JDoGULMHhzZnadzpZqvvwvdy8FoN Vw7A/W2626t8IC1li7PqipsQYyl8ADO29LG1OUpRBZy2grU1iZ4Lhbd+CLpYhXQ8fv 3kDMYsdvDwgHKFnjophLQiCW3St5H9JTqWo0ckvg=
To: Ebben Aries <exa@juniper.net>
Cc: draft-ietf-opsawg-sbom-access.all@ietf.org, opsawg@ietf.org, Scott Rose <scott.rose@nist.gov>, yang-doctors@ietf.org
References: <163321652671.24319.2544349921956875817@ietfa.amsl.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <611de2bd-d376-643f-1493-7067c560390e@lear.ch>
Date: Sun, 03 Oct 2021 10:48:10 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <163321652671.24319.2544349921956875817@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="88x9KUnJZrpQmpve77ld183SRsE1eZPYn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/G60134awlaIgYdlD8x75JoKmJno>
Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 03 Oct 2021 08:48:27 -0000
Ebben, Thank you VERY much for your thorough review. We will respond and update the draft in due course. Eliot On 03.10.21 01:15, Ebben Aries via Datatracker wrote: > Reviewer: Ebben Aries > Review result: Almost Ready > > Apologies for not turning this around sooner. Structure wise, the model is > fairly sound. Most of the comments below are either nits/wording, slight > adjustments and questions/clarifications. > > 1 module in this draft: > - ietf-mud-transparency@2021-07-06.yang > > No YANG compiler errors or warnings (pyang 2.5.0, yanglint 2.0.88, confdc 7.2.3.4) > - L#364: CODE BEGINS : filename must be defined on same line for tools such as > rfcstrip to correctly parse the module contents > > Module ietf-mud-transparency@2021-07-06.yang: > - import `ietf-inet-types` should reference RFC 6991 per > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7 > - import `ietf-mud` should reference RFC 8520 per > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7 > - L#016 - Minor nit: looks like L#17 should be moved up here > - L#018-020 - Minor nit: adjust email address formatting per > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C > - The type and enum members are identically defined for > `sbom-local-well-known` and `vuln-local-well-known`. Is this something you > can leverage by using a typedef or a grouping or is there intention to keep > these separately defined? > - When retrieving say an 'sbom' from the device, is it assumed that it be via > `sbom-local-well-known`? What if it is necessary to host this on an > alternate port for one of the communication protocols chosen? Would this > scenario then best use `sbom-url` to define a static URI? (Same question > applies to vuln as well) > - Independent of the answer to the above question, is `cloud` the best choice > or wording for the other case statement under the retrieval method choices? > > It seems to be that we have 3 cases for sbom/vuln retrieval methods which > correspond to the draft wording at L#176-180 which seems to not pair > identically. > > * on devices themselves: Could be /.well-known/ or a static URI could it > not? > * on a website: Static URI only > * out-of-band: Static URI only - should this leaf be named something closer > to that vs. 'contact'? > > General comments on the draft/modules: > - L#0021: s/provide access this/provide access to this/ > - L#0117: s/bills of material/bill of materials/ > - L#0627: JSON example needs correct prefix for the augment > `ietf-mud-transparency:transparency` > - L#0941: s/not be/not been/ > - L#0961: s/authoration/authorization/ > - Since `ietf-mud-transparency` imports `ietf-inet-types`, a normative > reference must be added per > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9 > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >
- [OPSAWG] Yangdoctors early review of draft-ietf-o… Ebben Aries via Datatracker
- Re: [OPSAWG] Yangdoctors early review of draft-ie… Eliot Lear
- Re: [OPSAWG] [yang-doctors] Yangdoctors early rev… Joe Clarke (jclarke)
- Re: [OPSAWG] Yangdoctors early review of draft-ie… Eliot Lear
- Re: [OPSAWG] Yangdoctors early review of draft-ie… Dick Brooks