Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

Hi Med, Thanks.  The impetus for this work is that some think that MUD files need a license statement.  As such, the augment should be sufficient in this case; but I will raise the question in netmod. As to this: On 06.05.2024 11:16, mohamed.boucad...@orange.com wrote: 2. I know that you

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

Michael, On 28.04.2024 23:46, Michael Richardson wrote: Eliot Lear wrote: > consideration.  Michael, I don't think it's necessary in this case to > update 8520 because we *are* indeed creating a new namespace.  However, > this wasn't properly indicated in the draft.

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

/arch/msg/opsawg/OlkjFOk55hB-29UG4FQaNbunXTY/ but still see the same issues in 2024. Putting aside the list/leaf-list thing, the other points are straightforward such as fixing a json example. Cheers, Med -Message d'origine- De : OPSAWG De la part de Eliot Lear Envoyé : lundi 22 avril

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

.org wrote: > Internet-Draft draft-ietf-opsawg-ol-05.txt is now available. It is a work item > of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. > Title: Ownership and licensing statements in YANG > Authors: Eliot Lear > Carsten Borma

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

s and Management Area Working Group (OPSAWG) WG of the IETF. > Title: Ownership and licensing statements in YANG > Authors: Eliot Lear > Carsten Bormann > Name:draft-ietf-opsawg-ol-05.txt > Pages: 8 > Dates: 2024-04-18 >

Re: [OPSAWG] Deb Cooley's Discuss on draft-ietf-opsawg-mud-acceptable-urls-11: (with DISCUSS and COMMENT)

, 2024 at 8:26 AM Eliot Lear wrote: Hi Deb, On 04.04.2024 13:45, Deb Cooley via Datatracker wrote: > > Shepherd writeup:  It would be nice to enumerate the manufacturers that have > implemented this concept.  The link to 'https://mudmaker.org' causes m

Re: [OPSAWG] Deb Cooley's Discuss on draft-ietf-opsawg-mud-acceptable-urls-11: (with DISCUSS and COMMENT)

Hi Deb, On 04.04.2024 13:45, Deb Cooley via Datatracker wrote: Shepherd writeup: It would be nice to enumerate the manufacturers that have implemented this concept. The link to 'https://mudmaker.org' causes my browser to throw big flashy warning signs. When I click through them, it tells me

Re: [OPSAWG] Last Call Review of draft-ietf-opsawg-mud-acceptable-urls-10

On 28.02.2024 20:16, Christian Huitema wrote: I am not entirely convinced. This looks like keeping logs, keeping them online, and accessing them in real-time. That can be challenging in many environments. The data we are talking about scales to number of devices X number of MUD-URL

Re: [OPSAWG] Last Call Review of draft-ietf-opsawg-mud-acceptable-urls-10

Hi Christian, Just on this point: On 28.02.2024 10:05, Christian Huitema wrote: How do you know that a specific URL is a rollback? It looks easy when the example say "revision1" and "revision2", but I am sure there are cases where you cannot tell by just looking at the URL. You may be able

Re: [OPSAWG] Last Call Review of draft-ietf-opsawg-mud-acceptable-urls-10

Hi Christian and thanks for another good read of another MUD document.  You've largely summarized the situation well, taking into account what RFC 8520 states. I want to note that your comments about detached signatures were specified in RFC 8520.  This draft tries to work within that

Re: [OPSAWG] [Technical Errata Reported] RFC8520 (7819)

I agree. This erratum should be verified. > On Feb 23, 2024, at 18:48, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8520, > "Manufacturer Usage Description Specification". > > -- > You may review the report below and

Re: [OPSAWG] advancing PCAP drafts

On 31.01.2024 15:10, Michael Richardson wrote: I don't know if ISE documents can create registries: one ISE told me no. See RFC 8726.  DR not permitted unless it's a required sub-registry tied to a requested allocation. Eliot OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public

Re: [OPSAWG] advancing PCAP drafts

I'd like to see these docs advance as well.  My only question is whether the pcapng doc should be a Proposed Standard. Eliot On 15.11.2023 10:33, Michael Richardson wrote: Hi, the three PCAP I-Ds have been stable for sometime now. draft-ietf-opsawg-pcap-03- going to Historic.

Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

On 23.10.2023 17:27, Michael Richardson wrote: Maybe someone else can explain it back to me in a better way. The fundamental issue is this: * If you are permitting an IP address in an ACL based on a name in a MUD file, the mapping to that address is valid for the greater of the TTL on

Re: [OPSAWG]  IPR Call for draft-ietf-opsawg-mud-acceptable-urls-06

I’m not aware of any IPR that applies to this draft, other than that which is already disclosed and licensed to developers of RFC8520, and I’m not sure how relevant it is. Eliot > > Forwarded Message > Subject: [OPSAWG]  IPR Call for draft-ietf-opsawg-mud-acceptable-urls-06

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-18.txt

and Management Area Working Group (OPSAWG) WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-18.txt Pages

Re: [OPSAWG] draft-ietf-opsawg-sbom-access

Hi Dick, Thanks for your comments.  Please see below. On 28.04.23 15:13, Dick Brooks wrote: SPDX V 2.3 provides guidance with regard to vulnerability reporting for SBOM's. A NIST Vulnerability Disclosure Report (VDR) is a single file that serves as an attestation showing the vulnerability

[OPSAWG] draft-ietf-opsawg-sbom-access

During the IESG evaluation, I received a query from the AD about using leaf-lists instead of leafs for SBOM and vulnerability data.  Before we publish this document, I think it's probably worth reviewing those nodes. Right now, everything is a leaf.  For SBOMs at least, to me this makes

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-sbom-access-16: (with COMMENT)

Righto.  Thanks for catching that Roman.  I will work with the AD to make sure that gets corrected prior to publication. Eliot On 27.04.23 14:15, Roman Danyliw via Datatracker wrote: Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-sbom-access-16: No Objection

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

Except that Rob suggested that I posted a new draft with the updates, which I have done. Eliot > On 27 Apr 2023, at 07:26, Eliot Lear wrote: > > This, along with all edits in answer to AD commentss, is corrected in the > working copy. I’ll post that update in the next day or so,

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

This, along with all edits in answer to AD commentss, is corrected in the working copy. I’ll post that update in the next day or so, barring new comments from other ADs. Eliot > On 27 Apr 2023, at 00:50, Zaheduzzaman Sarker via Datatracker > wrote: > > Zaheduzzaman Sarker has entered the

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

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

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sbom-access-15: (with DISCUSS and COMMENT)

Hi Roman, On 25.04.23 17:53, Roman Danyliw via Datatracker wrote: Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-sbom-access-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel

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

On 24.04.23 17:05, Carsten Bormann wrote: Please explain — do you really need the obsoleted content of RFC 7231 in addition to that of RFC 9110? Reviewing this, it's probably not necessary since the semantics are stable. Eliot ___ OPSAWG mailing

Re: [OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-sbom-access-15: (with COMMENT)

Hi Eric, On 24.04.23 12:31, Eric Vyncke (evyncke) wrote: Could you be more specific? EV> sure, the paragraph below as a "MUST" while the one before and the one after do not. And, they are all describing 3 methods considered by this I-D. I find it unbalanced, not critical of course. "Using

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

Hi Lars, On 24.04.23 15:51, Lars Eggert via Datatracker wrote: Lars Eggert 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

Re: [OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-sbom-access-15: (with COMMENT)

Thank you Eric, please see below. On 24.04.23 10:53, Éric Vyncke via Datatracker wrote: Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-sbom-access-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-15.txt

the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

to be included, but we can cross that bridge during the IESG review, if needed. Regards, Rob *From:*Eliot Lear *Sent:* 27 February 2023 13:25 *To:* Rob Wilton (rwilton) ; draft-ietf-opsawg-sbom-access@ietf.org *Cc:* opsawg@ietf.org *Subject:* Re: [OPSAWG] AD review of draft-ietf-opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

Rob: I think it's appropriate to accept all of your proposed changes with one caveat: On 07.02.23 14:50, Rob Wilton (rwilton) wrote: Hi Eliot, The only thing that I think that we need to tweak is the security section, where I think that we need to be more explicit that this module is not

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-acceptable-urls-05

+1 ;-) On 04.01.23 19:11, Rose, Scott W. (Fed) wrote: I approve of this document advancing. Preferably as Proposed Standard since it updates RFC 8520. Scott -- Scott Rose, NIST/CTL scott.r...@nist.gov ph: +1-301-975-8439 GVoice: +1-571-249-3671 *From:

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05

Same. On 16.01.23 16:44, Owen Friel (ofriel) wrote: +1, I am supportive of this document progressing. Owen -Original Message- From: Henk Birkholz Sent: Friday 9 December 2022 16:21 To: opsawg Subject: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05 Dear

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

Ok, this is now posted as -13. On 06.01.23 16:28, Eliot Lear wrote: Hi Rob, On 19.12.22 17:25, Rob Wilton (rwilton) wrote: Hi Eliot, Scott, Thanks for this document.  Here is my AD review for draft-ietf-opsawg-sbom-access-12. Moderate level comments: (1) p 3, sec 1.  Introduction

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

Hi Rob, On 19.12.22 17:25, Rob Wilton (rwilton) wrote: Hi Eliot, Scott, Thanks for this document. Here is my AD review for draft-ietf-opsawg-sbom-access-12. Moderate level comments: (1) p 3, sec 1. Introduction To enable application-layer discovery, this memo defines a well-known

Re: [OPSAWG]  WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01

On 31.12.22 16:00, Carsten Bormann wrote: On 2022-12-31, at 13:09, tom petch wrote: The I-D lacks much useful information compared with the tcpdump website which you say this replaces I read Michael’s response as a promise to do the necessary work. (If he doesn’t keep the promise, we can

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-12.txt

: Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-12.txt Pages : 21 Date: 2022-10-09 Abstract

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:

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-11.txt

and Management Area Working Group WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-11.txt Pages

Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-sbom-access-09

> But, I did agree that unconfigured devices which have not been onboarded with > an administrative credential should not answer queries about their SBOM. That I buy and can make clearer. Eliot > ___ OPSAWG mailing list OPSAWG@ietf.org

Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-sbom-access-09

On 29.09.22 18:53, Christian Huitema wrote: On 9/28/2022 12:06 AM, Eliot Lear wrote: Hi Christian, just following up on this: And following up myself. I am looking at the deltas between draft 10 and draft 9, and while it goes in the right direction, I would love to see a bit more work

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt

com Email:d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Eliot Lear Sent: Wednesday, September 28, 2022 8:03 AM To:d...@reliableenergyanalytics.com;opsawg@ietf.org;i-d-annou...@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt

Hi Dick, On 28.09.22 13:49, Dick Brooks wrote: I find this material misleading and incomplete. The title infers the ability to discover and retrieve vulnerability information. However the text of this draft makes clear that retrieval is not supported, ref Page 2: "This memo does not

Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-sbom-access-09

Hi Christian, just following up on this: On 16.09.22 07:45, Eliot Lear wrote: To address your second point first, it helps to keep in mind that what is described in this draft is not a retrieval mechanism but a *discovery* mechanism.  The device does not at all need to offer an SBOM

Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-sbom-access-09

Hi Christian, Thanks for your review.  To summarize: * You are concerned about a lack of a "MUST" for authorization for the information. * You are concerned that a device might need to run a web server. * The use of the term "some network environments" is vague. To address your second

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-09.txt

clues for others to find what I was referring to. Tom Petch Viele Grüße, Henk On 13.09.22 12:26, Eliot Lear wrote: The only change from this version is the pointer to a free version of the SPDX specification. With this, I believe all issues have been addressed. Eliot On 13.09.22 12:24

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-09.txt

. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-08.txt

Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-08.txt Pages : 21 Date: 2022-09-07 Abstract: To improve cybersecurity posture, automation is necessary to locate what software is running

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-07.txt

Hi Tom, On 07.09.22 12:02, tom petch wrote: From: OPSAWG on behalf of Eliot Lear Sent: 02 September 2022 18:03 This addresses Tom Petch's comments. Well, mostly. I do not understand the ISO reference. The URl - 81870 - works and brings up 5962-2021 but what is 19970-2? I get no hits

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt

rgyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Michael Richardson Sent: Friday, September 2, 2022 3:45 PM To: d...@reliableenergyanalytics.com Cc: 'Eliot Lear' ; opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt Dick Brooks wrote

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-07.txt

: Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-07.txt Pages : 21 Date: 2022-09-02 Abstract: To improve

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt

Hi Tom, Just on this one point: On 02.09.22 18:05, tom petch wrote: does 'http' match the pattern 'https?' ? It should.  However, some of the validators have some difficulty on (expr1)|(expr2)|(expr3).* because the .* is applied only to expr3.  So I did make a change.  Draft is posted.

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt

Perfect, Tom.  Thanks! Eliot On 02.09.22 18:05, tom petch wrote: From: OPSAWG on behalf of Eliot Lear Sent: 02 September 2022 13:10 Thank you Henk and chairs. I have a favor to ask participants. Give this document a good read again. Even though we are past WGLC, as an author I would still

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt

. While the secdir review is still in progress, we can make use of that time. For the OPSAWG co-chairs, Henk On 01.09.22 14:11, Eliot Lear wrote: Hi, The intent of this draft was to address all WGLC comments.  I hope that we have.  One major change based on Joe's comments: We moved from enums

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-06.txt

. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-06.txt Pages : 21 Date: 2022-09-01 Abstract

[OPSAWG] draft-ietf-opsawg-sbom-access status

All, The authors of this draft won't be present tomorrow, but we are working on resolving LC comments still.  Please expect an updated draft in the next two weeks or so, as well as commentary explaining the resolution. Eliot OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key

[OPSAWG] draft-ietf-opsawg-sbom-access

Hi Chairs, We've gathered some feedback from a number of sources.  Most of the changes are pretty straight forward.  Some of the YANG changes require a little bit more time to work through, perhaps consulting with some people who have more clue than us.  The authors intend to get together

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-sbom-access-05

Hi Joe, Thanks for your review.  Please see below.  What is listed is what is proposed (my co-author might have some thoughts here). See also the changes in https://github.com/elear/mud-sbom. On 14.04.22 23:38, Joe Clarke (jclarke) wrote: A number of comments as a contributor: * The tree

Re: [OPSAWG]  IPR Call for draft-ietf-opsawg-sbom-access-05

Hi Henk This one: On 01.05.22 19:33, Henk Birkholz wrote: "No, I'm not aware of any IPR that applies to this draft." ;-) Eliot OpenPGP_signature Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-sbom-access-05

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: A number of comments as a contributor: * The tree diagram doesn't

Re: [OPSAWG] IETF 113 Minutes published

Just to follow this up, While we didn't ask for time last week, we would like to see draft-ietf-sbom-access move to WGLC. Eliot On 30.03.22 16:18, Joe Clarke (jclarke) wrote: Thanks to Eliot and Rob (and I believe a few other note takers here and there) we have a set of minutes from our 113

Re: [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03

My apologies.  This should have gone out under my name, not under that of the ISE.  The ISE has no interest in this. Eliot On 28.03.22 21:25, Independent Submissions Editor (Eliot Lear) wrote: I think there are two things going on here. First, there is a need for the controller

Re: [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03

I think there are two things going on here. First, there is a need for the controller to be tightly bound with the resolver.  Thus it is aware of what is returned to the device.  How long the device uses that information should be governed by the upper bound of DNS caching semantics and

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-05.txt

: Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-05.txt Pages : 21 Date: 2022-03-06 Abstract: To improve cybersecurity posture, automation is necessary to locate what software is running

[OPSAWG] some comments on draft-mcr-iot-mud-considerations

Hi everyone, I have given this document a fresh read, and I think there are a few points that need to be drawn out. First, some of this has rather little to do with MUD.  MUD is simply an example mechanism that scales intent of the manufacturer of a device.  One could just as easily read

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-04.txt

item of the Operations and Management Area Working Group WG of the IETF. Title : Discovering and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg

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

Hi Nicolas: Thank you for your review. On 20.12.21 02:16, Niclas Comstedt via Datatracker wrote: - I realize the point about vulnerabilities info having a different change rate than software but why not include support to retrieve vulnerabilities from the endpoint? Part of this question is

Re: [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03

On 04.01.22 18:02, tom petch wrote: *From:* Eliot Lear *Sent:* Tuesday, January 04, 2022 16:28 *To:* tom petch; gen-...@ietf.org; Russ Housley *Cc:* draft-ietf-opsawg-sbom-access@ietf.org; opsawg@ietf.org *Subject:* Re: [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03 Hi

Re: [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03

Hi Tom, Thanks for your review.  Please see below. On 14.12.21 11:15, tom petch wrote: From: OPSAWG on behalf of Russ Housley via Datatracker Sent: 13 December 2021 22:02 Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03 Reviewer: Russ Housley Review result: Almost

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

Re: [OPSAWG] Draft 112 Agenda posted

familiarize yourself with https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/ ahead of time so you're ready to participate and/or present. Make sure you've registered and have a working DataTracker account. In the past few meetings, Eliot Lear and Rob Wilton have been excellent

Re: [OPSAWG]  WG Adoption Call for draft-tuexen-opsawg-pcapng-03

I support the adoption of this draft as well as the pcap draft. My presumption is that we will memorialize pcap and further work might be done on pcapng. On 21.10.21 21:51, Michael Richardson wrote: Carsten Bormann wrote: > While the original pcap format has held up very well over time,

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-03.txt

and Retrieving Software Transparency and Vulnerability Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-03.txt Pages : 19 Date: 2021-10-24 Abstract: To improve

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02

Hi Ebben and thanks for your review.  Please see below: On 03.10.21 01:15, Ebben Aries via Datatracker wrote: Reviewer: Ebben Aries Review result: Almost Ready Apologies for not turning this around sooner. Structure wise, the model is fairly sound. Most of the comments below are either

Re: [OPSAWG]  WG Adoption Call for draft-gharris-opsawg-pcap-02

+1. On 20.10.21 22:44, Carsten Bormann wrote: On 2021-10-20, at 22:22, Henk Birkholz wrote: this email *extends* the ongoing call for Working Group Adoption on https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until *Sunday, October 24th*. I believe WG time spent to get an

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02

Ebben, Thank you VERY much for your thorough review.  We will respond and update the draft in due course. Eliot On 03.10.21 01:15, Ebben Aries via Datatracker wrote: Reviewer: Ebben Aries Review result: Almost Ready Apologies for not turning this around sooner. Structure wise, the model

Re: [OPSAWG] Review of draft-lear-opsawg-ol

Hi Joe, I could totally turn ol inside out and make it a standalone module that the MUD augmentation just includes.  Is that something people would prefer? Eliot On 04.08.21 16:56, Joe Clarke (jclarke) wrote: I had a read through draft-lear-opsawg-ol. I find the concept of adding owner and

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

I think the deployments also have to be somewhat forgiving in terms of maintaining an ACL some period beyond TTL.  It would make a good paper to understand just how much. On 15.07.21 23:02, Michael Richardson wrote: Eliot Lear wrote: > What is and is not a good idea is highly context

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

What is and is not a good idea is highly contextual in this case.  The network CAN provide a level of protection to limit attacks on devices, but it can only do so if it knows who that device wants to talk to.  There is no magic here.  Either the bindings can be established or they can't.

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

> Those failures will happen with or without MUD. Please explain: how do we see inconsistent application of DNS based rules without MUD? What I meant in context was that there could be NAT binding timeouts and the like, but there are systems out there that do keep context based on

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

The key issue is that the new query and resolution has to get picked up by the network management system.  So long as that happens, then life is good.  This means that the resolver needs to be integrated with the MUD manager, but also that the IoT device should also be careful to observe

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-02.txt

Information Authors : Eliot Lear Scott Rose Filename: draft-ietf-opsawg-sbom-access-02.txt Pages : 20 Date: 2021-07-09 Abstract: To improve cybersecurity posture, automation is necessary to locate

Re: [OPSAWG] Call for presentation

Tianran, May I please have one 10 minute slot for draft-ietf-opsawg-sbom-access and one 5 minute slot for draft-lear-opsawg-ol? Both may require a moment of discussion, and I am asking for WG adoption of the latter. Eliot On 01.07.21 09:50, Tianran Zhou wrote: Hi WG, The OPSAWG meeting

[OPSAWG] draft-ietf-opsawg-sbom-access and VEX/CSAF

Hi! We had started a discussion about having vulnerability information made available alongside SBOM information in the draft.  In the last part of this discussion, people became concerned that the two concepts would become intermixed.  They are, to be sure, related, but one can be provided

Re: [OPSAWG] RADIUS Extensions for Encrypted DNS

I don't think this is the right approach.  I would rather see the information provided in an EAP method, so that DHCP can be removed entirely from the equation.  Otherwise we have multiple, disparate, security models in play to trust the information. Eliot On 04.06.21 15:00, Alan DeKok

Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

On 04.06.21 13:50, mohamed.boucad...@orange.com wrote: Re-, It is also ours as participants, Carsten. If you really want to make sure that extension is considered by a MUD implementer (and this is really about the augment thing), you can consider defining version 2 of the mud module in the

Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

On 04.06.21 12:12, Carsten Bormann wrote: On 4. Jun 2021, at 11:34, > > wrote: What I'm really concerned about is consistent use of the "update" header. That’s the IESG’s job — above my paygrade :-) What I’m concerned

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

*To: *Hassan Habibi Gharakheili *Cc: *Eliot Lear , opsawg@ietf.org *Subject: *Re: [OPSAWG] Source attribution in MUD files (RFC 8520) On 2021-05-22, at 03:00, Hassan Habibi Gharakheili wrote: > > If I understood correctly, the two statements (you mentioned below) are expected to be incl

Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

On 30.05.21 00:20, Michael Richardson wrote: Eliot Lear wrote: > So this raises an interesting question, which is probably more > appropriate for RATS.  What information should be shared with whom and > how?  The voucher is shipped in the clear without much prompting

Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

doesn't take a position on the subject, other than to allow for the notion that some requests *may* need to be authenticated. Eliot On 29.05.21 00:12, Michael Richardson wrote: Eliot Lear wrote: > This having been said, I think you may be applying the right policy at > the wron

Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

Toerless, Feel free to come up with whatever work flows you want. However...   I'm less fine with is creating a new endpoint to retrieve the exact same information.  The magic you want to implement, so far as I can tell, is entirely in the authorization model and that is orthogonal to the

Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

:59:53PM +0200, Eliot Lear wrote: On 28.05.21 17:31, Toerless Eckert wrote: On Fri, May 28, 2021 at 07:24:45AM +0200, Eliot Lear wrote: Explain to me how this work flow would allow for the registrar to decide whether to and/or what certificate to give to the pledge via EST based on SBOM

Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

On 28.05.21 17:31, Toerless Eckert wrote: On Fri, May 28, 2021 at 07:24:45AM +0200, Eliot Lear wrote: Explain to me how this work flow would allow for the registrar to decide whether to and/or what certificate to give to the pledge via EST based on SBOM information. Well, in that case

Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

Hi Tom, On 28.05.21 17:52, tom petch wrote: Well-formed I-D should explain how they update what they claim to update. This one does, sort of, in the Introduction. What is missing is text such as Section.x.y of RFC8520 is updated to include the following paragraph "Those generating MUD

Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

Hi Med, Thanks for your comments.  Please see below. On 28.05.21 11:18, mohamed.boucad...@orange.com wrote: Hi Eliot, all, This extension makes sense to me. I support it to be adopted in opsawg (where 8520 was developed). That's said, this draft does not update 8520. I suggest to remove

Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

often the significant aspects of that are deducible from the X520SerialNumber for good vendors. Cheers Toerless In-Reply-To: <983c17c3-1c0b-9626-4009-bb442ad28...@lear.ch> On Tue, May 25, 2021 at 03:01:14PM +0200, Eliot Lear wrote: Hi, For those of you who don???t know, Common Security Adv

Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

On 27.05.21 05:33, Michael Richardson wrote: Eliot Lear wrote: > For those of you who don’t know, Common Security Advisory Format (CSAF) > is an evolution on Common Vulnerability Reporting Framework.  Such an > object could easily be delivered with an SBOM.  It has a

Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

26, 2021 at 4:39 PM Eliot Lear <mailto:l...@lear.ch>> wrote: Hi Patrick, Snipping to the meat: On 26.05.21 05:08, Patrick Dwyer wrote: True, although I wouldn't expect a CSAF reference in isolation in this case. I think different manufacturers will hold

Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

Hi Patrick, Snipping to the meat: On 26.05.21 05:08, Patrick Dwyer wrote: True, although I wouldn't expect a CSAF reference in isolation in this case. I think different manufacturers will hold different points of view on this.  Some may simply be required to release an SBOM based on some

Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

On 25.05.21 15:51, Patrick Dwyer wrote: Hi Eliot, A well-known URI is just one way of enabling delivery of an SBOM. YYyyyes...  but did you mean CSAF above? Because of this, I think suppliers will need to include the CSAF location in the SBOM itself. That would tightly bind the CSAF to

[OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

Hi, For those of you who don’t know, Common Security Advisory Format (CSAF) is an evolution on Common Vulnerability Reporting Framework.  Such an object could easily be delivered with an SBOM.  It has a slightly different characteristic in terms of update frequency.  CSAF changes may happen

  1   2   3   4   >