Minutes IETF112: netmod
minutes-112-netmod-02

Meeting Minutes Network Modeling (netmod) WG
Date and time 2021-11-11 14:30
Title Minutes IETF112: netmod
State Active
Other versions markdown
Last updated 2021-11-11

minutes-112-netmod-02

Minutes for the NETMOD 112 WG Session

Our appreciation to the note takers!

Note takers:

  • Jason Sterne
  • Rob Wilton

Agenda for the NETMOD 112 WG Session

Session:

  • Thursday, November 11, 2021
  • Session II (14:30-15:30 UTC, 9:30-10:30 EST, 12:30-13:30 PDT)

WG Chairs:

  • Lou Berger (lberger at labs dot net)
  • Kent Watsen (kent plus ietf at watsen dot net)
  • Joel Jaeggli (joelja at bogus dot com)

Available During Session:

Available During and After Session:

Available After Session:

Introduction

  • Chairs (10 minutes)
  • Session Intro & WG Status

Lou Berger: Last document on agenda (draft-yg3bp-ccamp-optical-inventory-yang-00) is coming from CCAMP WG, may not have time to present, but generally would expect YANG models that could reasonably go to other WGs to go there - and this document will remain there.

Lou Berger: should be OK to move 6991-bis forward to WG last call, will wait a little to see if there are any proposed additions on the list (will move to WG LC in Dec)

Chartered items:

YANG Versioning Update (20 min)

Balazs presenting updates on changes (module versioning and semver), all documented on the slides.

Balazs Lengyel: The authors think that these docs (draft-ietf-netmod-yang-module-versioning-05, draft-ietf-netmod-yang-semver-05) are ready for WG LC.

Kent Watsen: Plan is to take these to WG LC, but then hold them until the 5 core versioning drafts are all ready and send them to the IESG as a set.

(+14 mintes into session, Bo presenting on YANG packages)

Lou Berger: Thank you and all contributors for the hard work and progress update. As a reminder, anyone can participate in the regular meetings. Try and repost weekly issues that are being discussed will help people identify which sessions to attend.

Non-Chartered items:

System-defined Configuration (15 min)

(+23 minutes into session)

Jason Sterne: Question about step 4 (on slide 5), would the origin there not be running rather than intended.

Qiufang Ma: There is no origin for running, only from intended.

Jason Sterne: For last bullet (slide 8), if the origin has purely specified in the system config, then it should be system, but if the config has been explicitly configured then it should be something else (e.g., intended origin).

Jason Sterne: There is going to be some confusion about how the origins merge, do might need more discussion about the system origin.

Kent Watsen (as contributor): Responding to Jason. For origin=system, when copied into running, everything copied would have origin=system, but descendent nodes would have origin=intended. On second point: (middle bullet point on this slide), should this work introduce into the intended datastore, a with-origin parameter when reading from intended. NMDA doesn't currently allow for this.

Qiufang Ma: The server must remember where the data comes from. Hence question is should we define the origin from the clients so that it comes from intended.

Balazs Lengyal: For third bullet, very common to do a show all config, copy it, and then replace it back. Need the system origin marking to know which config we don't need to push back.

Jason Sterne: Responding to Kent and Balazs. If someone does read from intended or operational, but not explicit declaring configuration in the running. Only advocating that if an operation explicitly declares configuring in running then the origin sees running.

Jan Lindblad: My main concern is that we are redefining RFC 7950 and 8342 in an incompatible way, and I'm concerned about that. Perhaps we should try and reverse the flags. I want everything to work as normal if anything if nothing new is specified.

Kent Watsen: Desire is to mimic the "default" annotation used in RFC 6243 for "explicit-mode" servers, so an explicit-client can signal to the server that the config is intended to be "system" or "running" (just like if a default value is intended to be the default or new config). More important open issue is that this work is perhaps requiring on YANG Next. E.g., a system-unaware client might get very surprised. We have to work through that detail.

Balazs Lengyal: For us the immutable flag is absolutely needed.
The with-system option should be the deault use.

Lou Berger: Out of time, we need to take further discussion on the list. Good discussion, if we get enough interest then we could always hold another interim.

From the Chat window:

Robert Wilton: As a contributor, I also agree with Jason on this point. The behaviour that he describes would also be consistent with how default values are handled.

Kent Watsen: me too
Balázs Lengyel: Agree. with-system is should be the default. The immutable lag is the most important part for us.

Extensions to the Access Control Lists (ACLs) YANG Model (15 min)

(+46 minutes into session)

Jason Sterne: On how to approach the work, but need some discussion on the list first. My initial feeling is that it might be better as a separate RFC that extends the base ACL model. What is meant by a network ACL?

Oscar: No, by network ACL, we mean an ACL that is replicated in several separate devices. E.g., to manage an ACL or particularly, a prefix list, from a central location. Define it once, and it applies to all devices (but downloading config to all devices).

Lou Berger: In general, it is a judgement call whether to augment or revise. We really need to get into the details. Similarly for the question about network vs device, we need to understand more of the details. Motivation is right on the presentation, but for the draft, focus on the new capabilities, then we can jump in to answering your questions. Nobody is saying this is wrong. We have heard that we need to understand the best way to do this, and also if there is WG support.

Oscar: Will look to revise the draft. We will identify what changes may break existing models.

Jason Sterne: Does any of this functionality mean stateful (e.g., firewall).

Oscar: Everything proposed so far is stateless.

From chat window:

Jeffrey Haas: It's important to distinguish the cases of exact match and mask-match for flags. And don't rely on enums for the bit names/positions. (or identities)

A YANG Data Model for Optical Network Inventory (5 min, time permitting)

The authors agreed to forego this presentation as they plan to proceed the work in the CCAMP WG.