Subject: [netmod] draft minutes for 2/1/2020 Interim

From: joel jaeggli <[email-masked]>
Date: Mon, 1 Feb 2021 08:06:59 -0800

These are based on the codimd which is editable

https://codimd.ietf.org/notes-ietf-interim-2021-netmod-01-netmod?edit

# NETMOD Agenda for Interim (virtual)
Date            February 1, 2021
Start Time      14:30 UTC
Duration        90 minutes

Time Zone Converter:

https://www.timeanddate.com/worldclock/converter.html?iso=20210201T143000&p1=1440&p2=37&p3=438&p4=33&p5=248&p6=224&p7=179
Slides:

https://datatracker.ietf.org/meeting/interim-2021-netmod-01/session/netmod
Notes & BlueSheet:
    https://codimd.ietf.org/notes-ietf-interim-2021-netmod-01-netmod
WebEx:
   https://ietf.webex.com/ietf/j.php?MTID=m8ee8976e972cc17b725f3ce1900b0cd0
Jabber:
    xmpp:[email-masked]?join

## Agenda:

### 1       Topic   Intro & Administrivia
Presenter:      Chairs

lou berger presenting
14:35

### 2       Topic   Module Versioning:
Presenter:      Authors
Follow on to
https://datatracker.ietf.org/meeting/interim-2020-netmod-03/session/netmod

#### T2) IANA considerations: how are final RFC revision labels assigned ?
> https://github.com/netmod-wg/yang-ver-dt/issues/59
>
Rob Wilon presenting
14:40

kent: asking iana to retroactively put versions to drafts what is the
guidance?
rob: ask for a new interface type routing type those get updated
automatically
lou: does it make sense to put text to tell people when to not use a
self managed iana module.
rob: you could
jason: looking for guidance on when iana would own the module vs when
they would not - is that part out of scope? rob is addressing the
guidlines for when you have iana manage it.
lou: we don't want to necessarily open up the guideilnes RFC just for
this one point so maybe include it in the yang versioning draft.
lou: provide text to working group for review

Joel(chair) the proposed approach (3rd slide) does not appear controversial

#### T3) YANG file naming when revision labels are being used (symbolic
links?
> @<revision-label>) ?
https://datatracker.ietf.org/doc/slides-interim-2021-netmod-01-sessa-revision-label-filename/
Reshad Rahman presenting
14:53

First sub-issue (slide 2, @ vs # as delimiter)
Kent: maybe try with pyang, yanglint, (yangson not likely impacted).
ideally they just skip over the # items.  I like the idea of the 2
approaches (old us @, new use #).
Italo: does the new scheme allowed to deliver 2 versions of the same
module on the same date?
Reshad: no - we are keeping the same RFC7950 restrictions where only one
new version of a module can be published on a particular day (revision
date uniquely identifies a module version)
Jan: would prefer to avoid duplicate files.  An operator or system
should use either @ or # (not a mix).
Kent: system could reject the @ or # if they wish. That system could
just have the names as they wish?
Rob: I agree with Kent. Allowed to have both if wanted to, but would
move to new scheme at some point (and use purely #).

Second sub-issue (slide 3 - allowed char set in revision labels)
Balazs: better to be restrictive and see if there is really a need.
These are part of a filename so being very open can be dangerous
Kent: certainly don't allow other chars that aren't in 7950
Rob: one extra char that we are adding is the + and maybe the comma.
Design team isn't certain about comma and interaction with csv.
Kent: call out the new chars in an email to the WG list

#### T1) Definition/meaning of BC vs NBC for config false nodes
> https://github.com/netmod-wg/yang-ver-dt/issues/15
>
https://datatracker.ietf.org/doc/slides-interim-2021-netmod-01-sessa-state-nbc-rules/

Balazs presenting
15:04

Jason: removing leafs (e.g. interface counters) feels like it should be
NBC. But removing
Balazs:
Kent: the market may not be happy.  removing should deprecate and then
obsolete
Jason: in theory that isn't needed because it is BC
Kent: sure but it is still good practice
Balazs: use mandatory for state leafs
Lou: we may have to split out reducing value space on mandatory vs
non-mandatory leafs. SOme clients may rely on it.
Balazs: worried that we are encouraging servers to just stop returning a
value instead of updating the model
Lou: my automation system may rely on certain state, and certain values
of state coming back
Rob: agree with Lou. Splitting mandatory vs non-mandatory makes sense.
Dangerious to allow optional data to just be removed from a model.
General expectations are likely that leafs are returned and supported
even if they aren't marked mandatory.
Rob: e.g. counter on i/f that splits unicast/multicast/broadcast.  You
can't make that mandatory on all types of interfaces.
Balazs: use "when" statements (when i/f type = x, then)
Kent: to Lou's comment - removing the leaf vs removing an enum. We've
been lax in marking state data as mandatory.  Maybe we need to mark more
as mandatory.  Another point - expanding value space needs to be careful
with patterns.
Balazs: lengths, patterns, must statements should all be examined
Jan: If nothing marked mandatory or in description, then can't rely on
the data being returned.
... lots of debate around use of mandatory in config false...
Balazs: state has been best effort historically
Kent: agree but maybe that isn't great and we should start getting more
formal. Perhaps we should have been setting mandatory true on more state
data.  Let's not reverse the default of mandatory for state (that would
need YANG NEXT).
Balazs: 1 - how strict should we be?  2 - do we mark a removal of
optional leafs as NBC just because of current expectations
Rob: RFC7950 doesn't allow removal of optional state leafs today (you
could deprecate or obsolete).
Jason: we should avoid mandatory for state
Kent: perhaps YANG NEXT is needed for new state rules (esp if we go
against RFC7950)
Balazs: we need to do something now, e.g. we should be allowed to add a
mandatory state leaf
Balazs: we should be more careful with state markings (mandatory). 2nd
bullet should just be NBC for now (easier to get accepted).  And
reducing value space for mandatory is NBC.
Rob: solving this properly is likely YANG NEXT. But we need something
for the interim.  So bullet 2 should be NBC for now with where we are today.
Kent: client validating RPC reply could be seen as a developer aid for
the server
Rob: worth checking NMDA spec.  Allows server to break those restraints
(at least temporarily).  Ok to flag up warnings, but refusing to accept
data could be a problem in general.  (consider config true & config
false for this point)

#### T4) SemVer: gaps in history, removing revision statements
> https://github.com/netmod-wg/yang-ver-dt/issues/61
>
https://datatracker.ietf.org/doc/slides-interim-2021-netmod-01-sessa-version-gaps/

Joe Clarke presenting
15:45

Kent: why strip any history at all? how is it possible that 1.2 isn't
present?
Joe: why strip? -> large amount of revision is cumbersome for humans. We
don't recommend it, but wouldn't want to block it.  why 1.2 missing? ->
1.2 might have been some internal revision.
Kent: I don't believe we should worry about the human problem. I don't
think we should allow gaps.
Balazs: one important reason for gaps -> branching.  1.5 may be in a
side branch.
Kent: that sounds like internal merging issue. It is about managing
expectations. I don't know any library that skips.  A missing value is
not expected.
Joe: maybe a system publishes every odd version
Jason: some publishers may have internal versions, and it would be
painful to have a mapping from internal to external
Rob: I see Kent's point and maybe a publisher doesn't have to actually
publish all those versions. But they could keep those versions in the
history.
Jason: it could cause a lot of bloat in the history
Joe: maybe soften the wording to encourage keeping all revisions?  Then
again if you went a year before publishing do you really want all those
internal versions listed?

1600 conclusion

# Virtual Bluesheet
NAME   AFFILIATION
------------------
1. Lou Berger        LabN Consulting, L.L.C.
1. Jason Sterne      Nokia
1. Italo Busi        Huawei
1. Reshad Rahman     None
1. Robert Wilton     Cisco
1. Kent Watsen       Watsen Networks
1. Balazs Lengyel    Ericsson
1. Joel Jaeggli      Fastly
1. Jan Lindblad
1. Joe Clarke        Cisco
1. Tom Hill
1. Xufeng Liu