Re: [Gen-art] [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

[Eliot Lear <[e-mail]>]

Hi Russ,

And thanks for your review. Please see below.

On 13.12.21 23:02, Russ Housley via Datatracker wrote:
> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-opsawg-sbom-access-03
> Reviewer: Russ Housley
> Review Date: 2021-12-13
> IETF LC End Date: unknown
> IESG Telechat date: unknown
>
> Summary: Almost Ready
>
>
> 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.
>
>
> Major Concerns:
>
> Section 1 says:
>
>     To satisfy these two key use cases, objects may be found in one of
>     three ways:
>
> This lead to some confusion for me.  Earlier in the document, it says:
>
>     This specification does not allow for vulnerability information to be
>     retrieved directly from the endpoint.  That's because vulnerability
>     information changes occur at different rates to software updates.
>
> After thinking about it, I realized that the objects do not include
> vulnerability information, but pointers to obtain vulnerability
> information.  Please reword to others do not need to give it the
> same amount of thought.

What I propose is first the following early on in the introduction:

> This memo doesn't specify the format of  this information, but rather
> only how to locate and retrieve these    objects.



>
>
> Minor Concerns:
>
> Section 1, first sentence: The reference to "A number of activities"
> is very vague.  It is not wrong.  Please be more specific, provide
> some references, or drop the vague reference altogether.

It'd be fun to reference an executive order.  Never done that before.

>
> Section 1 says:
>
>     In the second case, when a device does not have an appropriate
>     retrieval interface, but one is directly available from the
>     manufacturer, a URI to that information must be discovered.
>
> s/must/MUST/ ?
>
Sure.


> Nits:
>
> The terms "software" and "firmware" are used with essentially the same
> meaning in this document.  If there is a difference, it needs to be
> explained.  If they are the same in the context of this document, please
> say so.

I've removed the term "firmware".

> Abstract, last sentence: please add "(MUD)" and also a pointer to
> RFC 8520.

I think this got rewritten.  Let me know when you see the update.

Thanks again for the review.

    Eliot