[OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-architecture-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Service Assurance for Intent-based Networking 
Architecture
Authors : Benoit Claise
  Jean Quilbeuf
  Diego R. Lopez
  Dan Voyer
  Thangam Arumugam
Filename: 
draft-ietf-opsawg-service-assurance-architecture-00.txt
Pages   : 19
Date: 2021-05-21

Abstract:
   This document describes an architecture for Service Assurance for
   Intent-based Networking (SAIN).  This architecture aims at assuring
   that service instances are correctly running.  As services rely on
   multiple sub-services by the underlying network devices, getting the
   assurance of a healthy service is only possible with a holistic view
   of network devices.  This architecture not only helps to correlate
   the service degradation with the network root cause but also the
   impacted services when a network component fails or degrades.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-architecture-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-yang-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : YANG Modules for Service Assurance
Authors : Benoit Claise
  Jean Quilbeuf
  Paolo Lucente
  Paolo Fasano
  Thangam Arumugam
Filename: draft-ietf-opsawg-service-assurance-yang-00.txt
Pages   : 28
Date: 2021-05-21

Abstract:
   This document proposes YANG modules for the Service Assurance for
   Intent-based Networking Architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-yang-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Patrick Dwyer]

I agree with all of that. Perhaps not on whether it belongs here though.
This draft, so far, is completely focused on SBOMs. Not on vulnerability
information or advisories.

Perhaps it would be better served as a separate MUD extension and
well-known URI?

On Wed, May 26, 2021 at 4:39 PM Eliot Lear  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 different points of view on
> this.  Some may simply be required to release an SBOM based on some
> regulatory requirement.  Some not, and some may wish to release an SBOM
> without using this mechanism.
>
>
>
>> > I also think this is one of those things that crosses a logical
>> > boundary that is no longer about discovering and accessing an SBOM.
>>
>> That is true.  But not a huge stretch.
>>
>>
> It's not a huge stretch. But this is also tied to a particular format for
> this type of information. Personally I think CSAF is *the* format to use.
> But that might not be the case in some particular industries and countries.
>
> Yes.  I myself am hemming and hawing on this point a bit...  Let's just
> delve into that a bit more:
>
> On the one hand, we have one really good candidate, CSAF.  On the other
> hand, one might want to refer to the Old (more deployed) Stuff, which does
> almost as good a job, CVRF.  On the third hand, it is possible that this
> information could be included directly in a schema like CycloneDX, either
> directly or as an extension.  On the fourth hand, the information could be
> included as a reference by the underlying SBOM format, as you mentioned
> earlier.
>
> So what are the principles here?  I think they are these:
>
>1. If the information exists outside the context of an SBOM, it should
>be made known.
>2. Don't make the end device do work.  Leave that to the network
>management.
>3. When there's one really overwhelmingly good candidate, use it and
>don't overcomplicate the network management.
>4. Provide some flexibility for the idea that these formats may change.
>5. Don't duplicate information elements.
>
> Some of these principles conflict.  Here's what I suggest:
>
>1. If the information is included in the SBOM there is no need for a
>MUD file to include the new element.
>2. If the information is NOT included in the SBOM, or the SBOM isn't
>available, there is a need to provide the new element.
>3. Let's change the name of the element from "csaf-location" to
>"vulnerability-info", and make use of the same mechanism we used for SBOMs
>to decide, with a suggestion that CSAF be the preferred initial format for
>consumers.  This splits the baby a bit, but perhaps covers your concern?
>
> Also note that with CSAF I am taking a certain liberty to constrain the
> CSAF reference in this case to contain a single product, so that we don't
> get into a naming fiasco.  Naming.  I hate naming.
>
> Eliot
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Protocol Action: 'Finding and Using Geofeed Data' to Proposed Standard (draft-ietf-opsawg-finding-geofeeds-17.txt)

[The IESG]

The IESG has approved the following document:
- 'Finding and Using Geofeed Data'
  (draft-ietf-opsawg-finding-geofeeds-17.txt) as Proposed Standard

This document is the product of the Operations and Management Area Working
Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/





Technical Summary

Providers of Internet content and other services may wish to customize
those services based on the geographic location of the user of the
service. This is often done using the source IP address used to
contact the service. Also, infrastructure and other services might
wish to publish the locale of their services. [RFC8805] defines
geofeed, a syntax to associate geographic locales with IP addresses.
But it does not specify how to find the relevant geofeed data given
an IP address.

This document specifies how to augment the Routing Policy Specification
Language (RPSL) [RFC4012] inetnum: class [INETNUM] to refer to
geofeed data, and how to prudently use them. In all places inetnum:
is used, inet6num: should also be assumed [INET6NUM].

Working Group Summary

There seemed to be a reasonable amount of discussion during the WG phase, 
but nothing that seemed to be particular controversial or rough.

Document Quality

There are active discussions in one RIR to implement the proposed
field in their deployed RPSL Whois.  There are discussions commencing
in another RIR.  Commentary included an author of a third RPSL
implementation.

 I would like to thank George, the doc shepherd for performing a 
 diligent shepherd's review and writeup.

Personnel

The document Shepherd is George Michaelson.
The responsible Area Director is Robert Wilton.

IESG Note

This document defines a "remarks: Geofeed" attribute until a new
"geofeed:" attribute in the inetnum: class can be defined.  The
 authors are actively working with the relevant parties to get the
geofeed: attribute defined aligning with the specification defined
in this document.




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eliot Lear]

I don't mind.  If it helps I can relabel some of the containers to 
generalize.  Also keep in mind, the extension does not REQUIRE any 
elements in the MUD file.  But I think the WG should make a call on 
this.  If it is a bit far aways from the SBOM, we could write another draft.


On 26.05.21 13:46, Patrick Dwyer wrote:
I agree with all of that. Perhaps not on whether it belongs here 
though. This draft, so far, is completely focused on SBOMs. Not on 
vulnerability information or advisories.


Perhaps it would be better served as a separate MUD extension and 
well-known URI?


On Wed, May 26, 2021 at 4:39 PM Eliot Lear > 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 different points of view
on this.  Some may simply be required to release an SBOM based on
some regulatory requirement. Some not, and some may wish to
release an SBOM without using this mechanism.




> I also think this is one of those things that crosses a
logical
> boundary that is no longer about discovering and accessing
an SBOM.

That is true.  But not a huge stretch.


It's not a huge stretch. But this is also tied to a particular
format for this type of information. Personally I think CSAF is
/the/ format to use. But that might not be the case in some
particular industries and countries.


Yes.  I myself am hemming and hawing on this point a bit...  Let's
just delve into that a bit more:

On the one hand, we have one really good candidate, CSAF.  On the
other hand, one might want to refer to the Old (more deployed)
Stuff, which does almost as good a job, CVRF.  On the third hand,
it is possible that this information could be included directly in
a schema like CycloneDX, either directly or as an extension.  On
the fourth hand, the information could be included as a reference
by the underlying SBOM format, as you mentioned earlier.

So what are the principles here?  I think they are these:

 1. If the information exists outside the context of an SBOM, it
should be made known.
 2. Don't make the end device do work.  Leave that to the network
management.
 3. When there's one really overwhelmingly good candidate, use it
and don't overcomplicate the network management.
 4. Provide some flexibility for the idea that these formats may
change.
 5. Don't duplicate information elements.

Some of these principles conflict.  Here's what I suggest:

 1. If the information is included in the SBOM there is no need
for a MUD file to include the new element.
 2. If the information is NOT included in the SBOM, or the SBOM
isn't available, there is a need to provide the new element.
 3. Let's change the name of the element from "csaf-location" to
"vulnerability-info", and make use of the same mechanism we
used for SBOMs to decide, with a suggestion that CSAF be the
preferred initial format for consumers.  This splits the baby
a bit, but perhaps covers your concern?

Also note that with CSAF I am taking a certain liberty to
constrain the CSAF reference in this case to contain a single
product, so that we don't get into a naming fiasco.  Naming.  I
hate naming.

Eliot




OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] NomCom 2021-2022 Call for Volunteers

[Henk Birkholz]

Dear OPSAWG members,

please note that the NomCom 2021-2022 Call for Volunteers started today.


The IETF NomCom appoints people to fill the open slots on the IETF LLC,
IETF Trust, the IAB, and the IESG.
Ten voting members for the NomCom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we
have of choosing a random yet representative cross section of the IETF
population.


The call's duration is 4 weeks and ends before 23:59 UTC on Wednesday 
June 23, 2021. Further details can be found in BCP 10 (RFC 8713) and of 
course the announcement email:



https://mailarchive.ietf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT1TaPaU/



Viele Grüße,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Patrick Dwyer]

Just to be clear. I'm on the fence.

SBOMs and security advisory information, although delivered separately, go
hand in hand.

I think this draft is pretty close to done. Adding security advisories to
it, in my opinion, would require changes to the introduction and security
considerations sections.

I think it's cleaner to leave security advisories out of scope for this.

Deferring to the WG sounds like a reasonable idea.

Thanks Eliot

On Thu, May 27, 2021 at 1:20 AM Eliot Lear  wrote:

> I don't mind.  If it helps I can relabel some of the containers to
> generalize.  Also keep in mind, the extension does not REQUIRE any elements
> in the MUD file.  But I think the WG should make a call on this.  If it is
> a bit far aways from the SBOM, we could write another draft.
> On 26.05.21 13:46, Patrick Dwyer wrote:
>
> I agree with all of that. Perhaps not on whether it belongs here though.
> This draft, so far, is completely focused on SBOMs. Not on vulnerability
> information or advisories.
>
> Perhaps it would be better served as a separate MUD extension and
> well-known URI?
>
> On Wed, May 26, 2021 at 4:39 PM Eliot Lear  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 different points of view on
>> this.  Some may simply be required to release an SBOM based on some
>> regulatory requirement.  Some not, and some may wish to release an SBOM
>> without using this mechanism.
>>
>>
>>
>>> > I also think this is one of those things that crosses a logical
>>> > boundary that is no longer about discovering and accessing an SBOM.
>>>
>>> That is true.  But not a huge stretch.
>>>
>>>
>> It's not a huge stretch. But this is also tied to a particular format for
>> this type of information. Personally I think CSAF is *the* format to
>> use. But that might not be the case in some particular industries and
>> countries.
>>
>> Yes.  I myself am hemming and hawing on this point a bit...  Let's just
>> delve into that a bit more:
>>
>> On the one hand, we have one really good candidate, CSAF.  On the other
>> hand, one might want to refer to the Old (more deployed) Stuff, which does
>> almost as good a job, CVRF.  On the third hand, it is possible that this
>> information could be included directly in a schema like CycloneDX, either
>> directly or as an extension.  On the fourth hand, the information could be
>> included as a reference by the underlying SBOM format, as you mentioned
>> earlier.
>>
>> So what are the principles here?  I think they are these:
>>
>>1. If the information exists outside the context of an SBOM, it
>>should be made known.
>>2. Don't make the end device do work.  Leave that to the network
>>management.
>>3. When there's one really overwhelmingly good candidate, use it and
>>don't overcomplicate the network management.
>>4. Provide some flexibility for the idea that these formats may
>>change.
>>5. Don't duplicate information elements.
>>
>> Some of these principles conflict.  Here's what I suggest:
>>
>>1. If the information is included in the SBOM there is no need for a
>>MUD file to include the new element.
>>2. If the information is NOT included in the SBOM, or the SBOM isn't
>>available, there is a need to provide the new element.
>>3. Let's change the name of the element from "csaf-location" to
>>"vulnerability-info", and make use of the same mechanism we used for SBOMs
>>to decide, with a suggestion that CSAF be the preferred initial format for
>>consumers.  This splits the baby a bit, but perhaps covers your concern?
>>
>> Also note that with CSAF I am taking a certain liberty to constrain the
>> CSAF reference in this case to contain a single product, so that we don't
>> get into a naming fiasco.  Naming.  I hate naming.
>>
>> Eliot
>>
>>
>>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Dick Brooks]

+1 I think it's cleaner to leave security advisories out of scope for this.

 

 

Thanks,

 

Dick Brooks



  Never trust software, always 
verify and report! ™

  
http://www.reliableenergyanalytics.com

Email:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: OPSAWG  On Behalf Of Patrick Dwyer
Sent: Wednesday, May 26, 2021 6:12 PM
To: Eliot Lear 
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

 

Just to be clear. I'm on the fence.

SBOMs and security advisory information, although delivered separately, go hand 
in hand.

I think this draft is pretty close to done. Adding security advisories to it, 
in my opinion, would require changes to the introduction and security 
considerations sections.

I think it's cleaner to leave security advisories out of scope for this.

Deferring to the WG sounds like a reasonable idea.

Thanks Eliot

 

On Thu, May 27, 2021 at 1:20 AM Eliot Lear mailto:l...@lear.ch> 
> wrote:

I don't mind.  If it helps I can relabel some of the containers to generalize.  
Also keep in mind, the extension does not REQUIRE any elements in the MUD file. 
 But I think the WG should make a call on this.  If it is a bit far aways from 
the SBOM, we could write another draft.

On 26.05.21 13:46, Patrick Dwyer wrote:

I agree with all of that. Perhaps not on whether it belongs here though. This 
draft, so far, is completely focused on SBOMs. Not on vulnerability information 
or advisories.

Perhaps it would be better served as a separate MUD extension and well-known 
URI?

 

On Wed, May 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 different points of view on this.  
Some may simply be required to release an SBOM based on some regulatory 
requirement.  Some not, and some may wish to release an SBOM without using this 
mechanism.

 


> I also think this is one of those things that crosses a logical 
> boundary that is no longer about discovering and accessing an SBOM.

That is true.  But not a huge stretch.

 

It's not a huge stretch. But this is also tied to a particular format for this 
type of information. Personally I think CSAF is the format to use. But that 
might not be the case in some particular industries and countries. 

Yes.  I myself am hemming and hawing on this point a bit...  Let's just delve 
into that a bit more:

On the one hand, we have one really good candidate, CSAF.  On the other hand, 
one might want to refer to the Old (more deployed) Stuff, which does almost as 
good a job, CVRF.  On the third hand, it is possible that this information 
could be included directly in a schema like CycloneDX, either directly or as an 
extension.  On the fourth hand, the information could be included as a 
reference by the underlying SBOM format, as you mentioned earlier.

So what are the principles here?  I think they are these:

1.  If the information exists outside the context of an SBOM, it should be 
made known.
2.  Don't make the end device do work.  Leave that to the network 
management.
3.  When there's one really overwhelmingly good candidate, use it and don't 
overcomplicate the network management.
4.  Provide some flexibility for the idea that these formats may change.
5.  Don't duplicate information elements.

Some of these principles conflict.  Here's what I suggest:

1.  If the information is included in the SBOM there is no need for a MUD 
file to include the new element.
2.  If the information is NOT included in the SBOM, or the SBOM isn't 
available, there is a need to provide the new element.
3.  Let's change the name of the element from "csaf-location" to 
"vulnerability-info", and make use of the same mechanism we used for SBOMs to 
decide, with a suggestion that CSAF be the preferred initial format for 
consumers.  This splits the baby a bit, but perhaps covers your concern?

Also note that with CSAF I am taking a certain liberty to constrain the CSAF 
reference in this case to contain a single product, so that we don't get into a 
naming fiasco.  Naming.  I hate naming.

Eliot

 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg