Minutes IETF113: netmod
minutes-113-netmod-00

Draft Minutes inclusive of the agenda.

# 1) Introduction

   Chairs (10 minutes)
   Session Intro & WG Status

Charles Eckel In-room cooordinator.

Lou Berger speaking for intro

Mahesh Jethanandani: I will work with Rob on his (ethernet) documents.

# Chartered items:

##  YANG Versioning Update (45 min)

### 2) Title: YANG Versioning Update - Overview
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-05
  Discussion Leader: Joe Clarke

  :09
  Joe Clarke speaking

  Lou Berger - based on the update we'll decide if there needs to  be a second
  last call.

  No questions.

### 3) Title: Yang Packages
 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-06
  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages-03
  Discussion Leader: Jan Lindblad

:21
Jan Lindblad speaking

Charles Eckel: how do you envision -bis versions working? When changes look
like a deviation.

Jan Lindblad: deviations is not a way to communicate version changes. An update
is just a BC or NBC version update.

Slide 9: (API vs Implementation packages)

Lou Berger asks if the question regards the concept or realization.

Jan Lindblad: concept

Benoit Claise: I can see how the implementation option would be most useful.
Let's see if it gets used before spending too much time on it. (:38)

Tom Hill: exatly the opposite of Benoit I prefer API package so I can tell what
they support across vendors.

Lou Berger (as contributor): Agree with Tom that from a provider/user
perspective would like to specify what is desired (via API packages) and then
have vendors state what they support via an implementation package.

Scott Mansfield: (from chat) Was the point about listing conformance as part of
the package?

Benoit Claise: Going back to slide 8, API says what user/customer wants; the
implementation package says what the vendor is doing. Is this the right way do
represent this?

Tom Hill: it doesn't help if vendors use different APIs, need to be more
proscriptive.  Rather than query router "what can you do?", I want to say "do
this".

Rob Wilton (contributor): API package is giving the specification,
Implementation package says what the server is doing.

Jeff Haas: (missed it: 39) Would like to focus API package on dependencies.

Balazs Lengyel: it would be nice if a tool would enable discovery of what API
packages a module/package implements.

Jan Lindblad: The question was really whether making a distinction between API
and implementation packages is useful. I think we struck a cord here, based on
all the discussions spurred. Clearly the distinction between API and
implementation modules is a meaningful one to most people. Thank you.

## 4) Title: Self Describing Data Object Tags (10 min)
  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-06
  Presenter: Qin Wu

Qin Wu speaking: :53

Lou Berger (as contributor): On "Tag Managment Conflict Resolving" slide, not
sure why tags are any different than any other rw information.  So I don't
believe there is any unique issue here. The text change is fine, but unneeded.

Qin Wu: agree

Rob Wilton (as contributor): The module uses NACMs:instance-identifier typedef
which allows tags to either be for a specific data instance, or more
generically cover multiple instances (e.g., all instances of an MTU leaf).  I
think that this is the right thing to do, but it might be helpful if there was
some extra descriptive text to make this clear (if it isn't already there).

Lou Berger: chairs will discuss Last Call after the meeting.  Don't see any
reason not to.

# Non-Chartered items:

## 5) Title: System-Defined Configuration (15 min)
   https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02
   Presenter: Qiufang Ma

Quifang presenting (1:04)

Kent Watsen: On Slide 2, perhaps the WG should discuss if we should support in
<intended> first, not shy away from it just because there is a "when"
expresssion somewhere, especially as the update to the "when" expresssion would
because it expand the its scope and so wouldn't break existing models and we
can decide if it's worthing updating the other rfc

Rob Wilton (as a contributor): I have some concerns about whether running
configuration should always be required to be complete, or whether an
incomplete configuration should be mergable with system configuration before
validation.  An example is creating an interface with a default interface type
- should a client always have to specify this, or can a server use a system
value without injecting it into the running configuration?

Balazs Lengyel: Some SDOs specifify what must be created by the system, so
would be a problem if we restricted this in any way

Jan Lindblad: would like to ensure that existing clients don't break (Quifang
concurs).

Balazs Lengyel:

Jan Lindblad:

Balazs Lengyel: it would kill 3GPP YANG modeling
Jan Lindblad: Not at all. All you need to do is to make sure 3GPP clients and
servers implement flags to control this.

Balazs Lengyel:

Jan Lindblad:

Balazs Lengyel:

Rob Wilton (contributor): do you think it there should be a parameter (like
"resolve-system") to enable system-aware clients can ask the server pull-in
whatever <system> config needed?

Quifang Ma: yes, will present next.

Balazs Lengyel (on Slide 4): this is a show-stopper

Kent Watsen (contributor): this is a not approved approach, there was a
vigorous discussion on the mailing list, the system can act like a client to
avoid the server make changes.

Lou Berger: there's no RFC that precludes something automatically; this would
be a change in allowed behavior which we have to take into consideration

Balazs Lengyel: (in chat, after meeting ended?) I don't seem to be able to
modify the notes, so here are some comments also stated in voice:System:Balazs:
Other SDOs like 3GPP and O-RAN are using system-created data nodes. Their
design depends on them in some cases. Clients are not allowed to create these
list entries. Until now the system is allowed to modify the running
configuration. If we would prohibit this that would be a major
non-backwards-comptible change. I object to that. It would also need a YANG 2.0
revision. Even if we would prohibit the system to modify running, it would be
possible to work around it. The system instantiates an onboard client to do the
changes AND the system prohibits the change for other clients. However this is
just a more complicated way of stating that the system itself modifies running;
we gain nothing but make the world more complicated. While I agree that
system-created data nodes can be problematic sometimes it is a fact of life, so
we should not remove it.

## 6)  Title: Immutable Metadata Annotation (15 min)
   https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-00
   Presenter: Qiufang Ma

Qiufang presenting (1:32)

Rob Wilton (contributor) on Slide 5, has concern if servers decide some things
are immutable may break existing clients.  Having a parameter is a better
choice that always returning the data might be better.  Having this is as
annotation to indicate where immutable data exists, without encouraging it
might be a good solution.  Should also consider config-replace like operations.

Jan Linblad: agrees with Rob, restirctions make life difficult for clients, but
RFCs say already that rejection can happen already.

Qiufang Ma (to Rob and Jan): not introduce new restriction, just want to make
the information visible.

Balazs Lengyel: Generally supports work.  Some SDOs use invarient to represent
a similar concept. Some use immuable rules to say once created, cannot be
removed.

Rob Wilton: shouldn't encourage?

Balazs Lengyel: would like to agree
Balazs Lengyal: sometimes "immutable" can be specified in schema (YANG), i.e.,
don't need annotation.

Balazs Lengyel (in chat, after meeting ended?) Immutable:3 potential use-cases
for immutable: - invariant: once a leaf is created it cannot be changed -
capabilities that are created by the systems and client cannot modify them. Is
this better served by immutable or system data? - Immutable NACM rules that
must stay in place to protect some parts of the configuration from any
modification

## 7)  Title: Updated Common YANG Data Types for Traffic Engineering (10 min)
   https://datatracker.ietf.org/doc/html/draft-busi-teas-te-types-update-01
   Presenter: Italo Busi

Italo presenting (1:50)

Jeff Hass (from meetecho chat)- I can expand at mic, but BFD has had a similar
issue for RFC 9127-bis. Trivial change, painful process: 
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-02.  Short
form is process is too heavy weight.

Mahesh Jethanandani: provides BFD-bis experience (importance of the problem).

Rob Wilton (AD) could be a separate draft the "updates" this draft and only
updating the specific module.  Not supportive of putting diffs into the Apendix.

Italo Busi: (missed it)

Rob Wilton: could add a comment to RFC Editor and enables annecdotal text to be
removed before publication.

Jeff Haas: Some concern regarding how to handle other modules that "imports"
the updated module.  Issue being discussed on BFD list.

Lou Berger (as chair): Rob gave solution.  Separately, don't rely on tooling.

done at 2:03

### Note takers:

JJ = joel jaeggli
JS = Jürgen Schönwälder
MJ = Mahesh Jethanandani