Re: [OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11
Elliot:
The suggested changes all look good, thank for clarification and addressing my
comments, I will update document shepherd review to reflect the current
implementation status.
-Qin
发件人: Eliot Lear [mailto:l...@lear.ch]
发送时间: 2022年10月9日 20:19
收件人: Qin Wu ; opsawg
抄送: Eliot Lear ; draft-ietf-opsawg-sbom-acc...@ietf.org
主题: Re: [OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11
Hi Qin,
Thanks for your review. Please see below.
On 08.10.22 11:27, Qin Wu wrote:
Hi, authors:
I have read the latest version of this draft, it is well written, thank for
that.
Here is the identified minor issues during document shepherd review of
draft-ietf-opsawg-sbom-access-11:
1. Abstract said:
“
It may optionally be discovered through manufacturer usage descriptions.
”
[Qin] This sentence is not clear. Are you saying MUD extensions transparency
can be discovered using extensions defined in section 3.9 of RFC8520?
Or software transparency and vulnerability information can be discovered by
using ACL example defined in section 5.4 of this draft? I assume it is the
latter. Please clarify.
Ok, I propose the following change:
OLD:
This memo specifies a model to provide access to this information. It
may optionally be discovered through manufacturer usage descriptions.
NEW:
This memo extends the MUD YANG model to provide the locations of software
bills of materials and to vulnerability information.
2. Section 1 said:
“
The mechanisms specified in this document are meant to satisfy
several use cases:
* A network-layer management system retrieving information from an
IoT device as part of its ongoing lifecycle. Such devices may or
may not have query interfaces available.
”
[Qin] How many use cases do we specify here? I believe it is two, how about be
specific about the number of use cases here, s/several use cases/the following
two use cases
Ok
3. Section 1 said:
“ In the first case, devices will have interfaces that permit direct
retrieval. Examples of these interfaces might be an HTTP
[RFC9110<https://datatracker.ietf.org/doc/html/rfc9110>],
or COAP [RFC7252<https://datatracker.ietf.org/doc/html/rfc7252>] endpoint
for retrieval. There may also be private
interfaces as well.
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.
In the third case, a supplier may wish to make an SBOM or
vulnerability information available under certain circumstances, and
may need to individually evaluate requests. The result of that
evaluation might be the SBOM or vulnerability itself or a restricted
”
[Qin] I believe the first case, the second case, the third case are
corresponding to three ways to discover object instead of two key use cases
listed in section 1? Therefore there are confusing to be introduced here.
I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method
Ok. I changed the word "In" to "Using", but otherwise agree.
4. Section 1.1
[Qin] s/in either/either in
Ok
5. Section 1.1 said:
“ The MUD semantics provide a way for manufacturers
to control how often tooling should check for those changes through
the cache-validity node. “
[Qin] Can you provide a reference section in RFC8520 about such MUD semantics.
I have changed this to "MUD's cache-validity node provides a way..."
For your information, this is Section 3.5 of 8520.
6. Section 3 N.B.
[Qin] What N.B. stands for? Can you provide a reference or change in other
words.
N.B. is a commonly used Latin abbreviation for "nota bene" or "note well". It
falls into the class of i.e, and e.g.
7. Section 5.4 said:
“
5.4<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11#section-5.4>.
With ACLS
Finally, here is a complete example where the device provides SBOM
and vulnerability information, as well as access-control information.
{
"ietf-mud:mud": {
"mud-version": 1,
"extensions": [
"ol",
"transparency"
], “
[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other words, how
sbom access work together with Ownership and licensing statements in YANG
described in draft-ietf-opsawg-ol-01.
If ‘ol’ extension is needed, I think a informative reference is needed here.
This as discussed within the working group, and the point was made that it is
good to show mud working with unrelated extensions. I would prefer for this
reason not to include an informative reference. Implementations need not
process extensions they do not understand (to do so would require a major re
Re: [OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11
Hi Qin,
Thanks for your review. Please see below.
On 08.10.22 11:27, Qin Wu wrote:
Hi, authors:
I have read the latest version of this draft, it is well written,
thank for that.
Here is the identified minor issues during document shepherd review of
draft-ietf-opsawg-sbom-access-11:
1.Abstract said:
“
It may optionally be discovered through manufacturer usage descriptions.
”
[Qin] This sentence is not clear. Are you saying MUD extensions
transparency can be discovered using extensions defined in section 3.9
of RFC8520?
Or software transparency and vulnerability information can be
discovered by using ACL example defined in section 5.4 of this draft?
I assume it is the latter. Please clarify.
Ok, I propose the following change:
OLD:
This memo specifies a model to provide access to this information. It
may optionally be discovered through manufacturer usage descriptions.
NEW:
This memo extends the MUD YANG model to provide the locations of software
bills of materials and to vulnerability information.
2.Section 1 said:
“
The mechanisms specified in this document are meant to satisfy
several use cases:
* A network-layer management system retrieving information from an
IoT device as part of its ongoing lifecycle. Such devices may or
may not have query interfaces available.
”
[Qin] How many use cases do we specify here? I believe it is two, how
about be specific about the number of use cases here, s/several use
cases/the following two use cases
Ok
3.Section 1 said:
“ In the first case, devices will have interfaces that permit direct
retrieval. Examples of these interfaces might be an HTTP [RFC9110
<https://datatracker.ietf.org/doc/html/rfc9110>],
or COAP [RFC7252 <https://datatracker.ietf.org/doc/html/rfc7252>]
endpoint for retrieval. There may also be private
interfaces as well.
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.
In the third case, a supplier may wish to make an SBOM or
vulnerability information available under certain circumstances, and
may need to individually evaluate requests. The result of that
evaluation might be the SBOM or vulnerability itself or a restricted
”
[Qin] I believe the first case, the second case, the third case are
corresponding to three ways to discover object instead of two key use
cases listed in section 1? Therefore there are confusing to be
introduced here.
I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method
Ok. I changed the word "In" to "Using", but otherwise agree.
4.Section 1.1
[Qin] s/in either/either in
Ok
5.Section 1.1 said:
“The MUD semantics provide a way for manufacturers
to control how often tooling should check for those changes through
the cache-validity node.“
[Qin] Can you provide a reference section in RFC8520 about such MUD
semantics.
I have changed this to "MUD's cache-validity node provides a way..."
For your information, this is Section 3.5 of 8520.
6.Section 3 N.B.
[Qin] What N.B. stands for? Can you provide a reference or change in
other words.
N.B. is a commonly used Latin abbreviation for "nota bene" or "note
well". It falls into the class of i.e, and e.g.
7.Section 5.4 said:
“*5.4
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11#section-5.4>.
With ACLS*
Finally, here is a complete example where the device provides SBOM
and vulnerability information, as well as access-control information.
{
"ietf-mud:mud": {
"mud-version": 1,
"extensions": [
"ol",
"transparency"
],“
[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other
words, how sbom access work together with Ownership and licensing
statements in YANG described in draft-ietf-opsawg-ol-01.
If ‘ol’ extension is needed, I think a informative reference is needed
here.
This as discussed within the working group, and the point was made that
it is good to show mud working with unrelated extensions. I would
prefer for this reason *not* to include an informative reference.
Implementations need not process extensions they do not understand (to
do so would require a major rev of MUD).
8.Section 6 said:
“N.B., for MUD, the mandatory method of retrieval is TLS.“
[Qin] New fashion of acronym,J
9.Section 6 said:
“
One example may be to issue a certificate to the client for
this purpose after a registration process has taken place. Another
example would involve the use of OAUTH in combination with a
federations of SBOM servers.“
[Qin] I feel there is disconnection between
[OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11
Hi, authors:
I have read the latest version of this draft, it is well written, thank for
that.
Here is the identified minor issues during document shepherd review of
draft-ietf-opsawg-sbom-access-11:
1. Abstract said:
"
It may optionally be discovered through manufacturer usage descriptions.
"
[Qin] This sentence is not clear. Are you saying MUD extensions transparency
can be discovered using extensions defined in section 3.9 of RFC8520?
Or software transparency and vulnerability information can be discovered by
using ACL example defined in section 5.4 of this draft? I assume it is the
latter. Please clarify.
2. Section 1 said:
"
The mechanisms specified in this document are meant to satisfy
several use cases:
* A network-layer management system retrieving information from an
IoT device as part of its ongoing lifecycle. Such devices may or
may not have query interfaces available.
"
[Qin] How many use cases do we specify here? I believe it is two, how about be
specific about the number of use cases here, s/several use cases/the following
two use cases
3. Section 1 said:
" In the first case, devices will have interfaces that permit direct
retrieval. Examples of these interfaces might be an HTTP
[RFC9110<https://datatracker.ietf.org/doc/html/rfc9110>],
or COAP [RFC7252<https://datatracker.ietf.org/doc/html/rfc7252>] endpoint
for retrieval. There may also be private
interfaces as well.
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.
In the third case, a supplier may wish to make an SBOM or
vulnerability information available under certain circumstances, and
may need to individually evaluate requests. The result of that
evaluation might be the SBOM or vulnerability itself or a restricted
"
[Qin] I believe the first case, the second case, the third case are
corresponding to three ways to discover object instead of two key use cases
listed in section 1? Therefore there are confusing to be introduced here.
I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method
4. Section 1.1
[Qin] s/in either/either in
5. Section 1.1 said:
" The MUD semantics provide a way for manufacturers
to control how often tooling should check for those changes through
the cache-validity node. "
[Qin] Can you provide a reference section in RFC8520 about such MUD semantics.
6. Section 3 N.B.
[Qin] What N.B. stands for? Can you provide a reference or change in other
words.
7. Section 5.4 said:
"
5.4<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11#section-5.4>.
With ACLS
Finally, here is a complete example where the device provides SBOM
and vulnerability information, as well as access-control information.
{
"ietf-mud:mud": {
"mud-version": 1,
"extensions": [
"ol",
"transparency"
], "
[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other words, how
sbom access work together with Ownership and licensing statements in YANG
described in draft-ietf-opsawg-ol-01.
If 'ol' extension is needed, I think a informative reference is needed here.
8. Section 6 said:
"N.B., for MUD, the mandatory method of retrieval is TLS. "
[Qin] New fashion of acronym,:)
9. Section 6 said:
"
One example may be to issue a certificate to the client for
this purpose after a registration process has taken place. Another
example would involve the use of OAUTH in combination with a
federations of SBOM servers. "
[Qin] I feel there is disconnection between the fifth sentence and the sixth
sentence in the paragraph 9 . Two examples are provided here, I am wondering
which security risk are addressed by which example?
10. Section 6 said:
"
Vulnerability information is generally made available to such
databases as NIST's National Vulnerability Database. "
[Qin] Do we need to list the Database Name developed by specific entity in the
security section as normative text?
11. Do we have implementation that pertains to this draft?
-Qin
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
