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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
