Notes for the NETMOD 116 WG Session

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

Session:

Friday 2023-03-31 09:30-11:30 JST (00:30 - 02:30 UTC)
Room: 4th floor, G412-G413

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)

Available During Session:

MeetEcho:
https://meetings.conf.meetecho.com/ietf116/?group=netmod&short=netmod&item=1

Onsite tool:
https://meetings.conf.meetecho.com/onsite116/?group=netmod&short=netmod&item=1

Audio Only: https://mp3.conf.meetecho.com/ietf116/netmod/1.m3u
Zulip: https://zulip.ietf.org/#narrow/stream/netmod

Available During and After Session:

Notes: https://notes.ietf.org/notes-ietf-116-netmod#both
Slides: https://datatracker.ietf.org/meeting/116/session/netmod
Drafts (TGZ):
https://datatracker.ietf.org/meeting/116/agenda/netmod-drafts.tgz
Drafts (PDF):
https://datatracker.ietf.org/meeting/116/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/116/session/30184.ics

Available After Session:

Recording: http://www.meetecho.com/ietf116/recordings#NETMOD
Jabber Logs:https://www.ietf.org/jabber/logs/netmod

01) Session Intro & WG Status

Chairs (10 minutes)

Qin Wu: draft-ietf-netmod-node-tags-09 is ready, waiting for feedback on
the mailing list

Lou Berger: We have received a liaison.

Scott Mansfield: ITU are also interested in this work, expect a similar
liaison statement.

Charles Eckel: It is important to give a liason response to the 3gpp.

Lou Berger: We'd like to see response text sent to the list (or can send
to the chairs)

Chartered items:

02) 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-11

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model-08

start: 9:40

Rob Wilton: About expired reference: is it informative?

Scott Mansfield: yes, we can probably get rid of it

Qin Wu: Could link with the attachment circuit work instead.

Lou Berger: careful not to get too bogged down in that - we want to keep
things moving forward

Rob Wilton: Is the attachment circuit draft that you referenced a device
level or network level model?

Qin Wu: It can be used for both.

03) YANG Versioning Update and Discussion (30 min)

Presenters: Tom Hill and Joe Clarke

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-08

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

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison-02

Start 9:44

Tom Hill presented an overview/update of the general work.
No questions.

Joe Clarke presenting on Schemma Comparison (i.e., current work)

---

Some exchanges happened on the chat at this point related to slide 7 of
Joe's presentation (prefixed here with 'chat:')

chat: Michael Richardson
I assume counter_t has more bits of precision than uint8_t :-)
30 March 2023 at 20:58:27 PM EDT

chat: Jason Sterne
We probably need to more carefully define that example. We're still
debating a lot of these cases in the weekly calls and haven't worked
through all the details.
30 March 2023 at 20:59:33 PM EDT

chat: Per Andersson
It was a bit contrived example, and not presented in full, but the idea
is that the base type for counter_t is uint8
30 March 2023 at 20:59:39 PM EDT

chat: Jason Sterne
In that case, we might not classify that as NBC even in the schema
algorithm.
30 March 2023 at 21:00:15 PM EDT

chat: Jason Sterne
But if we rename a typedef that is being used by that leaf, then that
would be NBC in the schema algorithm.
30 March 2023 at 21:00:40 PM EDT

chat: Michael Richardson
Ah so, uint8_t -> counter_t is just a change of typedef, not increased
number of bits. CBOR, JSON and XML mostly do not care about the
transfer.
30 March 2023 at 21:01:08 PM EDT

---

back in the main meeting:

Jeff Haas: Comment on slide 7. We need to define if counter_t has the
same base type or not. If counter_t is also a uint8 (and maybe only
added a 'unit' or 'description') then this change may be of interest to
flag in the output, but may not be NBC.

Joe Clarke: if the new typedef added a 'units' then maybe that doesn't
change "on the wire" (algorithm 1) but it may change the "schema"
(algorithm 2).

Jeff Haas: Changes of typedefs that have regular expressions (patterns)
aren't really possible to analyze (e.g. IPv6 address patterns are
described with two totally different patterns (textually) but they have
the same semantics).

Joe Clarke: Yes, same for 'when' and 'must'. We will perhaps use
'potentially-nbc' as the output for these cases.

Qin Wu: For on-wire perhaps we are just trying to identify syntax
changes. For schema we are checking more.For a description change, do we
use the on-wire algorithm or the schema-algorithm?

Joe Clarke: Description change could affect how the value are
interpreted, so it might be NBC even if the on-wire format does not
change. Even though the client sends the same data, it may result in a
different behavior on the server so we may have to flag that even for
the on-wire algorithm.

Qin Wu: on-wire may be easier to implement. Schema comparison may be
useful but difficult. Are we going to mandate that both algorithms are
mandatory or that one is optional?

Joe Clarke: some of the output of this work may be reference code. Not
sure what will be mandatory to implement yet. Maybe pick a reference
tool like pyang that would have both algorithms.

Qin Wu: how to report this? Does the output differentiate between
whether the issue was found by the on-wire algorithm vs the schema
algorithm?

Joe Clarke: Reporting is still an open question, do you use --schema or
--on-wire, is the output json? Same with level of verbosity in the
output - do we keep all potentially-nbc in the output by default or not?

Lou Berger: What encodings do you have in mind for on-wire algorithms?

Joe Clarke: We have not discussed any encodings within the contributor
group yet (e.g. binary, CBOR, etc).

Rob Wilton: for encoding it comes down to whether we're embedding
typedef name in the output.

Lou Berger: The example with uint8 -> counter_t would perhaps change
(or not) for a binary encoding but maybe not for an XML encoding.

Rob Wilton: The size would maybe change in a binary format and that
would then be flagged (e.g. uint8 to uint32).

Lou Berger: feels like a slippery slope - lets see where the work
progresses

Jason Sterne: We will have to take different encodings into account,
even non-IETF formats as e.g. gRPC. For on-wire algorithm maybe typedef
name changes aren't reported, but for the schema algorithm it would be a
NBC change. The schema algorithm uses the full rules from Module
Versioning (typedef name change = NBC). The big question is whether an
on-wire algorithm, with a subset of rules, is useful for users/clients
(who aren't augmenting, composing, etc - don't care if a typedef was
renamed).

Carsten Bormann: Biggest challenge in CBOR is when you put something in
a union, the encoding has to change. A totally different encoding is
needed when a union changes. That is always NBC.

Joe Clarke: yes - as Jason mentioned we will have to take that into
account.

---

Some exchanges related to 'encoding' happened on the chat towards the
end of this presentation, shown here prefixed with 'chat:')

chat: Christian Hopps
integers and strings are strings in xml
30 March 2023 at 21:10:40 PM EDT

chat: Alex Huang Feng
Shouldn't the encodings be covered by other rfc such as yang-CBOR or
yang-json ?
30 March 2023 at 21:11:11 PM EDT

chat: Christian Hopps
and very different things in binary :)
30 March 2023 at 21:11:14 PM EDT

chat: Michael Richardson
yang-CBOR is RFC9254.
30 March 2023 at 21:13:05 PM EDT

chat: Jason Sterne
The encodings are covered elsewhere, but what we define as NBC in the
on-wire algorithm will have to take into account all the encodings that
we want to consider. (which should include CBOR, gRPC IMO)
30 March 2023 at 21:14:43 PM EDT

chat: Lou Berger
(as contributor) I'm very warry of going down a path where yang ends up
being encoding "aware"
30 March 2023 at 21:14:44 PM EDT

chat: Christian Hopps
It seems to me that "on-wire" compatability has a lot to do with the
chosen transports encoding
30 March 2023 at 21:14:52 PM EDT

chat: Christian Hopps
it might even be the definition of "on-wire"
30 March 2023 at 21:15:21 PM EDT

chat: Jason Sterne
Maybe. But what if we said the only differences for on-wire is that it
ignores typedef name changes & grouping name changes (at the limit)?
30 March 2023 at 21:15:40 PM EDT

chat: Joe Clarke
The on-wire (as Jason mentioned) is more of, "will this break the
client". And one open question is still config v. oper. So on-wire has
been initially construed as will it break the client from a config
standpoint.
30 March 2023 at 21:20:21 PM EDT

---

04) System-defined Configuration (10 min)

Presenter: Qiufang Ma

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config-01

Start 10:15

Rob Wilton: The question of running being valid needs further
discussion. Somewhat of an ambiguity in 8342. Some people may intepret
valid strictly (all leafrefs resolve, mandatory present, etc) but some
may feel that if 'intended' is valid then it implicitly means running is
valid by implication. If you have configuration you can comment out then
how can both running and intended be valid?

Kent Watsen: should we define validity as 'intended' being valid as NMDA
does?

Rob Wilton: before you poll I wanted to mention that we could have a
solution where we define different sematics for NMDA servers vs pre-NMDA
servers.

Poll Question: WOULD IT BE OKAY TO MOVE TO NMDA'S INTERPRETATION NOW?
(THAT RUNNING IS VALID VIS-A-VIS INTENDED)
Poll Results: Few participated, no clear conclusion.

Lou Berger: Not a lot of uptake on the poll. Many people may feel as I
do that this needs more discussion.

chat: Balázs Lengyel
referenced by instance-identifier should be considered

Rob Wilton: (referring to slide 5) my intuition is that
"resolve-reference" should copy all items necessary to make the config
valid.

Charles Eckel: Could this mechanism address the "isInvariant" needed for
3GPP? Or do we need two mechanisms here?

Quifang Ma: Reasons for two documents, 1) system config work now focuses
more on general system config issue without defining any explicit flag
to indicate immuability; 2) while immutable document is derived from
system configuration, we do not want it to be limited to system config.
There are cases for immutability beyond system config so it is its own
separate draft.

Charles Eckle: it would be nice to have one mechanism that meets both
requirements (3GPP and other NETMOD system config uses)

Balazs Lengyel: Two items: 1) autocopy cannot be defferred to the commit
because you might need to copy nested objects and it will need several
commits to do so. So I don't think autocopy can be deferred to the
commit. 2) Some people want to use immutable even without system config.
So that's another reason to keep it separate.

Non-Chartered items:

05) Security Considerations Template for YANG Module Documents (10 min)

Presenter: Kathleen Moriarty

Draft: https://datatracker.ietf.org/doc/draft-moriarty-yangsecuritytext-02

Start 10:30

Glenn Dean: This may be the first time a trust issue has come to a
technical WG for presentation. Minor change but will help IEEE to use it
properly.

Rob Wilton: Kent raised the question with netconf work of keystore
drafts of how to properly populate the yang security section. We might
have too much stuff in this section and may need to cut it down. But
this is quite pressing. Suggest to pull this through the process
quickly, and make an RFC, to keep liason relations good, then maybe
create a bis (of this new RFC) to update the actual template text.

Kathleen Moriarty: So you mean AD sponsor this as an RFC?

Lou Berger: Can you re-state what you're looking for from this WG?

Kathleen Moriarty: Move this quickly as an AD sponsored draft. Raise the
modification of the template text as a separate issue, to be dealt with
in another forum (in a bis draft of this RFC once published).

Lou Berger: I would expect this to come to OPS area because it comes
from the wiki. Let's do what is expedient though (here or OPS).

Benoit Claise: It was put a wiki because it was changed a number of
times in the past, and changes should be easy to do. But now we want to
do this as 'track'. So what is the process for that? Are we losing
flexibility in doing what is right for updates?

Kathleen Moriarty: Note it hasn't been updated since 2018 so it is
reasonably stable. Although the group is talking about potential
updates.

Glenn Dean: This path is so IEEE can make use of it as a reference for
license material. Because it is an external org we had to go this path.

Lou Berger: I'm still uncertain of the specific ask from teh trust. Can
we just update it on the wiki?

Kathleen Moriarty: No. That was the problem.

Glenn Dean: We can't do that, because the Trust provisions need a
document to reference. We can't license out the wiki. We don't want to
cut a specialized license for this. Publish an RFC, wrap it in these two
tags, and you're good to do. Extenal orgs can take that text, modify as
needed, and publish. Must be via RFC not wiki.

Lou Berger: I like the expedited solution. I would suggest to the trust
that they consider general licensing terms for the wiki so the next
person that comes along addresses that as well.

Glenn Dean: We'll take that under advisement.

Lou Berger: The action is on Rob to create a draft and what working
group to put it in.

Rob Wilton: There is a draft, and I'm happy to AD sponsor it directly
rather than putting it through any WG.

Michael Richardson: Thanks for the slide. I didn't get this
understanding from the document (that may need clarification). Was it
really necessary to have this as an RFC and no other place we can do
this?

Kathleen Moriarty: Yes. We looked and this is the only way forward.

Michael Richardson: does this new document constrain us to not keep
using the wiki internally? Updating it there, etc?

Glenn Dean: We don't have the means to license out text from the wiki.
The wiki is fine for internal IETF use and process.

Michael Richardson: Fair enough. Let's get it done as quickly as
possible then.

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

Presenter: Qiufang Ma

Draft: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag-05

Start 10:40

Jason Sterne: [Referring to slide 8]. The slide says the only way to
change an immutable leaf is to delete and re-create it. If a candidate
is supposed to be declarative (i.e. what I want to achieve), shouldn't
it be the server that automatically deletes & re-creates in order to
achieve the desired configuration? The candidate would accept the new
value and the flag would just warn the user that the parent object would
be deleted/re-created by the server.

Qiufang Ma: I think it should be the client to delete and re-create.
There may be a traffic disturbance if the server deletes and re-creates.

POLL: IMMUTABLE - QUESTION FOR GROUP: IS IT TIME TO ADOPT? almost half
participated, almost all supported. -- expect adoption call on list

Kent Watsen: I wanted to answer Jason's question. Qiufang said it
correctly - nothing changes. There is no new run-time behavior being
asked by the server. The server only has to ferry a document to the
client. No new run time behavior on the client either. If they don't
want to look at the document they don't have to request the document.
But if they wish to have more knowledge about how the server behaves
then they can request the document. So just goodness I think in that
regard.

Balazs Lengyel: No new behaviour on the server, only here to model
existing behavior. Some of these behaviors in 3GPP have been around for
decades and aren't going to modify this. But they want to be able to
document this in YANG. Either we serve them e.g. 3gpp and ITU or the
behaviour is put in proprietary solutions or in description text etc.

Jan Lindblad (from chat): The requirements to serve 3GPP and ITU can be
fulfilled without removing core YANG principles.

07) Representing Unknown YANG bits in Operational State (10 min)

Presenter: Jeff Haas

Draft: https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits-01

Start 10:54

Jason Sterne: This is a modelling convention. Is this an informational
RFC? I could see many such proposal for various modelling
proposals/templates. Do we need to define applicability?

Jeff Haas: I would recommend a proposed standard for the type, user
should have freedom of using it or not. No mandate. Users have freedom
to use whatever modelling techniques they want. This is just a tool in
the toolbox.

Alex Clemm: How do you avoid the versioning problem? You still need to
change the model.

Jeff Haas: Indeed, there is a change in terms of schema presentation
(the unknown bits change, this is expected), should not be NBC but it is
an upgrade.

Balazs Lengyel: actually this does modify the NBC rules, a change in the
schema (specifying unknown bits) could be considered as backward
compatible. Probably needs to be documented in the RFC

Jeff Haas: I think of this as an upgrade, but interested in hearing the
WG opinion on how it should be treated (wrt to BC vs NBC, markings)

POLL: QUESTION FOR GROUP: ARE YOU INTERESTED IN WORKING ON UNKNOWN BITS:
YES = YES; HANDS DOWN = NO; NO RESPONSE = NO OPINION

Lou Berger: about half responded, of those overwhelming supported

08) YANG lessons from BGP YANG work (10 min)

Presenter: Jeff Haas and Mahesh Jethanandani

No associated draft

Start 11:03
No time for questions.

chat: Qin Wu
@Mahesh, do we have strong agreement to delegate thing to IANA? would it
be great to provide more examples to help understand how this practice
is excercised
30 March 2023 at 22:14:40 PM EDT

chat: Benoît Claise
Next, we'll follow the same process for the topology-related YANG
modules (what we call the Digital Map)
30 March 2023 at 22:15:05 PM EDT

chat: Lou Berger
straw poll - should we have an interim to discuss lessons learned?
30 March 2023 at 22:17:14 PM EDT
[a few folks supported this idea in the chat]

chat: Qin Wu
I think it is a good idea, I have resonance on packing model for test
and validation. We have see a lot of initiate to do this.
30 March 2023 at 22:18:40 PM EDT

chat: Joe Clarke
+1 on the BGP work. Also interesting to see the OC "donation".
30 March 2023 at 22:14:42 PM EDT

chat: Jeffrey Haas
We decided to change direction from several things in the oc module.
Many of our motivations for such are differing agendas between the orgs.
IETF cares about all the stuff, oc is an operational focused subset.
But it’s important to recognize the history and contributions. We’ll
likely borrow ideas both ways over the maintenance life
30 March 2023 at 22:18:47 PM EDT

chat: Jeffrey Haas
One bit of work mahesh skipped in the slides is how collaboration tools
for integrated testing, draft generation and model validation was
incredibly helpful.
Some baseline tools like we used that are IETF supportive would be
generally helpful to the organization.
30 March 2023 at 22:20:47 PM EDT

chat: Juan Cardona
Some kind of tooling for model examples, model coverage, etc for ietf
models could be very useful.. I would even dare to say that it should be
mandatory. Jeff, what tools did you use?
30 March 2023 at 22:25:04 PM EDT

chat: Jeffrey Haas
The usual tools.
Just inside a docker container with good make files
No need for local installs
30 March 2023 at 22:30:42 PM EDT

09) Incident Management for Network Services (10 min)

Presenter: Chong Feng

Draft: https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management-00

Start 11:13

Balazs Lengyel: We had a very similar discussion in 3GPP about alarms
and incidents. Alarms can be very low level (e.g. one interface is down)
or can be very high level (e.g. 1/2 of network is down). An alarm could
be based on dozens of counters and states. So we don't really need a
different mechanism in addition to alarms. Is the information provided
by an incident different than provided by an alarm?

Rob Wilton: take a look at the SAIN documents (in RFC editor queue). How
is this different and can this be done as augmentations on that model?

Qin Wu: We try to align with TMF and we're aware of 3GPP. incidents are
different from traditional alarms because they focus more on the service
level. Try to provide more abstration and reduce load on the higher
level management systems.

Benoit Claise: Advantage of this work is that it is trying to map two
different worlds: TMF (top down) and IETF (bottom-up), which we have to
do. This is the first attempt to do this matching and I've known we need
to do this work for a long time. Thank you for this work.

10) ANIMA yang-data/sx:structure, RFC8366bis discussion (10 min)

Presenter: Michael Richardson

Draft: https://datatracker.ietf.org/doc/draft-ietf-anima-rfc8366bis-07

Start 11:24

Michael Richardson: There is an example repo where I put all these
methods we tried togeher into a simple version. A link is on the mailing
list.

POLL: INTEREST IN INTERIM FOR VOUCHER CONCERN?

Lou Berger: Even if not all participated there is enough interest for an
interim.

Unscheduled time (0 min)