Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Hi Henk, > If not, you could update the MUD file to > always point to the latest version If you do so, then the MUD file only adapts to the devices which use the latest version. Actually, you can't guarantee all devices been updated at the same time, so the devices which haven't been updated will be pointed out to the wrong MUD file. draft-ietf-opsawg-mud-acceptable-urls tries to solve this problem by update the MUD URL in some secure ways. Regards & Thanks! Wei Pan > -Original Message- > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Henk > Birkholz > Sent: Friday, April 30, 2021 1:46 AM > To: Eliot Lear > Cc: opsawg > Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access > > I was under the assumption that the thing that is immutable is the MUD > URL right (e.g. if it resides in an IDevID)? Is a specific MUD URL statically > linked to one specific MUD file? If not, you could update the MUD file to > always point to the latest version (first, other linked via that MUD file > maybe) > - or would that defeat some purpose that I am missing or forgot? > > On 29.04.21 19:42, Eliot Lear wrote: > > The MUD file can certainly point to a single version, but if the MUD file is > obtained through some immutable mechanism (device certificate) then the > version info has to come from somewhere else. > > > > Eliot > > > >> On 29 Apr 2021, at 19:39, Henk Birkholz > wrote: > >> > >> Hi Eliot, > >> > >> shouldn't be the MUD file (that is maintained by an appropriate > authority, hopefully) in charge of that? The default SBOM retrievable via > the MUD file could therefore always be the latest version? Older versions > should be discoverable via the MUD file or mechanism around that? > >> > >> Viele Grüße, > >> > >> Henk (no hat) > >> > >> On 29.04.21 19:15, Eliot Lear wrote: > >>> Soo… > >>> I think this is a bit of an interesting question. If an SBOM lives in the > cloud somewhere, and it is associated to a version string, how do you know > which one is the LATEST version? If there is semantic meaning, then the > inventory management system has to be able to determine that. The > simple approach would be for the array to be ordered, but I am not a fan of > these sorts of implicit mechanisms. Another approach would be to index > on a date rather than a version. > >>> Eliot > On 29 Apr 2021, at 17:16, Dick Brooks > wrote: > > Thanks, Eliot. I was just expressing my preferred method of > versioning. As long as the spec doesn't disallow semantic versioning, then > I'm ok. > > Thanks, > > Dick Brooks > > Never trust software, always verify and report! ™ > http://www.reliableenergyanalytics.com > Email: d...@reliableenergyanalytics.com > Tel: +1 978-696-1788 > > -Original Message- > From: Eliot Lear > Sent: Thursday, April 29, 2021 10:25 AM > To: Dick Brooks > Cc: Eliot Lear ; opsawg > > Subject: Re: [OPSAWG] Sbom versioning - > draft-ietf-opawg-sbom-access > > Hi Dick > > When you say semantic versioning, what do you have in mind? > Keep in mind that we want to be neutral to format. > > Eliot > > > On 29 Apr 2021, at 15:30, Dick Brooks > wrote: > > > > Eliot, > > > > Here is the information I use in SAG-PM to discover and retrieve an > SBOM; hope this helps. Version is a must have attribute of the product > definition to retrieve the correct SBOM. > > > > Semantic versioning is preferred: MAJOR.MINOR.PATCH > > > > > >Reliable Energy Analytics > LLC > >SAG-PM (TM) > >1.1.0 > > signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.x > ml.sig">https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml< > /SBOM> > > > https://softwareassuranceguardian.com/sag-pm.zip > > >Y > > > N > > > 2021-04-23T15:57:00 eUTC> > > > > > > > > Thanks, > > > > Dick Brooks > > > > Never trust software, always verify and report! ™ > > http://www.reliableenergyanalytics.com > > Email: d...@reliableenergyanalytics.com > > Tel: +1 978-696-1788 > > > > -Original Message- > > From: OPSAWG On Behalf Of Eliot > Lear > > Sent: Thursday, April 29, 2021 9:15 AM > > To: opsawg > > Subject: [OPSAWG] Sbom versioning - > draft-ietf-opawg-sbom-access > > > > The current draft allows for multiple SBOM versions. The reason > for this is that if a MUD URL is used, and the SBOM is contained on a server > somewhere, one would need to use out of band information to determine > software versions. However, this doesn’t make sense if you are retrieving > the SBOM from the device. Therefore, the model needs to change a bit. > > > > We want a “when” clause somewhere for the version info, but this > introduces an new
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
When you say multiple SBOM versions, do you mean multiple versions of SBOMs that describe the same particular version of software? Or multiple SBOMs for different versions of the same software? On Thu, Apr 29, 2021 at 11:15 PM Eliot Lear wrote: > The current draft allows for multiple SBOM versions. The reason for this > is that if a MUD URL is used, and the SBOM is contained on a server > somewhere, one would need to use out of band information to determine > software versions. However, this doesn’t make sense if you are retrieving > the SBOM from the device. Therefore, the model needs to change a bit. > > We want a “when” clause somewhere for the version info, but this > introduces an new challenge: as currently listed the version-info field is > an index. That has to go. > > So… what I think we want to do is invert the list along the following > lines: > > - choice sbom-type: > case url: > list sboms > leaf version-info > leaf sbom-url > case local-uri: > type empty - the whole thing is constructed using > .well-known/sbom > case contact-info: as before but without versioning > > > Anyway, this is what I am thinking. Thoughts? > > Eliot > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
hi kyle: thanks a million for the review. we have a suply chain problem getting solid reviews these days. > The nits include a need for a thorough editorial pass prior to submission to > the RFC editor. For example: > > * The abstract should probably give the uninformed reader a bit more > information about the overall geofeed ecosystem. * "utterly awesome", "or > whatever", "It would be polite" aha! the style directorate. we'll see how far it gets. maybe even rfced still has a twinkle in their eye. :) > I would also move the privacy discussion from section 2 "Geofeed > Files" to a privacy considerations section, as that is where those > concerned will look for that information. aha. a privacy section is a new fashion of which i was unaware. done. thanks. > This document appears to propose overlapping mechanisms for > establishment of trust in geofeed data. As far as I can tell, geofeed > data may be authenticated both by: > > * RPKI private key signature of a digest of a canonicalized form of the > geofeed data file. * Web PKI via https URL for geofeed data file. not exactly. the web pki has no authority over IP address space ownership. it is only used to authenticate a *pointer* to the geofeed file. and the S in https is just because we know folk will whine if the S is not there; it's ietf fashion, similar to not working over ipv6 (or privacy consideration sections:). And the us of TLS will ensure that the file comes from the intended source and it comes without modification. for example, was i to put my geofeed file in gobble docs, the web pki would be gobble's cert chain, not mine, the IP space owner. one can optionally authenticate the geofeed data themselves by using the rpki to sign over them. and, unlike the web pki, the rpki does provide authority over IP address space ownership. so these two pki uses are quite distinct and serve very different purposes. to aid the reader, i have hacked in The URL's use of the web PKI can not provide authentication of IP address space ownership. It is only used to authenticate a pointer to the geofeed file and transport integrity of the data. In contrast, the RPKI can be used to authenticate IP space ownership; see optional authentication in Section 4. > I'm trying to suss out the requirements that led to this design, and > so far it is not clear to me why two mechanisms are necessary or > desirable given the complexity this implies for clients. ISTM that if > a requirement is made that the geofeed data file MUST be served via > https, and RPKI authenticates the URL, then the web PKI would provide > a sufficient trust anchor for the geofeed data itself without any > additional RPKI signature. Alternatively, if the assumption is that > RPKI is the more appropriate PKI for protecting this information, then > why leverage the web PKI at all? see above > * There appears to be no way to revoke previously-signed geofeed data > except via rotation of the RPKI key pair. Using the web PKI and https > is a countermeasure here by preventing impersonation of the geofeed > host, but it's unclear what utility RPKI provides if web PKI is > required to guarantee geofeed freshness. Metadata imposing a expiry > on geofeed data authenticated by RPKI would serve the same function, > at the cost of requiring the data to be refreshed regularly. validation of the signing certificate needs to ensure that it is part of the current manifest and that the resources are covered by the RPKI certificate. this handles revocation. but, if you want to go down the "how does revocation work in the rpki" rabbit hole, you have to drink the 3779 validation koolaid, and that of the "up-down" protocol, and have a look at manifests. not that i am recommending going down this rabbit hole. > * Is it always the case that RPKI private keys are protected by HSM, > or is that simply a best practice? not at all. but, imiho, we should stay neutral on that. the example Identifying the private key associated with the certificate, and getting the department with the Hardware Security Module (HSM) to sign the CMS blob is left as an exercise for the implementor. was merely a cultural reference to the silos in a large LIR where address space ownership, rpki signing, ... are often in a very separate fiefdom from geo location folk. > Is the assumption that all RPKI changes imply a manual workflow? no. one hopes it will become more and more automated as time passes. we hope the manual workflow will go away. weekly would be a fantastic improvement over the multi-month or forever gap we have now. every week there is a plea on nanog "my customer in gzork is blocked by fooTV who seems to think thay're in gzplatz and won't let them watch sesame street." the two informative references, draft-ietf-sidrops-rpki-rta and draft-spaghetti-sidrops-rpki-rsc, should give you a feeling to where this can go, devops willing. > * Is it actually
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
> On 29 Apr 2021, at 19:46, Henk Birkholz > wrote: > > I was under the assumption that the thing that is immutable is the MUD URL > right Yes, if it is in the certificate. So now you go to the MUD file. Surely that can be updated with new version information. But if devices still have the old version, you have to handle that as well. This is an area which eventually can be helped by RATS, if one of the attestation information elements is version information. Eliot > > On 29.04.21 19:42, Eliot Lear wrote: >> The MUD file can certainly point to a single version, but if the MUD file is >> obtained through some immutable mechanism (device certificate) then the >> version info has to come from somewhere else. >> Eliot >>> On 29 Apr 2021, at 19:39, Henk Birkholz >>> wrote: >>> >>> Hi Eliot, >>> >>> shouldn't be the MUD file (that is maintained by an appropriate authority, >>> hopefully) in charge of that? The default SBOM retrievable via the MUD file >>> could therefore always be the latest version? Older versions should be >>> discoverable via the MUD file or mechanism around that? >>> >>> Viele Grüße, >>> >>> Henk (no hat) >>> >>> On 29.04.21 19:15, Eliot Lear wrote: Soo… I think this is a bit of an interesting question. If an SBOM lives in the cloud somewhere, and it is associated to a version string, how do you know which one is the LATEST version? If there is semantic meaning, then the inventory management system has to be able to determine that. The simple approach would be for the array to be ordered, but I am not a fan of these sorts of implicit mechanisms. Another approach would be to index on a date rather than a version. Eliot > On 29 Apr 2021, at 17:16, Dick Brooks > wrote: > > Thanks, Eliot. I was just expressing my preferred method of versioning. > As long as the spec doesn't disallow semantic versioning, then I'm ok. > > Thanks, > > Dick Brooks > > Never trust software, always verify and report! ™ > http://www.reliableenergyanalytics.com > Email: d...@reliableenergyanalytics.com > Tel: +1 978-696-1788 > > -Original Message- > From: Eliot Lear > Sent: Thursday, April 29, 2021 10:25 AM > To: Dick Brooks > Cc: Eliot Lear ; opsawg > Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access > > Hi Dick > > When you say semantic versioning, what do you have in mind? Keep in mind > that we want to be neutral to format. > > Eliot > >> On 29 Apr 2021, at 15:30, Dick Brooks >> wrote: >> >> Eliot, >> >> Here is the information I use in SAG-PM to discover and retrieve an >> SBOM; hope this helps. Version is a must have attribute of the product >> definition to retrieve the correct SBOM. >> >> Semantic versioning is preferred: MAJOR.MINOR.PATCH >> >> >> Reliable Energy Analytics LLC >> SAG-PM (TM) >> 1.1.0 >> > signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml >> >> https://softwareassuranceguardian.com/sag-pm.zip >> Y >> N >> >> 2021-04-23T15:57:00 >> >> >> >> Thanks, >> >> Dick Brooks >> >> Never trust software, always verify and report! ™ >> http://www.reliableenergyanalytics.com >> Email: d...@reliableenergyanalytics.com >> Tel: +1 978-696-1788 >> >> -Original Message- >> From: OPSAWG On Behalf Of Eliot Lear >> Sent: Thursday, April 29, 2021 9:15 AM >> To: opsawg >> Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access >> >> The current draft allows for multiple SBOM versions. The reason for >> this is that if a MUD URL is used, and the SBOM is contained on a server >> somewhere, one would need to use out of band information to determine >> software versions. However, this doesn’t make sense if you are >> retrieving the SBOM from the device. Therefore, the model needs to >> change a bit. >> >> We want a “when” clause somewhere for the version info, but this >> introduces an new challenge: as currently listed the version-info field >> is an index. That has to go. >> >> So… what I think we want to do is invert the list along the following >> lines: >> >> - choice sbom-type: >> case url: >> list sboms >> leaf version-info >> leaf sbom-url >> case local-uri: >> type empty - the whole thing is constructed using >> .well-known/sbom >> case contact-info: as before but without versioning >> >> >> Anyway, this is what I am thinking.
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
I was under the assumption that the thing that is immutable is the MUD URL right (e.g. if it resides in an IDevID)? Is a specific MUD URL statically linked to one specific MUD file? If not, you could update the MUD file to always point to the latest version (first, other linked via that MUD file maybe) - or would that defeat some purpose that I am missing or forgot? On 29.04.21 19:42, Eliot Lear wrote: The MUD file can certainly point to a single version, but if the MUD file is obtained through some immutable mechanism (device certificate) then the version info has to come from somewhere else. Eliot On 29 Apr 2021, at 19:39, Henk Birkholz wrote: Hi Eliot, shouldn't be the MUD file (that is maintained by an appropriate authority, hopefully) in charge of that? The default SBOM retrievable via the MUD file could therefore always be the latest version? Older versions should be discoverable via the MUD file or mechanism around that? Viele Grüße, Henk (no hat) On 29.04.21 19:15, Eliot Lear wrote: Soo… I think this is a bit of an interesting question. If an SBOM lives in the cloud somewhere, and it is associated to a version string, how do you know which one is the LATEST version? If there is semantic meaning, then the inventory management system has to be able to determine that. The simple approach would be for the array to be ordered, but I am not a fan of these sorts of implicit mechanisms. Another approach would be to index on a date rather than a version. Eliot On 29 Apr 2021, at 17:16, Dick Brooks wrote: Thanks, Eliot. I was just expressing my preferred method of versioning. As long as the spec doesn't disallow semantic versioning, then I'm ok. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Eliot Lear Sent: Thursday, April 29, 2021 10:25 AM To: Dick Brooks Cc: Eliot Lear ; opsawg Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access Hi Dick When you say semantic versioning, what do you have in mind? Keep in mind that we want to be neutral to format. Eliot On 29 Apr 2021, at 15:30, Dick Brooks wrote: Eliot, Here is the information I use in SAG-PM to discover and retrieve an SBOM; hope this helps. Version is a must have attribute of the product definition to retrieve the correct SBOM. Semantic versioning is preferred: MAJOR.MINOR.PATCH Reliable Energy Analytics LLC SAG-PM (TM) 1.1.0 https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml https://softwareassuranceguardian.com/sag-pm.zip Y N 2021-04-23T15:57:00 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: OPSAWG On Behalf Of Eliot Lear Sent: Thursday, April 29, 2021 9:15 AM To: opsawg Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
The MUD file can certainly point to a single version, but if the MUD file is obtained through some immutable mechanism (device certificate) then the version info has to come from somewhere else. Eliot > On 29 Apr 2021, at 19:39, Henk Birkholz > wrote: > > Hi Eliot, > > shouldn't be the MUD file (that is maintained by an appropriate authority, > hopefully) in charge of that? The default SBOM retrievable via the MUD file > could therefore always be the latest version? Older versions should be > discoverable via the MUD file or mechanism around that? > > Viele Grüße, > > Henk (no hat) > > On 29.04.21 19:15, Eliot Lear wrote: >> Soo… >> I think this is a bit of an interesting question. If an SBOM lives in the >> cloud somewhere, and it is associated to a version string, how do you know >> which one is the LATEST version? If there is semantic meaning, then the >> inventory management system has to be able to determine that. The simple >> approach would be for the array to be ordered, but I am not a fan of these >> sorts of implicit mechanisms. Another approach would be to index on a date >> rather than a version. >> Eliot >>> On 29 Apr 2021, at 17:16, Dick Brooks >>> wrote: >>> >>> Thanks, Eliot. I was just expressing my preferred method of versioning. As >>> long as the spec doesn't disallow semantic versioning, then I'm ok. >>> >>> Thanks, >>> >>> Dick Brooks >>> >>> Never trust software, always verify and report! ™ >>> http://www.reliableenergyanalytics.com >>> Email: d...@reliableenergyanalytics.com >>> Tel: +1 978-696-1788 >>> >>> -Original Message- >>> From: Eliot Lear >>> Sent: Thursday, April 29, 2021 10:25 AM >>> To: Dick Brooks >>> Cc: Eliot Lear ; opsawg >>> Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access >>> >>> Hi Dick >>> >>> When you say semantic versioning, what do you have in mind? Keep in mind >>> that we want to be neutral to format. >>> >>> Eliot >>> On 29 Apr 2021, at 15:30, Dick Brooks wrote: Eliot, Here is the information I use in SAG-PM to discover and retrieve an SBOM; hope this helps. Version is a must have attribute of the product definition to retrieve the correct SBOM. Semantic versioning is preferred: MAJOR.MINOR.PATCH Reliable Energy Analytics LLC SAG-PM (TM) 1.1.0 >>> signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml https://softwareassuranceguardian.com/sag-pm.zip Y N 2021-04-23T15:57:00 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: OPSAWG On Behalf Of Eliot Lear Sent: Thursday, April 29, 2021 9:15 AM To: opsawg Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg >>> >>> >> ___ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Hi Eliot, shouldn't be the MUD file (that is maintained by an appropriate authority, hopefully) in charge of that? The default SBOM retrievable via the MUD file could therefore always be the latest version? Older versions should be discoverable via the MUD file or mechanism around that? Viele Grüße, Henk (no hat) On 29.04.21 19:15, Eliot Lear wrote: Soo… I think this is a bit of an interesting question. If an SBOM lives in the cloud somewhere, and it is associated to a version string, how do you know which one is the LATEST version? If there is semantic meaning, then the inventory management system has to be able to determine that. The simple approach would be for the array to be ordered, but I am not a fan of these sorts of implicit mechanisms. Another approach would be to index on a date rather than a version. Eliot On 29 Apr 2021, at 17:16, Dick Brooks wrote: Thanks, Eliot. I was just expressing my preferred method of versioning. As long as the spec doesn't disallow semantic versioning, then I'm ok. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Eliot Lear Sent: Thursday, April 29, 2021 10:25 AM To: Dick Brooks Cc: Eliot Lear ; opsawg Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access Hi Dick When you say semantic versioning, what do you have in mind? Keep in mind that we want to be neutral to format. Eliot On 29 Apr 2021, at 15:30, Dick Brooks wrote: Eliot, Here is the information I use in SAG-PM to discover and retrieve an SBOM; hope this helps. Version is a must have attribute of the product definition to retrieve the correct SBOM. Semantic versioning is preferred: MAJOR.MINOR.PATCH Reliable Energy Analytics LLC SAG-PM (TM) 1.1.0 https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml https://softwareassuranceguardian.com/sag-pm.zip Y N 2021-04-23T15:57:00 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: OPSAWG On Behalf Of Eliot Lear Sent: Thursday, April 29, 2021 9:15 AM To: opsawg Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Here's how it works with SAG-PM:
1. Customer downloads a software object to be installed.
2. SAG-PM introspects the downloaded file for identification properties:
Performing program introspection; storing SBOM information for posterity
*** PROPERTIES ***
> Manufacturer : Reliable Energy Analytics LLC
> ProductCode : {C0AF4A54-0C0A-4948-BF1F-A66089EF4C5A}
> ProductName : SAG-PM (TM)
> ProductVersion : 1.1.0
NOTE: A username and password are required to access this Questionnaire
>Enter Username for Vendor Reliable Energy Analytics LLC :
3. This information is used to lookup the vendor, product and version in a
local database, which identifies the "VendorResponse" data (see attached
example)
4. Retrieve the Vendor response data, then download the SBOM identified for
that Vendor/Product/Version
5 Perform the remaining risk assessment steps.
Thanks,
Dick Brooks
Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788
-Original Message-
From: Eliot Lear
Sent: Thursday, April 29, 2021 1:16 PM
To: d...@reliableenergyanalytics.com
Cc: Eliot Lear ; opsawg
Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Soo…
I think this is a bit of an interesting question. If an SBOM lives in the
cloud somewhere, and it is associated to a version string, how do you know
which one is the LATEST version? If there is semantic meaning, then the
inventory management system has to be able to determine that. The simple
approach would be for the array to be ordered, but I am not a fan of these
sorts of implicit mechanisms. Another approach would be to index on a date
rather than a version.
Eliot
> On 29 Apr 2021, at 17:16, Dick Brooks
> wrote:
>
> Thanks, Eliot. I was just expressing my preferred method of versioning. As
> long as the spec doesn't disallow semantic versioning, then I'm ok.
>
> Thanks,
>
> Dick Brooks
>
> Never trust software, always verify and report! ™
> http://www.reliableenergyanalytics.com
> Email: d...@reliableenergyanalytics.com
> Tel: +1 978-696-1788
>
> -Original Message-
> From: Eliot Lear
> Sent: Thursday, April 29, 2021 10:25 AM
> To: Dick Brooks
> Cc: Eliot Lear ; opsawg
>
> Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
>
> Hi Dick
>
> When you say semantic versioning, what do you have in mind? Keep in mind
> that we want to be neutral to format.
>
> Eliot
>
>> On 29 Apr 2021, at 15:30, Dick Brooks
>> wrote:
>>
>> Eliot,
>>
>> Here is the information I use in SAG-PM to discover and retrieve an SBOM;
>> hope this helps. Version is a must have attribute of the product definition
>> to retrieve the correct SBOM.
>>
>> Semantic versioning is preferred: MAJOR.MINOR.PATCH
>>
>>
>> Reliable Energy Analytics LLC
>> SAG-PM (TM)
>> 1.1.0
>> > signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml
>>
>> https://softwareassuranceguardian.com/sag-pm.zip
>> Y
>> N
>>
>> 2021-04-23T15:57:00
>>
>>
>>
>> Thanks,
>>
>> Dick Brooks
>>
>> Never trust software, always verify and report! ™
>> http://www.reliableenergyanalytics.com
>> Email: d...@reliableenergyanalytics.com
>> Tel: +1 978-696-1788
>>
>> -Original Message-
>> From: OPSAWG On Behalf Of Eliot Lear
>> Sent: Thursday, April 29, 2021 9:15 AM
>> To: opsawg
>> Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
>>
>> The current draft allows for multiple SBOM versions. The reason for this is
>> that if a MUD URL is used, and the SBOM is contained on a server somewhere,
>> one would need to use out of band information to determine software
>> versions. However, this doesn’t make sense if you are retrieving the SBOM
>> from the device. Therefore, the model needs to change a bit.
>>
>> We want a “when” clause somewhere for the version info, but this introduces
>> an new challenge: as currently listed the version-info field is an index.
>> That has to go.
>>
>> So… what I think we want to do is invert the list along the following lines:
>>
>> - choice sbom-type:
>> case url:
>> list sboms
>> leaf version-info
>> leaf sbom-url
>> case local-uri:
>> type empty - the whole thing is constructed using
>> .well-known/sbom
>> case contact-info: as before but without versioning
>>
>>
>> Anyway, this is what I am thinking. Thoughts?
>>
>> Eliot
>>
>> ___
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>
>
Reliable Energy Analytics LLC
dns:reliableenergyanalytics.com
23 Linda Drive
Westfield
Massachusetts
01085
USA
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Soo… I think this is a bit of an interesting question. If an SBOM lives in the cloud somewhere, and it is associated to a version string, how do you know which one is the LATEST version? If there is semantic meaning, then the inventory management system has to be able to determine that. The simple approach would be for the array to be ordered, but I am not a fan of these sorts of implicit mechanisms. Another approach would be to index on a date rather than a version. Eliot > On 29 Apr 2021, at 17:16, Dick Brooks > wrote: > > Thanks, Eliot. I was just expressing my preferred method of versioning. As > long as the spec doesn't disallow semantic versioning, then I'm ok. > > Thanks, > > Dick Brooks > > Never trust software, always verify and report! ™ > http://www.reliableenergyanalytics.com > Email: d...@reliableenergyanalytics.com > Tel: +1 978-696-1788 > > -Original Message- > From: Eliot Lear > Sent: Thursday, April 29, 2021 10:25 AM > To: Dick Brooks > Cc: Eliot Lear ; opsawg > Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access > > Hi Dick > > When you say semantic versioning, what do you have in mind? Keep in mind > that we want to be neutral to format. > > Eliot > >> On 29 Apr 2021, at 15:30, Dick Brooks >> wrote: >> >> Eliot, >> >> Here is the information I use in SAG-PM to discover and retrieve an SBOM; >> hope this helps. Version is a must have attribute of the product definition >> to retrieve the correct SBOM. >> >> Semantic versioning is preferred: MAJOR.MINOR.PATCH >> >> >> Reliable Energy Analytics LLC >> SAG-PM (TM) >> 1.1.0 >> > signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml >> >> https://softwareassuranceguardian.com/sag-pm.zip >> Y >> N >> >> 2021-04-23T15:57:00 >> >> >> >> Thanks, >> >> Dick Brooks >> >> Never trust software, always verify and report! ™ >> http://www.reliableenergyanalytics.com >> Email: d...@reliableenergyanalytics.com >> Tel: +1 978-696-1788 >> >> -Original Message- >> From: OPSAWG On Behalf Of Eliot Lear >> Sent: Thursday, April 29, 2021 9:15 AM >> To: opsawg >> Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access >> >> The current draft allows for multiple SBOM versions. The reason for this is >> that if a MUD URL is used, and the SBOM is contained on a server somewhere, >> one would need to use out of band information to determine software >> versions. However, this doesn’t make sense if you are retrieving the SBOM >> from the device. Therefore, the model needs to change a bit. >> >> We want a “when” clause somewhere for the version info, but this introduces >> an new challenge: as currently listed the version-info field is an index. >> That has to go. >> >> So… what I think we want to do is invert the list along the following lines: >> >> - choice sbom-type: >> case url: >> list sboms >> leaf version-info >> leaf sbom-url >> case local-uri: >> type empty - the whole thing is constructed using >> .well-known/sbom >> case contact-info: as before but without versioning >> >> >> Anyway, this is what I am thinking. Thoughts? >> >> Eliot >> >> ___ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Thanks, Eliot. I was just expressing my preferred method of versioning. As long as the spec doesn't disallow semantic versioning, then I'm ok. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: Eliot Lear Sent: Thursday, April 29, 2021 10:25 AM To: Dick Brooks Cc: Eliot Lear ; opsawg Subject: Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access Hi Dick When you say semantic versioning, what do you have in mind? Keep in mind that we want to be neutral to format. Eliot > On 29 Apr 2021, at 15:30, Dick Brooks > wrote: > > Eliot, > > Here is the information I use in SAG-PM to discover and retrieve an SBOM; > hope this helps. Version is a must have attribute of the product definition > to retrieve the correct SBOM. > > Semantic versioning is preferred: MAJOR.MINOR.PATCH > > >Reliable Energy Analytics LLC >SAG-PM (TM) >1.1.0 > signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml > > https://softwareassuranceguardian.com/sag-pm.zip >Y >N > > 2021-04-23T15:57:00 > > > > Thanks, > > Dick Brooks > > Never trust software, always verify and report! ™ > http://www.reliableenergyanalytics.com > Email: d...@reliableenergyanalytics.com > Tel: +1 978-696-1788 > > -Original Message- > From: OPSAWG On Behalf Of Eliot Lear > Sent: Thursday, April 29, 2021 9:15 AM > To: opsawg > Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access > > The current draft allows for multiple SBOM versions. The reason for this is > that if a MUD URL is used, and the SBOM is contained on a server somewhere, > one would need to use out of band information to determine software versions. > However, this doesn’t make sense if you are retrieving the SBOM from the > device. Therefore, the model needs to change a bit. > > We want a “when” clause somewhere for the version info, but this introduces > an new challenge: as currently listed the version-info field is an index. > That has to go. > > So… what I think we want to do is invert the list along the following lines: > > - choice sbom-type: > case url: > list sboms > leaf version-info > leaf sbom-url > case local-uri: > type empty - the whole thing is constructed using > .well-known/sbom > case contact-info: as before but without versioning > > > Anyway, this is what I am thinking. Thoughts? > > Eliot > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Hi Dick When you say semantic versioning, what do you have in mind? Keep in mind that we want to be neutral to format. Eliot > On 29 Apr 2021, at 15:30, Dick Brooks > wrote: > > Eliot, > > Here is the information I use in SAG-PM to discover and retrieve an SBOM; > hope this helps. Version is a must have attribute of the product definition > to retrieve the correct SBOM. > > Semantic versioning is preferred: MAJOR.MINOR.PATCH > > >Reliable Energy Analytics LLC >SAG-PM (TM) >1.1.0 > signature="https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml > > https://softwareassuranceguardian.com/sag-pm.zip >Y >N > > 2021-04-23T15:57:00 > > > > Thanks, > > Dick Brooks > > Never trust software, always verify and report! ™ > http://www.reliableenergyanalytics.com > Email: d...@reliableenergyanalytics.com > Tel: +1 978-696-1788 > > -Original Message- > From: OPSAWG On Behalf Of Eliot Lear > Sent: Thursday, April 29, 2021 9:15 AM > To: opsawg > Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access > > The current draft allows for multiple SBOM versions. The reason for this is > that if a MUD URL is used, and the SBOM is contained on a server somewhere, > one would need to use out of band information to determine software versions. > However, this doesn’t make sense if you are retrieving the SBOM from the > device. Therefore, the model needs to change a bit. > > We want a “when” clause somewhere for the version info, but this introduces > an new challenge: as currently listed the version-info field is an index. > That has to go. > > So… what I think we want to do is invert the list along the following lines: > > - choice sbom-type: > case url: > list sboms > leaf version-info > leaf sbom-url > case local-uri: > type empty - the whole thing is constructed using > .well-known/sbom > case contact-info: as before but without versioning > > > Anyway, this is what I am thinking. Thoughts? > > Eliot > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
Eliot, Here is the information I use in SAG-PM to discover and retrieve an SBOM; hope this helps. Version is a must have attribute of the product definition to retrieve the correct SBOM. Semantic versioning is preferred: MAJOR.MINOR.PATCH Reliable Energy Analytics LLC SAG-PM (TM) 1.1.0 https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml.sig;>https://softwareassuranceguardian.com/SAG-PM-cycloneDX.xml https://softwareassuranceguardian.com/sag-pm.zip Y N 2021-04-23T15:57:00 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -Original Message- From: OPSAWG On Behalf Of Eliot Lear Sent: Thursday, April 29, 2021 9:15 AM To: opsawg Subject: [OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Sbom versioning - draft-ietf-opawg-sbom-access
The current draft allows for multiple SBOM versions. The reason for this is that if a MUD URL is used, and the SBOM is contained on a server somewhere, one would need to use out of band information to determine software versions. However, this doesn’t make sense if you are retrieving the SBOM from the device. Therefore, the model needs to change a bit. We want a “when” clause somewhere for the version info, but this introduces an new challenge: as currently listed the version-info field is an index. That has to go. So… what I think we want to do is invert the list along the following lines: - choice sbom-type: case url: list sboms leaf version-info leaf sbom-url case local-uri: type empty - the whole thing is constructed using .well-known/sbom case contact-info: as before but without versioning Anyway, this is what I am thinking. Thoughts? Eliot signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07
Hi,all I support the adoption of this draft. Needless to say, real-time monitoring and making sure that the network indeed complies with the desired service intent is the key to IBN. Thanks to the authors for this work. Best Regards, Qiufang Ma -Original Message- From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Henk Birkholz Sent: Wednesday, April 28, 2021 2:02 AM To: opsawg Subject: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07 Dear OPSAWG members, this starts a call for Working Group Adoption for > https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assu > rance-yang-07 ending on Tuesday, May 18th. As a reminder, this I-D describes YANG modules intended to facilitate the aggregation of an assurance graph about the health of services and sub-services in a system of interconnected network devices. To achieve that, the I-D defines modules for graph updates about (sub-)services and corresponding health and symptom knowledge acquired via assurance telemetry. Please reply with your support and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05
Hi, all I support the adoption of this draft. Needless to say, real-time monitoring and making sure that the network indeed complies with the desired service intent is the key to IBN. I have just one comment: the assurance graph for the tunnel service depicted in Fig.2 looks more like a tree structure(undirected graph),rather than a DAG. Authors, could you please show the dependency relations in that graph? Best Regards, Qiufang Ma -Original Message- From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Henk Birkholz Sent: Wednesday, April 28, 2021 2:00 AM To: opsawg Subject: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05 Dear OPSAWG members, this starts a call for Working Group Adoption for > https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assu > rance-architecture-05 ending on Tuesday, May 18th. As a reminder, this I-D describes the health of an interconnected system of network devices and (sub-)services located in that system. A degraded health status is explained via symptom descriptions and the resulting interconnected knowledge is aggregated in an assurance graph. Please reply with your support and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] conclusion: how many SBOMs to retrieve
Hi, At least from the discussion thus far, with the discovery mechanism in draf-ietf-opsawg-sbom-access there is currently only a need to retrieve a single SBOM. According to both SPDX and CycloneDx folk, they have sufficiently internalized any additional references. CycloneDx can point directly to a URL, whereas with SPDX one further resolution before you get there. I can’t say at this stage which is better, but from this draft’s perspective, its job is done either way, once the JSON extension is read and the initial SBOM is located. Eliot signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
Reviewer: Kyle Rose Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document Has Issues. == Nits The nits include a need for a thorough editorial pass prior to submission to the RFC editor. For example: * The abstract should probably give the uninformed reader a bit more information about the overall geofeed ecosystem. * "utterly awesome", "or whatever", "It would be polite" I would also move the privacy discussion from section 2 "Geofeed Files" to a privacy considerations section, as that is where those concerned will look for that information. == Unclear requirements This document appears to propose overlapping mechanisms for establishment of trust in geofeed data. As far as I can tell, geofeed data may be authenticated both by: * RPKI private key signature of a digest of a canonicalized form of the geofeed data file. * Web PKI via https URL for geofeed data file. I'm trying to suss out the requirements that led to this design, and so far it is not clear to me why two mechanisms are necessary or desirable given the complexity this implies for clients. ISTM that if a requirement is made that the geofeed data file MUST be served via https, and RPKI authenticates the URL, then the web PKI would provide a sufficient trust anchor for the geofeed data itself without any additional RPKI signature. Alternatively, if the assumption is that RPKI is the more appropriate PKI for protecting this information, then why leverage the web PKI at all? Moreover, even if the flexibility offered by two mechanisms is found to be desirable, there is no explicit recommendation that an LIR use one mechanism exclusively for a given geofeed. == Security gaps * There appears to be no way to revoke previously-signed geofeed data except via rotation of the RPKI key pair. Using the web PKI and https is a countermeasure here by preventing impersonation of the geofeed host, but it's unclear what utility RPKI provides if web PKI is required to guarantee geofeed freshness. Metadata imposing a expiry on geofeed data authenticated by RPKI would serve the same function, at the cost of requiring the data to be refreshed regularly. == Other questions * Is it always the case that RPKI private keys are protected by HSM, or is that simply a best practice? Is the assumption that all RPKI changes imply a manual workflow? * Is it actually the case that "the data change very infrequently"? Is there no legitimate use case for rapidly changing geofeed information, e.g., for overlay networks providing IP mobility? 'At most weekly' seems arbitrary. This also has implications for the choice of PKI, if manual workflows are indeed required for RPKI signing. * Why does the geofeed appendix not accommodate multiple signatures for distinct address ranges? The requirement that a geofeed file not be RPKI-signed in order to be shared by multiple INETNUM objects could be relieved were multiple signatures allowed. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07
Without any hat, I support the adoption of this document by OPSAWG. Having worked for 2 years on a very similar project/proof of concept, the YANG module approach is indeed correct and represent well the use cases. Regards -éric -Original Message- From: OPSAWG on behalf of Henk Birkholz Date: Tuesday, 27 April 2021 at 20:02 To: opsawg Subject: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07 Dear OPSAWG members, this starts a call for Working Group Adoption for > https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07 ending on Tuesday, May 18th. As a reminder, this I-D describes YANG modules intended to facilitate the aggregation of an assurance graph about the health of services and sub-services in a system of interconnected network devices. To achieve that, the I-D defines modules for graph updates about (sub-)services and corresponding health and symptom knowledge acquired via assurance telemetry. Please reply with your support and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05
Without any hat, I support the adoption of this document by OPSAWG. Having worked for 2 years on a very similar project/proof of concept, the architecture has been proven valid. -éric -Original Message- From: OPSAWG on behalf of Henk Birkholz Date: Tuesday, 27 April 2021 at 20:01 To: opsawg Subject: [OPSAWG] WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05 Dear OPSAWG members, this starts a call for Working Group Adoption for > https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05 ending on Tuesday, May 18th. As a reminder, this I-D describes the health of an interconnected system of network devices and (sub-)services located in that system. A degraded health status is explained via symptom descriptions and the resulting interconnected knowledge is aggregated in an assurance graph. Please reply with your support and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
