From: Eliot Lear
Sent: Tuesday, January 04, 2022 16:28
To: tom petch; gen-...@ietf.org; Russ Housley
Cc: draft-ietf-opsawg-sbom-access....@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03

Hi Tom,

Thanks for your review.  Please see below.

<tp>

On security, YANG Guidelines, RFC8407, says that there MUST be Security 
Considerations and that they MUST be patterned on the latest template.  No 
exemption for read only or grouping only!

For example, I note that you refer to HTTP whereas the template only uses 
HTTPS, underpinned by TLS.  It is fine to say that the data is read only.  It 
is also fine to say that the data is in the public domain and so privacy is not 
a concern.  I have not yet seen a statement in an I-D that the integrity of the 
data is of no concern and so corruption by an evil actor e.g. by using HTTP 
insead of HTTPS is not a concern but perhaps that day will come:-)

Whatever, I think that a number of AD will be looking for Security 
Considerations based on the template and you will be asked why not and I see 
that as easier to fix now rather than at IESG Review.

Tom Petch

On 14.12.21 11:15, tom petch wrote:
> From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Russ Housley via 
> Datatracker <nore...@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


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to