[yang-doctors] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02
Ebben Aries via Datatracker <noreply@ietf.org> Sat, 02 October 2021 23:15 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: yang-doctors@ietf.org
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C70C73A0804; Sat, 2 Oct 2021 16:15:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ebben Aries via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-opsawg-sbom-access.all@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163321652671.24319.2544349921956875817@ietfa.amsl.com>
Reply-To: Ebben Aries <exa@juniper.net>
Date: Sat, 02 Oct 2021 16:15:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/Yo55mOLONFUsz1YT4G4089jfOCA>
Subject: [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Oct 2021 23:15:28 -0000
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
- [yang-doctors] Yangdoctors early review of draft-… Ebben Aries via Datatracker
- Re: [yang-doctors] [OPSAWG] Yangdoctors early rev… Eliot Lear
- Re: [yang-doctors] [OPSAWG] Yangdoctors early rev… Joe Clarke (jclarke)
- Re: [yang-doctors] [OPSAWG] Yangdoctors early rev… Eliot Lear
- Re: [yang-doctors] [OPSAWG] Yangdoctors early rev… Dick Brooks