The draft minutes for our session today are both below and uploaded here:
https://datatracker.ietf.org/meeting/112/materials/minutes-112-netmod
Please review and send any corrections to the chairs alias (CC-ed).
Thanks!
Kent (and Lou (and Joel))
# 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
-------------------------------------------------------
- Meeting material: https://datatracker.ietf.org/meeting/112/session/netmod
- WG Documents: https://datatracker.ietf.org/wg/netmod/documents/
## 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:
- ICS: https://datatracker.ietf.org/meeting/112/sessions/netmod.ics
- MeetEcho: https://meetings.conf.meetecho.com/ietf112/?group=netmod
- Audio Only: http://mp3.conf.meetecho.com/ietf112/netmod/1.m3u
- Jabber: xmpp:[email protected]?join
## Available During and After Session:
- Minutes: https://codimd.ietf.org/notes-ietf-112-netmod
- Slides: https://datatracker.ietf.org/meeting/112/session/netmod
- Drafts (TGZ):
https://datatracker.ietf.org/meeting/112/agenda/netmod-drafts.tgz
- Drafts (PDF):
https://datatracker.ietf.org/meeting/112/agenda/netmod-drafts.pdf
## Available After Session:
- Recording: http://www.meetecho.com/ietf112/recordings#NETMOD
- Jabber Logs: https://www.ietf.org/jabber/logs/netmod
## 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)
-
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-05
- https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-05
- https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages-02
- Discussion Leader: Balazs Lengyel, Bo Wu
_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)
- https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-00
- Discussion Leader: Qiufang Ma
_(+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)
- https://datatracker.ietf.org/doc/html/draft-dbb-netmod-acl-00
- Discussion Leader: Oscar González de Dios
_(+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)
-
https://datatracker.ietf.org/doc/html/draft-yg3bp-ccamp-optical-inventory-yang-00
- Discussion Leader: Aihua Guo
_The authors agreed to forego this presentation as they plan to proceed the
work in the CCAMP WG._
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
