Minutes for the NETMOD 117 WG Session

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

Session:

Monday, July 24, 2023 13:00-15:00 (local) (20:00-22:00 UTC) Session II
Room: Continental 5

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 and After Session:

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

Available After Session:

Youtube: https://www.youtube.com/watch?v=toJpkGEk6HI
Recording and Polls: https://www.meetecho.com/ietf117/recordings#NETMOD

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

1) Session Intro & WG Status

Chairs (10 minutes)

Notes:

Mahesh Jethanandani: WRT syslog draft - planning on posting the update,
but will wait on update to client/server drafts from Kent

David Sinicrope(as BBF liaison): We should something back to BBF.
Willing to help draft a response.

Chartered items:

2) YANG Versioning LC, Update and Discussion (60 min)

Presenter: Joe Clarke

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

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

Start time: 13:14
Notes:

Jason Sterne: (Clarification) Option 1 also applies to YANG 1.0

Lou Berger: is document listed as updating both?

Joe Clarke: It may not be. We may need to update that.

Rob Wilton: Jurgen's doc is a variant of option 1, i.e., something that
updates RFC 7950.

Joe Clarke: Yes.

Kent Watsen: Juergen's draft updates 7950, but results in a "1.2",
does that trigger same adoption concerns?

Joe Clarke: option 2 adds a longer road and effort for standardization
and adoption.ll

Jason Sterne: I think Jurgen's doc is Option 2 (a new version of YANG)

Lou Berger: I read Jurgen's doc as Option 2

Jason Sterne: As a vendor I can't just suddenly publish modules with
yang version 1.2 or new language keywords. I'd have to ensure they've
upgraded their toolchains to handle yang 1.2 first.

Balázs Lengyel: 3GPP publishes every 3 months and correct later. This is
what they're doing with YANG as well.

Rob Wilton: with AD hat on. Benoit made the point this is not an option.

** FIXME: WHAT DID BENOIT SAY? IT'S NOT CAPTURED!!! **

Jason Sterne: People have been using terms like "pragmatic exceptions".
I think that is Options 1 or 2. Publish rules that match that behavior.
That isn't option 3.

Joe Clarke: I personally think option 1 is the way to go. The 1.2 thing
is going to add too much delay.

Ahmed Elhassany: We should continue option 1 and 2 together. Do option 1
to move forward but a bit of a hack. But do option 2 to clean this up
for the next 10, 30 years.

Lou Berger: Can you clarify what you mean by both Option 1 and 2?

Ahmed Elhassany: Option 2 - make it as a built in part of the language.

Lou Berger: If I understand correctly, do Option 1 to fix our today
problem then do option 2 as part of YANG next.

Rob Wilton: I'm supportive of fixing this now. YANG NEXT has a large
list of issues and will take ~5 years.

Balázs Lengyel: Ericsson and 3GPP are OK with doing option 2 later, but
we need a solution now.

POLL #1: Do we allow for NBC changes in YANG? (YES=Option 1 Or Option 2,
NO=Option 3)
Kent Watsen: Most attendees responded. Amoung respondents, unianimous
consensus to move to supporting NBC changes in YANG - to be confirmed on
list.

POLL #2: Do We Keep The 1.0/1.1 Version Number Or Move To 1.2?
(YES=1.0/1.1, NO=1.2)?
Lou Berger: About the same level of response. Split decision, more
supported keeping 1.0/1.1. But a good part of the group prefered a
simple 1.2.

Jason Sterne: It might be helpful to hear from people who voted for #2
to help give a perspective of why thet might view that as preferrable.
(Rob Wilton seconded this request, Balazs asked if 1.2 supporters would
be OK with option 1 now but option 2 later)

Kent Watsen: As a 1.2 supporter, the rules are MUST NOT and I think that
we need to stick with that. I worry about clients and how they would
react to NBC changes that occur when they aren't ready for them.

Joe Clarke: They're seeing them already today.

Rob Wilton: Just to back up Joe's point. OpenConfig, vendors, IETF are
all doing this.

Kent Watsen: I'm willing to go with group consensus on this. But if we
go with option 1, let's just do option 2 with YANG NEXT (much larger
scope).

Oscar Gonzalas Del Dios: We need to get something now. If breaking
changes are happening today, we need to handle it soon. If 1.2 is the
right way to do it, then let's do it quickly.

Dean Bogdanovic: 1.2 would more clearly indicate that we're doing an NBC
to YANG itself.

Jason Sterne: Clients are already making incorrect assumptions today.
Users have to carefully look at every revision and suspect it has NBC
changes.

Charles Eckel: I'm confused if 1.2 would break existing clients. If that
is the case of the installed eco system, go forward now with option 1
and wait with larger changes for YANG 2.0.

Lou Berger: if we keep 1.1, what we're doing is updating rules in a
document. If we go with 1.2 we're impacting every client. Which is
harder for clients to deal with?

Rob Wilton: If everyone today was adhering to the current rules then I'd
be more inclined to do this with YANG 1.2. But the reality is that NBC
changes are happening today with YANG 1.0/1.1 and we should update the
language to match the reality.

Kent Watsen: You're right - currently NBC changes are being made. If we
were really just talking about a document change (MUST NOT to SHOULD
NOT) that would be fine, but the scope is larger than that and I'm
concerned about the impact on clients.

Joe Clarke: Yes - this also includes optional extensions to signal that
this has occured (useful for tools if they want to start using them,
useful to humans)

Balázs Lengyel: I remember in the early days of YANG we debated
deviations and many people hated them but we just needed them. We also
should have allowed NBC changes in YANG 1.0.

Benoit Claise: We are now many years later. OpenConfig seemed to
understand NBC changes are a fact quickly. I'm a strong supporter of
option 1.

Ahmed Elhassany: As an operator I'd like to speak about updating the
tool chain. It is easier than updating routers. We don't want silent
failures - would rather things fail in a clear way and then we can fix
them. We don't want breaking changes slipping through silently.

Lou Berger: can you clarify if you are speaking to support Option 1 or
Option 2?

Ahmed Elhassany: My comments were orthogonal. I personally would like to
move to Option 1 now. We'll learn from it. People waiting for it can get
it now and learn from that experience. Then we can do it in YANG NEXT.

POLL #3: Do You Support Option 4 - Option 1 (No Version Change) And
Start On Yang Next/2.0? (Yes, = Raise Hands, No = Do Not Raise Hands)
//no stated conclusion from poll [60% YES, 10% NO, 30% ABSTAINED]

Dean Bogdanovic: These two things are not linked? Linking them will slow
us down.

Joe Clarke: Would like to see some things addressed, but need to make
progress so as not to fracture YANG.

Rob Wilton: what are the next steps to progress this. Are we going to
have an interim?

Lou Berger: I think we need a discussion, perhaps with the three of
us...

Charles Eckel: can we give an update to 3GPP soon? They have a meeting
coming up in Aug.

3) Extensions to the Access Control Lists (ACLs) (10 min)

Presenter: Oscar Gonzalez de Dios

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions-02

Start time: 14:10
Notes:

Mahesh Jethanandani: Does there exist a document in order to update ICMP
types?

4) Node Tags in YANG Modules (10 min)

Presenter: Qin Wu

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags-10

Start time: 14:20

5) System-defined Configuration (10 min)

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

Presenter: Qiufang Ma

POLL: Must Offline The "Running" Document (Not Online ) Be
YANG-Valid? (YES=Offline Validation MUST Succeed, NO=Intention Is Only
That Online MUST Be Valid) [No conclusion from
poll]

Non-Chartered items:

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

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

Presenter: Qiufang Ma

Start time: 14:40
Notes:

POLL: Immutable Flag: Should We Adopt This Document As A Starting
Point For The WG? (Yes=Raise Hands, No=Do Not Raise)

Lou Berger: We didn't have a lot of people responding, but those
responding thought if this was a suitable starting point for work for
the working group.

Balázs Lengyel: I'm dissapointed that the IETF is rejecting/ignoring
half of the 3GPP liaison statement. We need clients to be able to create
immutable elements.

7) Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (10 min)

Presenter: Qin Wu

Draft: https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis-01

Start time: 14:50

POLL: RFC8407Bis: Should we adopt this document as a starting point
for the WG? (YES=RAISE HANDS, NO=DO NOT RAISE)

Lou Berger: Not a large amount of support but there's no opposition.
Stay tuned on list.

Unscheduled time (0 min)

Note takers