Russ, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars

> On 14. Dec 2021, at 00:02, Russ Housley via Datatracker <nore...@ietf.org> 
> 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.
> 
> 
> 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.
> 
> 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/ ?
> 
> 
> 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.
> 
> Abstract, last sentence: please add "(MUD)" and also a pointer to
> RFC 8520.
> 
> 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.
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to