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

[tom petch <[e-mail]>]

From: Eliot Lear
Sent: Tuesday, January 04, 2022 16:28
To: tom petch; [e-mail]; Russ Housley
Cc: [e-mail]; [e-mail]
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 <[e-mail]> on behalf of Russ Housley via Datatracker <[e-mail]>
> 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