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

[Dick Brooks]

Also, regarding:
> 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.

In practice today, consumers are indeed retrieving vulnerability information 
directly from the vendor endpoint where SBOM's are being distributed. SBOM 
Vulnerability Disclosure Reports (VDR) can update independently from an SBOM, 
but remain at a given URL for download. An example of this method is available 
online using the AWS client software for demonstration only:

https://github.com/rjb4standards/REA-Products/tree/master/C-SCRM-Use-Case

AWS-CLI SBOM: 
https://raw.githubusercontent.com/rjb4standards/REA-Products/master/C-SCRM-Use-Case/AWS_SBOM.spdx
 
AWS-CLI VDR:  
https://raw.githubusercontent.com/rjb4standards/REA-Products/master/C-SCRM-Use-Case/AWSCLIVDR.xml
 

FYI: VEX is a different form of vulnerability disclosure, reporting CVE info on 
a product level, i.e. Log4j, whereas the SBOM VDR reports CVE's at the SBOM 
component level. These are not competitive offerings, they are complementary 
offerings.

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-Original Message-
From: OPSAWG  On Behalf Of Eliot Lear
Sent: Tuesday, January 4, 2022 11:17 AM
To: Russ Housley ; gen-...@ietf.org
Cc: draft-ietf-opsawg-sbom-access@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

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 theseobjects.



>
>
> 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



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

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

[Eliot Lear]

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
.

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




OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

[Russ Housley via Datatracker]

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
.

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.



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