Minutes IETF108: opsawg
minutes-108-opsawg-00

What: Combined OpsAWG / OpsArea

When: 14:10-15:50 Tuesday Session III

Where: Room 3

OpsAWG Section

Administrivia - scribes, minutes, etc.
Tianran / Joe
5 minutes

Update on L3NM and L2NM
Oscar González de Dios
Draft:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
https://datatracker.ietf.org/doc/draft-bgbw-opsawg-vpn-common/
15 minutes

Joe Clarke: Are there any objections to breaking out the types into a common module? If there are then please go to the mic line.
No objections.
Jeff Haas: The refactoring is reasonable because the models are mature enough to find common stuff. Suggestion is to try and put common stuff in IANA maintainable and extendable modules.
Hum: If you feel that this common definitions should be in a standalone document.
Result: Forte
Hum: If you feel that this should be included as part of the L3NM draft?
Result: Pianissimo
Joe: Conclusion is that it should be in a standalone draft (to be confirmed on the list)

Presenting on restructing L3NM module:

Benoit: Does part of the YANG doctors review need to be redone if the groupings are moved into a common draft? This issue has been answered on jabber by Mohamed.

Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
Thomas Graf
Draft:
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/
5 minutes

Joe: Are there any comments for this work, for those who have read it?
No comments.
Hum: If you support adopting this work in OPSAWG
Hum result: Piano
Joe: Will take this to list and do a call for adoption there. Without the chair hat this seems like useful work, you have done the due dilligence to talk to the Segment Routing folks.
Comment from Benoit in the chat: Expert Review is enough, for WG review doesn't hurt

Software Bill of Materials (SBOM) Extension for MUD
Eliot Lear
Draft:
https://tools.ietf.org/html/draft-lear-opsawg-mud-sbom-00
10 minutes

Michael Richardson: Great work, hope we adopt. Business regarding telephone call is interesting. Trying to work why having a well known URL and don't just put it into the URI
Eliot: Many devices might be using the same MUD file. ...
Michael: Strange to enumerate CoAP, HTTP there ... strange that a device can provide a SBOM but the MUD file is elsewhere.
Eliot: Use case is when the device is not capable. THe device only gives a MUD URL. E.g. consider a simple device that doesn't have any mechanism to fetch the SBOM.
Jeff Haas: (1) Will probably need to provide more structure to the SBOM components. (2) Giving the ability to retrieve stuff via URI. Document that is retrieved from the URI needs to have some form of checksum. (3) This might then force some type of versioning.
Eliot: Would love to have some help.
Warren: For many things, okay having a software BOM if I have a relationship with. If I am just selling a lightbulb I might not want to share the list of libraries used.
Eliot: (1) Nobody is forcing anyone to produce the SBOMs. Particular industries might force them. (2) The information can be authorized. Might point the person to the cloud, which requires authorization. IETF should not impose policy here, but have flexibilty to allow policy.
Warren: If you create a standard they will come. I.e. if it part of a standard then regulators may demand it.
Eliot: Cannot stop regulators from making silly requests. Perhaps don't take a position about how useful these are. Or we could take the alternative approach of saying that these are really useful and everyone should do this.

Doug Montgomery (from chat): Maybe the SBOM should always just point to a manifest that we define (including checksum, etc).15:55:26
Michael (from chat): @Warren, it's PRECISELY that lightbulb that people want to know the SBOM for.15:56:06
Jeffrey Haas (from chat): What I'm mostly arguing is the manifest needs a bit of structure for audit and enumeration, and the sbom record needs the ability to identify a specific version of the manifest15:56:16
Doug Montgomery (from chat): Agree. I was thinking that the SBOM Manifest could provide a level of indirection for all the possible encoding formats.15:57:32
Warren Kumari (from chat): @MCR: Yes, but the lighbulb mfgr might not want to share that... if the standard exists people may be forced to publiosh using it.15:58:00
I personally think it is useful, but....15:58:36
Michael (from chat): yup, some regulator might insist, and that's not really our problem.15:58:37
Doug Montgomery (from chat): Large user communities are already requiring these ... I don't think the existence of an interoperable signalling message will change that.15:58:55
Michael (from chat): @Doug, the SBOM is signed.15:58:56

A YANG Model for Network and VPN Service Performance Monitoring
Bo Wu
Draft:
https://datatracker.ietf.org/doc/draft-www-opsawg-yang-vpn-service-pm/
10 minutes

Rob wilton: How much maturity does this draft have? How much discussion occurred in BESS?
Qin: Discussed in BESS and determined not in BESS scope; BESS chair has concerns, so some revision was done to clarify those concerns. Also checked with Routing Area AD, but didn't get feedback yet.
Rob wilton: Sounds interesting; needs comments.

Tianran: Is this related to L3NM or L2NM?
Qin: This is fairly agnostic; can be related to either L2 or L3
Tianran: Is that complementary to L2NM and L3NM?
???

Source Address Validation Architecture (SAVA): Intra-domain Use Cases
Dan Li
Draft:
https://datatracker.ietf.org/doc/draft-li-sava-intra-domain-use-cases/
10 minutes

Eric Vyncke: Suggest presenting this draft in Ops Sec WG
Yunan: Yes, we intend to put this work to OpsSec WG, but there was no session this time.
Joe: Any other comments on this work?
None

Ops-Area Section

Administrivia - scribes, minutes, etc.
Warren / Rob
15 minutes

Warren: Discussing idea of IoT operations and onboarding WG; still early, just giving a heads up

Service Assurance for Intent-based Networking (SAIN)
Benoit Claise & Korian Edeline
Draft:
https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assurance-architecture/
https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assurance-yang/
20 minutes

Tianran: Should this be in NMRG?
Benoit: Presenting both in NMRG and OpsA; since we want to standardize and present a YANG module, this fits in opsawg; we believe we've done the research part with the PoC and HAT
Warren: Thank you Benoit and for showing up for the session; please continue the conversation on the list; interesting in NMRG but work should happen in IETF (contributor view)

Open Mic