Minutes for the NETMOD 118 WG Session

https://datatracker.ietf.org/meeting/118/materials/agenda-118-netmod
https://datatracker.ietf.org/meeting/118/session/netmod

Session:

Tuesday, November 7, 2023
13:00-15:00 Prague (Central European Time)
12:00-14:00 UTC
Room: Congress Hall 3

WG Chairs:

Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)

WG Secretary

Jason Sterne (jason dot sterne at nokia dot com)

Session Information:

Notes: https://notes.ietf.org/notes-ietf-118-netmod
Slides: https://datatracker.ietf.org/meeting/118/session/netmod
Zulip (chat):
https://zulip.ietf.org/#narrow/stream/126-netmod/topic/ietf-118
Drafts (TGZ):
https://datatracker.ietf.org/meeting/118/agenda/netmod-drafts.tgz
Drafts (PDF):
https://datatracker.ietf.org/meeting/118/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/118/session/31616.ics

Recording:
https://www.youtube.com/watch?v=IcVarlAhAdA
https://play.conf.meetecho.com/Playout/?session=IETF118-NETMOD-20231107-1200

Jabber Logs: https://www.ietf.org/jabber/logs/netmod

1) Session Intro & WG Status (10 min)

Presenter: Chairs

Chartered items:

2) Common Interface Extension YANG Data Models, Sub-interface VLAN YANG Data Models (10 min)

Presenter: Scott Mansfield
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang-12
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model-09

Notes:
Lou Berger: Please try to reolve the identified open issue on the list,
and then we can move to last call both documents together.

3) System-defined Configuration (10 min)

Presenter: Qiufang Ma
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config-04

Notes:

Kent Watsen: Mentioning that running must be valid but without
specifying whether that means on the server or offline is a clever way
of letting us move forward without getting stuck on the details.

Maybe we need to separate into two parts? 1) long term theoretical
whether running should be offline validatable alone vs 2) do we need to
wait for YANG NEXT to change/clarify offline validity of running

Rob Wilton: Let's have a dedicated interim. I don't think we can skirt
this issue.

Kent Watsen: Agree

Rob Wilton: (re origin of system data copied into running) I'm not sure
of the answer, but we should specify it.

Kent Watsen: Origin is in operational only today, should we add it to
running? The question of whether to upgrade (migrate) nodes in running
may be connected to this issue of origin. Maybe upgrade migration only
happens on nodes with certain origins in the running.

Lou Berger: We should try and find a way of resolving the issues and
scheduling an interim may help with that.

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

Presenters: Oscar Gonzalez de Dios
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions-03

Notes:

Rob Wilton: I don't have a strong preference on the 2 options, augment
vs bis (just continue with what you have now)

Mahesh Jethanandani: As author of ACL draft I prefer a bis

Lou Berger: who read this? who thinks the current approach is good? who
wants a bis?

POLL 1: Who has read the draft?

RESULT: about 1/4 of room

POLL 2: If you read the draft, do you think it is ready for Last Call?

RESULT: most (all but 1) said yes

Joe Clarke: Might want to use the base module without the augmentation.
Bis would be more required if you need the new items as part of basic
use of the module.

Rob Wilton: If you do it as a bis, you can focus on the changes. Bis
doesn't have to be particularly heavy although you can't really stop
people from reading/commenting on the rest of the document.

Lou Berger: I like the augmentation better (as individual).

Lou Berger: The chairs will discuss off line and will likely proceed
with last call. If you were the "no" for the doc being ready please send
a note on the list.

5) YANG Versioning (45 min)

Presenters: Jan Lindblad and Joe Clarke
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-10

Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver-12

Notes:

Discussion of T7 (filename):

Italo Busi: (re issue T7, filename) It is better to wait for next YANG
version. Date is main identifier for now. It is a tag. Maybe in next
version we should reverse and use the label. Avoid having 2 different
ways to name the modules.

Lou Berger: When do you think the next version would likely be?

Italo Busi: Soon

Lou Berger: YANG NEXT is going to take a while

Italo Busi: That's OK

Kent Watsen: I second Italo's comment entirely. When we switch to labels
that should be the only way to do it.

Per Andersson: I did a hackathon to add a label to the filename in
pyang. It was pretty easy actually. I think we should do it now.

Lou Berger: As contributor - I'm concerned about vendors doing their own
thing. I'd rather have a format specified.

Discussion of T8 (recommended-min):

Per Andersson: if not in order, produce a warning

Kent Watsen: The word recommended isn't saying it has to be followed. If
it less than recommended-min it is just a warning. In YANG NEXT we could
make it more strict?

Rob Wilton: We started with this being stricter. Got push back from the
WG that changed YANG too much. So we softened it. Other opinions have
been expressed that maybe dependency information should be outside the
module (e.g. packages, library, etc). Branching adds some complexity.

Kent Watsen: can't quite follow that - needs clarification offline.

Lou Berger: There isn't a specific question on the slide.

Jan Lindblad: We're split on this in the weekly call group.

Lou Berger: Split with 2 camps or a lot of "not sure / don't care"?

Rob Wilton: Some people think this is important. Others feel it is
blocking the work.

Lou Berger: so nobody is opposed? More about getting this work done.

Rob Wilton: correct

Kent Watsen: it seems like recommended-min is a compromise to allow it
to go through.

Rob Wilton: I think we'll end up with the same solution even if we delay
this work.

Jason Sterne: I echo what Kent said. This was weakened from a
conformance statement to a recommended min to allow us to keep it in the
work. I'm in favor. It is simply machine readable info for users or
people constructing packages.

---

From the chat:

Balazs Lengyel: Import min is useful. Lets included it as a
recommendation and warning. I agree with Ken.

Joe Clarke: I, too, am in support of some kind of min signaling. I was
more in favor of strength, but I can live with the warning in 1.1.

Balazs Lengyel: Not needed as backwards compatibility is not even
defined for instance data.

Per Andersson: Keeping it as a warning and not enforcing would give
implementors freedom to use compatible models if they know what they are
doing and can ensure compatibility.

Per Andersson: recommended-min I mean

Joe Clarke: Yep. I think it's good to keep.

Rob Wilton: @Kent, I see the reason for softening the import min-rev
text for 3 reasons:
(1) Because it is better to keep strict conformance out of YANG modules
(i.e., put it into packages instead)
(2) Because there are cases (with a branched history) where a different
version of the file is valid, but would fail a strict min-rev check.
(3) To get the work done (which was a lowest priority)

Per Andersson: It adds value with recommended-min right away also,
letting module authors signal to implementors how to use and what to
expect

Lou Berger: would really prefer (non) compatible was in metadata, but
can live with plan

Rob Wilton: non-compatible is also in meta-data as the extension
statement

Lou Berger: okay, sure...

---

POLL: WRT T8: Is min need now? YES=keep, NO=Defer to YANG next.

RESULT: split with a slight leaning towards yes.

POLL: WRT T8: Is recommended min need now? YES=keep, NO=Defer to YANG next.

RESULT: Same as immediately previous poll - split with a slight leaning
towards yes.

Lou Berger: Don't select yes for both polls.

Discussion of T9 (instance data):

Lou Berger: Can you live without this?

POLL: T9: Can you live without versioning of instance data?

RESULT: not huge participation, but 100% say "yes"

Discussion of T10 (insignificant whitespace):

Lou Berger: The other one that I'd like is "should whitespace be
included in a checksum". Yes - you'd need a pre-processor.

Rob Wilton: This is really the question: do we want to be able to do a
checksum using plain text.

Jason Sterne: on implication if we don't require it to be a separate
version, is imagine an author publishes two versions with different
whitespace (e.g. shrink line length), then there might be two copies of
that version 3.0.0 floating around. We should bump the editorial version
at least.

Lou Berger: So it would not have a digit change - it would be the
identical.

Jan Lindblad: Two different modules with different checksums (if they
include whitespaces), but it is the same module.

Kent Watsen: We've never talked about checksums before. Is it so
important?

Jan Lindbald: Checksums are useful when versions are floating around to
know exactly which one we're talking about.

POLL: Should whitespace be considered for the revision label?c.

RESULT: A good number of people answered with a 3:1 ratio preferring to
ignore whitespace.

Italo Busi: When I download YANG files from different sources, sometimes
there is an extra line at the end and sometimes there isn't. It would be
confusing if those are different versions.

Joe Clarke: Jason mentioned versions "floating around". Jan mentioned
wanting to know which one is the "right one". If I care that I have
the canonical 3.0.1 and want to be able to go to the official source,
then we need the revision to include the whitespace.

Kent Watsen: If you were to use a canonical checksum where would it be
published.

Joe Clarke: Checksums.txt on the website where the

Kent Watsen: Checksum-ver instead of yang semver.

Balazs Lengyel: People aren't so precise and this newline at the end
will cause confusion. I'm in favor of normalizing before doing a
checksum. Reformatting a description is a significant change and outside
the scope of this discussion.

Discussion of items T1-T6:

Lou Berger: Clarification: these were sent to the list as the decisions
that have been made based on previous discussions.

Lou Berger: Silence means "you can live with this". I don't necessarily
agree with all of it, but I can live with it.

Discussion of YANG Semver:

Kent Watsen: If it says either of compatible or non_compatible, then
they still have to go to the revision history to understand the
relationship. So why have the suffix.

Joe Clarke: Correct. For lineage you have to look at history. But for a
quick understanding of compatibility you can just use the YANG semver to
know if you need to dig further.

Kent Watsen: So it means some patch changes can break things and some
don't?

Joe Clarke: Yes - because we can't increment anything else at that
point, so we add the modifier.

Ramkumar Rajagopalan: Why do I need that "compatible" extension in the
example? If there is no modifier it is compatible.

Joe Clarke: To indicate it isn't just a patch change. The change
includes some other BC changes (e.g. maybe a new leaf). Next step is for
authors to update the drafts based on the discussion.

Non-Chartered items: (went out of order)

8) Mounting YANG-Defined Information from Remote Datastores (10 min)

Draft: https://datatracker.ietf.org/doc/draft-clemm-netmod-peermount-00

Presenter: Alex Clemm

Ladislav Lhotka: avoid the name "mount" or we'll introduce confusion

Alex Clemm: This is different problem space. Schema mount is mounting
locally. This is federated data, about mounting instances on a remote
system

Jason Sterne: How does this deal with absolute leafrefs and paths in
"must" statements in the device models. Those won't make sense when
viewed from the northbound side of the composed controller model.

Alex Clemm: This isn't config so "must" statements don't matter

Jason Sterne: I'll take this to the list to avoid taking the rest of the
time

Rob Wilton: I thought schema mount was supposed to handle this scenario

Alex Clemm: That was alias mount and was different. I can see this is
confusing.

Lou Berger This is different. There are some similarities. We need to
take this to the list

Jan Lindblad: I read the draft and it is interesting, but there are many
open unresolved issues. This is not simple.

Ignacio Martinez-Casanueva: We have an alternative terminology to the
mount term we could consider: data virtualization

---

From chat:

Balazs Lengyel: I would call it remote-mount

Lou Berger: I agree - had the same comment

Lou Berger: I see this as akin to html caching

---

6) YANG Extension and Metadata Annotation for Immutable Flag (10 min)

Presenter: Qiufang Ma
Draft:
https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag-09

Balazs Lengyel: I'm concerned with the removal of the extension. 3GPP
has nodes where it is known at design time that they are immutable. 3GPP
will likely have to create their own extension since the IETF is
rejecting this need.

Rob Wilton: This WG should send a reply back to the 3GPP liaison
statement. Maybe we should rename it as "system config" instead of
"immutable"? One question, if a client writes to running, can a delete
request of that same data ever fail?

Qiufang Ma: If same value, you can add into running and can be deleted

Kent Watsen: Conversely, if you can't add it to running, you can't
delete it from running

Rob Wilton: Fine, but it isn't that a client can add something to
running, and then the system says "fine, now that is locked and you can
never change it"?

Lou Berger: Isn't that the extension that was removed?

Rob Wilton: I thought the extension was just statically declaring this

Kent Watsen: Immutability isn't dependant on any client interaction, it
is purely server-defined

Italo Busi: 3GPP needs this extension but also other SDOs. It is better
to have one solution from IETF rather than each SDO doing their own
thing.

Lou Berger: 3GPP came to us to help them solve a problem (instead of
just taking what we have and changing it). I think it would be good for
us as a group to do that instead of telling them to do that in their
standard body.

Jan Lindblad: I think the contention here is really what immutable
means. Some concepts from 3GPP may not be compatible with YANG but there
may be a way to achieve the basic needs.

Balazs Lengyel: If you have the info at design time that a schema node
is always immutable, why not show that in the model rather than waiting
for that info in an annotation at run time?

---

From chat:

Rob Wilton: @Balazs, why is the data immutable. Rather than labelling it
as immutable, pehaps we can label it with what it is (e.g., perhaps it
is device capabilities) and infer from that the configuration is
immutable.

Lou Berger: or use a tag

Balazs Lengyel: @ Lou, Robert: The basic is to provide the information
in design time bit runtime. I as I understand tag is only available in
runtime.

Balazs Lengyel: @immutable: I can live with a different name instead of
immutable. The name is not so important.

Lou Berger: see section 3 of 8819 - tags are available at design time

---

7) A YANG Data Model for Interface Reference Topology (10 min)

Draft:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-if-ref-topo-yang-01
Presenter: Scott Mansfield

Olga Havel: Thanks Scott, I was thinking this same thing when I saw the
draft.

Kent Watsen: (as chair) Our understanding is there is a new "inventory"
WG that deals with things like topology. Might that be the right place?
NETMOD is a catch all if there isn't another group.

Qiufang Ma: IVY [Inventory WG] is the new WG and it may be a place for
this work.

Rob Wilton: I will help find the right home.

Bo Wu: I notice model is a network model, but adding an interface name
as a leafref.

Kent Watsen: Sorry Bo, but we're out of time for a question like that
now. Please take it to the list.

9) Model Driven Telemetry integrating YANG with Time Series Databases (10 min)

Draft: https://datatracker.ietf.org/doc/draft-kll-yang-label-tsdb-00
Draft:
https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist-00
Presenter: Jan Lindblad

Kent Watsen: Which parts of this work should be in which WG? Maybe
splitting the work?

Jan Lindblad: Maybe the mapping part in NETCONF and the framework part
in NETMOD?