Subject: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-sbom-access-05

From: Henk Birkholz <[email-masked]>
Date: Tue, 12 Apr 2022 13:15:36 +0200

Dear OPSAWG members,

this email starts a three week period for a Working Group Last Call of

 > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/

ending on Wednesday, April 27th.

The authors believe the Internet-Draft is ready for a WGLC. The draft 
has been discussed at meetings, as well as on the list, and review 
feedback has been incorporated in -05.

Please send your comments to the list and your assessment of whether or 
not it is ready to proceed to publication before April 27th.

For the OPSAWG co-chairs,

Henk

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 14 Apr 2022 21:38:51 +0000

A number of comments as a contributor:

* The tree diagram doesn't reference RFC8340 (see RFC8407 Section 3.4)

* The description of the transparency-extension grouping is a tautology.  This is one of my pet peeves.  Can you add more flavor here?

* Replace use of s/w and h/w with software and hardware respectively.

* Would it make sense to further refine your contact leafs to check for the MUST URI schemas?

* Your description for sbom-url and vuln-url are different.  One says statically located URI whereas the other says statically located URL.  I think the latter is correct.

* The type for sbom-local-well-known is an enum.  Would it make sense to make this an identityref so that other schemes may be used in the future?

* When you say "customers" in this document, I think "users" is a better term.

* Your example in Section 5.1 also uses the "ol" extension.  I think you should omit that in this draft for better clarity.

* In your security considerations, I don't grok this text:

In as much as the module itself is
made writeable, this only indicates a change in how to retrieve what
read-only elements.

But it does raise a question: why are these objects read-write?  I'd think they'd be more operational and read-only from a Thing or device.

* Section 8: "review" is misspelled.

Joe

On 4/12/22 07:16, Henk Birkholz wrote:

Dear OPSAWG members,

Henk

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Apr 2022 00:43:53 +0200

Hi Joe,

good points.

I’m not so sure about this one, though:

> On 14. Apr 2022, at 23:38, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
> 

I think it would be good to show how these extensions work together.
(It probably would also be good to spend some explanatory text on this.)

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 15 Apr 2022 02:30:08 +0200

Dear OPSAWG members,

please be aware that I introduced an inconsistency in the recent WGLC 
announcement.

It is actually a period of *three weeks* to get your feedback in. I 
extended the time frame from two weeks due to the Eastern holidays 
occurring all over the EU.

As a result, the deadline to send your comments to the list and your 
assessment of whether or not it is ready to proceed to publication 
effectively is *May 4th* and it is not terminating on April 27th already.

There so no harm though in providing feedback before April 27th! :-) So 
don't stop doing that!

Thanks Tom for pointing that out.

Viele Grüße & a enjoy a inspiring Easter time,

Henk

On 12.04.22 13:15, Henk Birkholz wrote:
> [email-masked]

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 15 Apr 2022 13:40:16 +0000

> (It probably would also be good to spend some explanatory text on this.)

Text would be needed for sure, but that would then necessitate an inform
reference to the OL draft.  And that one is about ready to fall off.  I
like that work, and I'd like to see it expand a bit more from MUD, but
I'm not sure what it's future holds.

Joe

---

From: tom petch <[email-masked]>
Date: Sat, 16 Apr 2022 11:47:46 +0000

From: OPSAWG <[email-masked]> on behalf of Henk Birkholz <[email-masked]>
Sent: 15 April 2022 01:30

<tp>

In the YANG module, abbreviations need expanding - MUD, COAP

All those URI could do with a reference perhaps to the IANA registry which then gives links to RFC for them

COAP COAPS ditto and probably HTTP HTTPS given the spate of new RFC thereof

contact details are out of date https://datatracker

YANG namespace needs registering with IANA

Tom Petch

Dear OPSAWG members,

Henk

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Apr 2022 06:58:06 -0400

Hi Joe and others,

Thanks for your comments.  At least one of the co-authors is traveling 
about.  It will be a little more than a week before I reply in substance.

Eliot

On 14.04.22 17:38, Joe Clarke (jclarke) wrote:
> * The description of the transparency-extension grouping is a 
> tautology.  This is one of my pet peeves.  Can you add more flavor here?
>
> * Your description for sbom-url and vuln-url are different.  One says 
> statically located URI whereas the other says statically located URL.  
> I think the latter is correct.
>
> * The type for sbom-local-well-known is an enum.  Would it make sense 
> to make this an identityref so that other schemes may be used in the 
> future?
>
> * Your example in Section 5.1 also uses the "ol" extension.  I think 
> you should omit that in this draft for better clarity.
>
> But it does raise a question: why are these objects read-write? I'd 
> think they'd be more operational and read-only from a Thing or device.
>