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:net...@jabber.ietf.org?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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
