Re: [OPSAWG] Warren Kumari's No Objection on draft-ietf-opsawg-sbom-access-15: (with COMMENT)

[Eliot Lear <[e-mail]>]

On 26.04.23 02:32, Warren Kumari via Datatracker wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-opsawg-sbom-access-15: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for this document, and also much thanks to Henk for the OpsDir review
> -
> https://datatracker.ietf.org/doc/review-ietf-opsawg-sbom-access-03-opsdir-early-comstedt-2021-12-19/
>
> I found it an easy read, and only have a few nits to offer:
>
> 1: "A number of activities have been working to improve visibility to
>     what software is running on a system, and what vulnerabilities that
>     software may have[EO2021]."
> Missing space before the [EO2021] reference.

Hmm...  I go both ways on that.

>
> 2: "... two classes of questions *at scale*:"
> I think that you should drop the "emphasis" - I really don't think that it
> helps readability, and looks "odd". I often use this form for emphasis, but I
> really don't think that it should be used in an RFC.

You are the second person to complain about that text.  Expanded on what 
that means.

>
> 3: "Examples of these interfaces might be an HTTP [RFC7231],[RFC9110], or COAP
> [RFC7252] endpoint for retrieval." Missing space after [RFC7231] -- hey, I
> *did* mention that this is all nits (and also that I *emphasize text*).

Ok.


>
> 4: "Using the second method, 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." I don't really understand the
> uppercase MUST here; it's unclear who / what the MUST is directed at.

Removed per earlier discussion.


>
> 5: "To address either risk, any change in a URL, and in particular to the
> authority section, should be treated with some suspicion.  One mitigation would
> be to test any cloud-based URL against a reputation service." I don't really
> have any useful text to suggest, but I find the wording of "To address either
> risk, ..., should be treated with some suspicion" to be strange. I don't really
> view treating something with suspicion as addressing a risk. I *do* know what
> you are trying to say, but I don't really think that this accomplishes it. I'm
> also not really sure why the second sentence only views 'cloud-based' URLs as
> different to non-cloud-based ones - why is foo.bar.example.com more or less
> sketchy if it is on AWS then on a physical server? And I think that the
> hand-wavy "check it against some sort of reputation thing" is sufficiently
> underspecified that it's not helpful.

I agree with you about suspicion, but I don't agree with you about 
reputation services.  In fact I would go so far as to say that any 
resolver that can take as input random HTTP and HTTPS URIs should do 
some sort of test with a reputation service.  All browsers do this 
already!  But that's not this document.  In any case, I've rewritten 
this section a bit to also suggest that administrators be given the 
opportunity to approve processing when an origin has changed.  There are 
*legitimate *reasons for such changes, but some caution seems warranted, 
especially to an origin of unknown quality.

>
> Please notes that these really are just intended to be nits / attempts to help
> improve the document; I seem to be having a hard time with my tone in this
> writeup and apologize if it came out as snarky....
>
Thanks for your suggestions.  The document is much improved!

Eliot