Next in thread →
Next in month →
Re: [openc2] RE: EXT :[openc2] Updates to SBOM sharing draft
Dave, Duncan, I looked it up for you. WGLC is "a Last Call within the working group (conducted over the working group's email list) before a document is passed on to the IESG for consideration." Hope that helps. On Fri, Jul 9, 2021 at 9:51 AM Lemire, Dave (HII-TSD) <> wrote: Iâm guessing that WGLC is an IETF process term, Iâve got no idea what it means. More specifics on what they mean by us âcatch[ing] upâ would also be helpful. Who is Eliot Lear talking to?  Do we know what IETF WG / charter this is under? And their plans for progressing what appears to be an ID to an RFC?  Dave  David Lemire IA Systems Engineer Technical Solutions 302 Sentinel Drive | Annapolis Junction, MD 20701 Work (301)Â575-5190 | MobileÂ(240)Â938-9350  From: [mailto:] On Behalf Of duncan sfractal.com Sent: Friday, July 9, 2021 9:05 AM To: TC OpenC2 () <>; David Kemp <> Cc: Eliot Lear (elear) <> Subject: EXT :[openc2] Updates to SBOM sharing draft  CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.  IETF has an RFC that references using OpenC2. Attached is some work circulated to the SBOM crowd.  According to IETF gurus we need to : âOpenC2 needs to catch up to this work if they want to remain after WGLC (themâs the rules). Iâve reinitiated a discussion with those guys.â Iâm not sure what the means but we should do it promptly. Dave K (or L or anyone else) Iâd appreciate help in doing this.  iPhone, iTypo, iApologize Duncan  From: ntia-sbom-framing-bounces+duncan= <ntia-sbom-framing-bounces+duncan=> on behalf of Eliot Lear via ntia-sbom-framing <> Sent: Friday, July 9, 2021 8:06 AM To: ntia-sbom-framing Cc: Rose, Scott W. Subject: Re: [ntia-sbom-framing] Updates to SBOM sharing draft  This time with the draft attached.  On 9 Jul 2021, at 13:57, Eliot Lear <> wrote:  Hi everyone,  As discussed, Scott and I have updated the SBOM sharing draft. As agreed, it handles VEX and SBOMs independently. We need to get this posted by Monday for the draft deadline. A few of the more salient points:  The intro is rewritten a bit to make clear what the key questions are. We donât focus on licensing in this draft, though there is one sentence about them in formats and format neutrality. There are two independent âchoicesâ in terms of how the information is retrieved- one for SBOMs and one for VEXes. Each are roughly speaking the same. Each maintains format neutrality. There is also some text in there about what if the VEX and the SBOM file are the same. Thatâs to address (obliquely) CycloneDX. We managed to write the entire draft without using the term âVEXâ. OpenC2 needs to catch up to this work if they want to remain after WGLC (themâs the rules). Iâve reinitiated a discussion with those guys. Weâve taken Patâs feedback to create separate well-known suffixes rather than to establish a tree. Iâve updated https://mudmaker.org/test [mudmaker.org]Âwith a version that does All Of This.  One question is just whether it should ever be expected that vulnerability information be kept on the box. That seems like a stretch, even though the draft supports it.  Please see attached, and you can view the source atÂhttps://github.com/elear/mud-sbom/tree/vex [github.com]. This will probably get merged over the weekend into the âmasterâ branch (which at some point will be renamed âmainâ).  Eliot -- ChetÂEnsign Chief Technical Community Steward OASIS Open  +1 201-341-1393 www.oasis-open.org
Next in thread →
Next in month →