Hello NETMOD WG,
I've blatantly copied the message that Rifaat Shekh-Yusef sent to the
secdispatch list here 😊
The NomCom is tasked with selecting the IETF leadership, like the IESG, the IAB
and ADs. For the NomCom to be able to make an informed decision, they need
feedback from the wider IETF
Hello NETMOD WG,
Our weekly YANG Versioning call will be a little different next week during
IETF 115.
The call meeting will be 30 minutes earlier than normal:
8:30-9:30 EST
13:30-14:30 UK time
For anyone attending IETF 115 in person, we have booked the "Mezzanine 12" side
meeting room. You ca
Hello WG,
A new item has been added to the Agenda:
A Policy-based Network Access Control (10 minutes)
Presenters: Qin Wu/Qiufang Ma
Draft: https://datatracker.ietf.org/doc/html/draft-ma-opsawg-ucl-acl-00
Jason
> -Original Message-
> From: Kent Watsen
> Sent: Tuesday, October 25, 2022 6
Hi all,
I support the adoption of this draft. I think this is a worthwhile topic to
work on. We do still need some discussions on the details of the solution.
I'm a bit tied up with the YANG versioning work/drafts at the moment so I'll
have limited time to dedicate to work on this in the short
nt a new item in parallel for a period, then
finally obsoleting the old item).
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/
Jason
From: netmod On Behalf Of Sterne, Jason (Nokia -
CA/Ottawa)
Sent: Monday, June 6, 2022 6:56 PM
To: Scott Mansfield ; italo.busi
Hi all,
Just to close part of the loop on this topic: In addition to the discussions
below in this thread and other threads in the WG mailing list, we also had
numerous discussions in our weekly calls on the top-level NBC indicator (at the
module level) vs the per-node NBC indicators.
In the
YANG Versioning Weekly Call Minutes - 2022-10-18
2 major discussions:
(A) Should YANG Semver support branching at the minor ?
(B) Where should the per-node NBC/BC compatibility text live ?
(A) Should YANG Semver support branching at the minor ?
- decision was to align to what we believe is the mo
No, I'm not aware of any IPR that applies to this draft.
Jason
> -Original Message-
> From: Kent Watsen
> Sent: Wednesday, October 12, 2022 9:24 PM
> To: maqiufang (A) ; Qin Wu
> ; Feng Chong ; Kent
> Watsen ; Jan Lindblad (jlindbla) ;
> Chongfeng Xie ; Sterne
quot;obsolete" schema nodes.
If this leaf is set to "false" or absent, then the behaviour is
unspecified.
Servers SHOULD set both the "deprecated-nodes-implemented" and
"obsolete-nodes-absent" leafs to "true".
-
Hi all,
IMO an obsolete node is not in the schema:
- any mandatory statement should be ignored (i.e. it is fine for a datastore to
*not* have data for mandatory obsolete nodes)
- trying to write data to that element should be an error (no such node)
I generally agree with Jan about the deprecate
YANG Versioning Weekly Call Minutes - 2022-10-11
IETF 115 preparation:
- NETMOD is 9:30 UK time
- cutoff for drafts is Oct 24
- Tom, Balazs and Joe presented at IETF 114
- Who is attending 115 ?
- Balasz - attending, could present
- Joe - attending, could present
- Jan - attending, could pre
YANG Versioning Weekly Call Minutes - 2022-09-13
We reviewed the open issues against Module Versioning:
https://github.com/netmod-wg/yang-ver-dt/labels/updated-mod-rev-handling
Most are assigned and in-progress.
We continued reviewing Jason's PR for the per-node compatibility markers:
https://gi
Hi all,
Not many people are going to understand a must statement like that. Maybe a
good idea to also describe this constraint in a description statement somewhere
in the model ?
Jason
> -Original Message-
> From: netmod On Behalf Of Kent Watsen
> Sent: Tuesday, August 23, 2022 9:32 PM
Thanks Balazs. Agree the key message is the de-coupling of those two drafts
from the remaining 3.
I'm not sure if you intended 2022-Q2 but that Q is over 😊
We need to roll the per-element tags into the draft and still have some LC
comments we haven't replied to (and it is summer vact period). I
Hi all,
A number of people are away over the next few weeks so we're going to cancel
the Tues Aug 2 and Aug 9 weekly YANG Versioning calls.
We'll pick them back up on Tues August 16.
--
Versioning work on Github:
https://github.com/netmod-wg/yang-ver-
oesn't preclude declaring against).
> -Original Message-
> From: Jürgen Schönwälder
> Sent: Tuesday, July 26, 2022 2:15 AM
> To: Sterne, Jason (Nokia - CA/Ottawa)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] origin annotation against non-presence container
> (po
Hello Wolfgang,
I don't see any clear right answer here.
You're talking about a condition that must be met for a configuration change to
take operational effect. In this case it is a restart. But there could be other
types of similar conditions. E.g. other nodes that need:
- an admin-state to b
HI all,
RFC 8526 section 3.1.1.4 seems to have an origin against a container (container
bgp, from C.2 in RFC 8342):
http://example.com/ns/bgp
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
2001:db8::2:3
ht still work fine with older
clients. Maybe others in the WG see a "gotcha" I'm missing though.
Jason
From: Italo Busi
Sent: Monday, June 27, 2022 8:19 AM
To: netmod@ietf.org
Cc: 'cc...@ietf.org' ; Scott Mansfield
; Sterne, Jason (Nokia - CA/Ottawa)
Subject: RE: Anot
YANG Versioning Weekly Call Minutes - 2022-06-07
Priority of our effort is WG LC on first 2 drafts. Anything that we can do on
that will be the focus.
Otherwise we'll switch over to the Schema Comparison draft for a few weeks.
Potentially consider IETF hackathon as an opportunity to work on sch
e would need to take a look at it.
This discussion is also making me realize that our text in B.2.3.1 may have a
mistake. An author can't stick the old leaf into a "choice" and be 100% BC so
we should probably remove that option.
Jason
From: Scott Mansfield
Sent: Friday, Ju
Hi Italo,
One problem I see with this change is that in the old data model, the leaf
"mode" had to exist in the instance data. But with the new model, it is valid
to have instance data with no "mode" leaf at all. That instance data would not
validate against the old YANG model.
I do see your p
Hi all,
We're planning to switch over to the Comparison and Packages drafts in the call
tomorrow.
Within our weekly calls we're mostly done initial discussion of all the WGLC
feedback on Module Versioning and YANG Semver. Various authors are planning to
reply back to the list for followup disc
YANG Versioning Weekly Call Minutes - 2022-05-24
As part of "per-element" BC/NBC tags, we need to define default assumptions
that a tool will make for certain types of module changes. Note that these are
just assumptions, not definitive rules that these changes are indeed NBC or BC.
In some cas
YANG Versioning Weekly Call Minutes - 2022-05-17
We further discussed the use of per-element NBC/BC marking:
- mixing a lot of detailed per-element history in a module may not be as clean
as keeping it as "the current API"
- in some more extreme cases, could end up with a module that is more hist
Hi all,
Tomorrow (May 17th) we'll continue with the discussions around per-element
version tags (the discussion sparked by Jurgen's "alternative approaches" email
during Module Versioning WGLC). The current thinking in the calls is that we
still likely want a top-level "YANG Semver" for the mod
Hi all,
Last week we mainly discussed Jurgen's email "yang versioning solution
complexity and alternative approaches".
Tomorrow we'll continue with that discussion, and then work through other WG LC
feedback (from Jurgen, Andy and Italo).
Please feel welcome to join and help us drive this work
YANG Versioning Weekly Call Minutes - 2022-03-29
Discussed Jurgen's feedback on Module Versioning:
* 1. Introduction
- discussion notes captured in github Issues #145 and #146
- generally agreed on the direction of Jurgen's comments
* 3.4.1. File names
- discussion notes captured in github Issue
YANG Versioning Weekly Call Minutes - 2022-03-22
We mainly discussed optionality in YANG packages:
- What optionality should we be able to describe ? (none ? deviations, optional
modules, etc ?)
- How should that optionality look in the packages & library modules (API vs
implementation packages,
Hi all,
There is an interesting consequence of the wording for lists.
> The list's key nodes are encoded as subelements to the list's
> identifier element, in the same order as they are defined within the
> "key" statement.
>
> The rest of the list's child nodes are encoded as sub
Yeah - I don't think there is any way for YANG to really express different
defaults (i.e. dynamic defaults that depend on some other condition, e.g. which
list item, etc).
The YANG default statement is really only for leafs that have a static default
value (i.e. always the same).
In this case
YANG Versioning Weekly Call Minutes - 2022-02-22
Reshad & Jason looked at Bo's PR for issues #105/#125. After Reshad approves,
Bo to go ahead and merge in.
We further discussed optional modules in packages (i.e. API Packages vs
Implementation Packages).
- allow "down rev" of an optional module
YANG Versioning Weekly Call Minutes - 2022-02-08
We had a few new people join the call on Tuesday - that's great. Thanks for
joining in. It may take a few calls to get into the swing of things.
Discussed on the call:
- reviewed some action items that have progressed:
- #74 items (a) and (c)
Hi all,
This immediately made me worried about all such xxx-ref constructs in YANG that
I've seen in a few modules.
But looking at IETF interfaces https://datatracker.ietf.org/doc/html/rfc8343 I
see that this error is avoided because interface-ref is fully qualified right ?
typedef interf
Hi all,
The main topic of discussion in the call tomorrow (Tues Feb 8) will be schema
mount information in YANG Packages. We've had a few discussions around this
topic. We're still struggling with what it means to list mounted schema in a
package, whether that schema is optional vs mandatory, h
"No, I'm not aware of any IPR that applies to this draft"
Regards, Jason
> -Original Message-
> From: Lou Berger
> Sent: Monday, January 31, 2022 4:54 PM
> To: jcla...@cisco.com; res...@yahoo.com; rwil...@cisco.com;
> balazs.leng...@ericsson.com; St
"No, I'm not aware of any IPR that applies to this draft"
Regards, Jason
> -Original Message-
> From: Lou Berger
> Sent: Monday, January 31, 2022 4:57 PM
> To: jcla...@cisco.com; rwil...@cisco.com; res...@yahoo.com;
> balazs.leng...@ericsson.com; St
YANG Versioning Weekly Call Minutes - 2022-02-01
- Reviewed PR 127 for issue #74 items (a) and (c) - schema terminology. Jason
to fold PR into latest.
- Reviewed Jan's text for issue #70 - deviations in packages. Jan to create a
PR.
- Reviewed Jason's text for issue #74 item (k) - pre-release
YANG Versioning Weekly Call Minutes - 2022-01-25
WG LC next steps for 1st two drafts:
- Jason to discuss plan with NETMOD chairs.
Jason: #74 items (a) and (c) and #38:
- if one person can review PR#127 for basic sanity, Jason will pull into latest
draft on github.
Schema terminology by jsterne *
combined set of schema nodes defined by a YANG
package. Package schema can be used to define datastore schema.
Rgds,
Jason
From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Friday, January 7, 2022 5:37 PM
To: Juergen Schoenwaelder
Cc: netmod@ietf.org
Subject: RE: [netmod] Definitions of
YANG Versioning Weekly Call Minutes - 2022-01-18
We discussed the following two open issues:
Jason: #74 items (a) and (c) and #38 (schema terminology)
Rob: #57 (mount points in packages)
For #74 we're done reviewing. Jason to update, issue PR, and pull changes into
the latest draft.
For #57:
-
YANG Versioning Weekly Call Minutes - 2022-01-11
We discussed issue #74 items (a) and (c) about 'schema' terminology (overlap
with issue #38). Comments were added to the schema-terminology branch in
GitHub. Jason to update.
Rob will take issue #57 (mount points in packages) and propose updated
Hi all,
In the weekly YANG versioning call tomorrow well discuss issue #74 items (a)
and (c): definitions of packages, package schema, and other "schema" terms.
https://github.com/netmod-wg/yang-ver-dt/issues/74
We may also touch on some of these issues:
#65: (revision label scheme for packages
Please see inline.
> -Original Message-
> From: Jürgen Schönwälder
> Sent: Thursday, December 9, 2021 1:19 PM
> To: Sterne, Jason (Nokia - CA/Ottawa)
> Cc: maqiufang (A) ;
> netmod@ietf.org
> Subject: Re: [netmod] system DS polluting intended and operational
>
&
datastore schema or only
part of a YANG datastore schema with some module import dependencies missing,
as described in Section 5.4.
Jason
> -Original Message-
> From: Jürgen Schönwälder
> Sent: Thursday, January 6, 2022 5:09 PM
> To: Sterne, Jason (Nokia - CA/
Hi all,
This email is related to the items (a) and (c) in Issue #74 of the YANG
versioning work:
https://github.com/netmod-wg/yang-ver-dt/issues/74
First some background:
"YANG schema" is not defined in RFC7950 or 8342 (NMDA).
8342 defin
YANG Versioning Weekly Call Minutes - 2022-01-04
Discussed Issue #65 (revision label scheme for Packages). Balazs will send
updated text.
See minutes from 2021-12-14 for list of current action items.
Jason to raise a new issue for combined name+version (done - issue #123)
Topics for next week:
Hi all,
The YANG Versioning weekly calls are cancelled Tues Dec 21 and 28. We'll resume
on Tues Jan 4. As always, everyone is welcome.
Jason
--
Weekly webex call details:
Meeting number (access code): 161 096 5630
Meeting password: semver?
Occurs ev
YANG Versioning Weekly Call Minutes - 2021-12-14
Jason: announce Dec 21 and 28 weekly calls are cancelled
The primary discussions were around issues #67/#69 - relationship between
Packages and yang-library (two options compared: p-02 and J1). Some notes from
the discussion:
- unclear exactly ho
Hi all,
The main discussion topic for the weekly YANG Versioning call tomorrow is a
fairly fundamental one: the basic structure of Packages and how they fit in
with YANG Library.
We are debating 2 approaches that we will walk through and discuss on the call.
It is mainly related to how "includ
I wonder if having all the system config appear in intended and operational may
be annoying. We didn't want to pollute running with 100s/1000s of lines of
unreferenced system config. So maybe putting all that in intended & operational
is also ugly ?
We should have *some* way that a client can r
e a use
case given their model-driven architecture).
I assume Huawei must have it given the 3 primary authors are associated with
Huawei in the draft. Maybe they can confirm.
Jason
> -Original Message-
> From: Jürgen Schönwälder
> Sent: Thursday, December 9, 2021 10:17 AM
>
Hi Andy,
The actual system instance data isn't in a YANG model, but that instance data
sits in schema defined in the YANG model. It is typically a list entry
populated by the system. But there may also be other list entries created by
the users/clients, and other areas of the YANG model may re
> FWIW, JUNOS “solves” this by *hiding* these system-nodes, such that
> clients must use a special command just to discover them. And, yes, if ever
> any of these are hidden-nodes are reference, offline-validation of
> will fail.
Other implementations have a similar concept with the same cons
> We’ve always maintained that should only contain client-provided
> config, right?
+1
Or at least the clients (or at least operators of a network element) should
have the option of avoiding any config appearing in the running besides what
they put in there.
If config can magically appear in
I think it may be a server implementor's choice whether they would put a
loopback interface into (i.e. consider it as system provisioned
configuration), or into (and not system, i.e. consider it as
state information).
The primary config use cases I see aren't so much interfaces, cards,
etc.
+1. If a value was explicitly configured in , that takes precedence as
origin whether it matches or not (just like it takes precedence as the
value in ).
For config that is *not* in , and comes from , then we should
probably go with "system" as the origin. It is a bit confusing that
flows i
Hi Qiufang Ma,
Please see inline.
Jason
From: maqiufang (A)
Sent: Thursday, December 9, 2021 7:57 AM
To: Sterne, Jason (Nokia - CA/Ottawa)
Cc: netmod@ietf.org
Subject: RE: [netmod] "immutable" flag
Hi, Jason,
Thanks for your comments, please see my reply inline.
From: Sterne, Ja
t of nodes in running" are you talking about Jan's
option #1 below (but perhaps without the explicit datastore) ? i.e.
all the system config is actually returning from a of running ?
Jason
From: Andy Bierman
Sent: Wednesday, December 8, 2021 5:50 PM
To: Sterne, Jason (Nokia - CA/
g in this discussion -> i.e. is it ok that running is invalid, as
long as intended is valid ?)
Jason
> -Original Message-
> From: Jürgen Schönwälder
> Sent: Thursday, December 9, 2021 8:46 AM
> To: maqiufang (A)
> Cc: Andy Bierman ; Sterne, Jason (Nokia -
> CA/Otta
Sorry all - I just noticed that my email client didn't thread all the responses
to this topic in with the original post. It looks like this has been heavily
discussed and I'll look through those emails.
From: netmod On Behalf Of Sterne, Jason (Nokia -
CA/Ottawa)
Sent: Wednesday,
Hi Qiufang,
In your first option, did you mean "understand a certain data node is from
or from " ?
It is an interesting question about whether the origin annotation could/should
be available in a read from , and what values that origin could take.
We should consider other transformations betw
Hi Qiufang,
I think there are use-cases for "immutable" even outside of system config so we
may not want to restrict it to system config.
I'm not sure it would be as simple as erroring when a write is attempted to
that value.
Are you talking about an error at edit time, or at commit/validation
Hi Kent,
I'm not following your "In the meanwhile" thoughts.
Legacy clients are failing offline validation today. If running config has a
leafref to system config, and doesn't return that system config
(which it doesn't in some implementations), then the instance data returned to
the client d
Hi guys,
Andy - about use cases. Here is a problem we're trying to address:
There are at least several major router implementations that have this concept
of "hidden config" (i.e. list entries that can be referenced in a leafref by
explicit user config, but those list entries are not returned
YANG Versioning Weekly Call Minutes - 2021-11-30
Should we issue a new YANG Semver v06 for the additional text I proposed for
issue #84 ? Answer: yes. Joe to issue v-06 of Semver and Jason to suggest
chairs to go for WG LC in early Jan. Authors have reviewed & think they are
done, and so does
vation for the _COMPAT extension on
YANG Semver)
- review text authors provide for other open packages issues
- continue with these issues:
https://github.com/netmod-wg/yang-ver-dt/issues/74
https://github.com/netmod-wg/yang-ver-dt/issues/76
Rgds,
Jason
From: Sterne, Jason (Nokia - CA/Ottawa)
Sen
YANG Versioning Weekly Call Minutes - 2021-11-23
Today we discussed Jan's alternative approach for how Packages and YANG Library
fit together.
We agreed we need further discussion (target = 2 weeks from now, Dec 7 call).
Jan will try to give an example of an instance data document for the new
Hi all,
Here are the planned key discussion topics for the weekly YANG Versioning call
tomorrow:
a) Overlapping module advertisements
With the proposed YANG packages solution, there would be one more place where a
server would list the set of modules it implements (there are already 4). Can
w
Hi all,
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-05#section-3.3
shows how the COMPAT suffix (_compatible or _non_compatible) is "sticky" but
we could use some clarifying text to explain *why* that is useful. This was
raised in https://github.com/netmod-wg/yang-ver-dt
YANG Versioning Weekly Call Minutes - 2021-11-16
Reminders:
- meetings are back to 1 hour starting at 9am Eastern Standard Time (New York /
Ottawa).
- topics for next week listed at the bottom of the minutes
1) review feedback from IETF112
- not much feedback, quiet meeting
- try to send topics
Hi all,
The weekly YANG Versioning call on Tues Nov 9th is cancelled. See you at the
IETF112 NETMOD session on Thursday!
Jason
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
YANG Versioning Weekly Call Minutes - 2021-11-02
Meeting cancelled next week (Nov 9, IETF 112 week). Meetings will start again
on Tues Nov 16th 9:00am Eastern Standard Time (EST) for 1 hour.
The regexp pattern for YANG semver revision-label doesn't allow the recommended
IETF pre-release names.
YANG Versioning Weekly Call Minutes - 2021-09-28
We continued going through the github issues for Packages.
Assigned author for writing up specific text for issues:
#29: TBD
#30: Jason
#32: TBD
#38: Rob
#57: TBD
#63: Reshad
#64: Jason
#65: Balazs
#66: Jason
#67/#69: Jan
#82: Bo
#103: Rob
Other d
Hi guys,
I'm not sure how reusing '@' is preferrable for URLs than using '#'. They are
both escaped right ?
Jason
> -Original Message-
> From: netmod On Behalf Of Rob Wilton
> (rwilton)
> Sent: Wednesday, September 15, 2021 5:08 AM
> To: Joe Clarke (jclarke) ;
> netmod@ietf.org
> Subje
mental issues common to both (e.g. is
valid on its own for offline validation).
Are the authors considering a virtual interim or an updated draft ? (although
if we haven't converged on the basics, not sure an updated draft makes sense
yet ?).
Jason
From: netmod On Behalf Of Sterne,
Hi all,
Reserving a "magic value" like -1 may be workable, but it doesn't feel like a
terribly good fit into YANG. The rest of the range of integer values are valid
and it seems odd to just tack on a "-1".
Why not just make the absence of the leaf mean "not applicable" or "not
available" or wh
YANG Versioning Weekly Call Minutes - 2021-09-21
We discussed how Packages should describe YANG mount points. Resulting notes
added to the issue tracker. We have mostly concluded on an approach, but need
to write up specific text for the draft:
https://github.com/netmod-wg/yang-ver-dt/issues/57
YANG Versioning Weekly Call Minutes - 2021-08-31
Bo volunteered to do editing of the Packages draft.
Jason suggested that we distribute the work of proposing specific text changes
to other weekly call members (not the draft editor) to spread the workload
around.
Reviewed open github issues aga
.
Jason
From: Jan Lindblad (jlindbla) mailto:jlind...@cisco.com>>
Sent: Monday, August 23, 2021 6:50 AM
To: Andy Bierman mailto:a...@yumaworks.com>>; Sterne, Jason
(Nokia - CA/Ottawa) mailto:jason.ste...@nokia.com>>
Cc: Kent Watsen mailto:kent+i...@watsen.net>>;
netmod@iet
the hood) and then
it would always return that policy in a , making the leafref valid.
Jason
From: Jan Lindblad (jlindbla)
Sent: Monday, August 23, 2021 6:50 AM
To: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa)
Cc: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] system configuration
Hi all,
In order to help move the YANG versioning work forward we're going to extend
the weekly calls to 2 hours (starting 1 hour earlier than before). This change
takes effect on our next meeting on Tuesday August 31st.
As always, anyone is welcome (and encouraged) to join. It would be particu
Thx Kent. Please see inline.
Jason
From: Kent Watsen
Sent: Monday, August 9, 2021 9:59 PM
To: Andy Bierman
Cc: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf.org
Subject: Re: [netmod] system configuration sync mechanism
There was a request for concrete use cases. This email from before was
Hi Andy,
Pls see inline.
Jason
From: Andy Bierman
Sent: Monday, August 9, 2021 6:23 PM
To: Sterne, Jason (Nokia - CA/Ottawa)
Cc: Juergen Schoenwaelder ; Kent Watsen
; NetMod WG
Subject: Re: [netmod] system configuration sync mechanism
On Mon, Aug 9, 2021 at 2:51 PM Sterne, Jason (Nokia
Hi guys,
I'm late to the game on this thread but I did read through the entire thing
(whew - can't promise I absorbed every nuance though). I am familiar with this
issue. I've been dealing with it from the server implementation side (some
clients *do* complain if there are references to missing
YANG Versioning Weekly Call Minutes - 2021-07-27
We reviewed and updated the IETF111 slides
- moved discussion of the main open issue (YANG 1.1 vs 1.2 vs 2.0) to the end
- added summary slides of 1st two drafts
Reconfirmed reasons why we propose these drafts as part of YANG 1.1:
- no real harm
YANG Versioning Weekly Call Minutes - 2021-07-20
We reviewed the IETF111 slides. Jason, Reshad, Joe to submit them in the next
few days
Remaining open issues on Module Versioning & Semver drafts:
- include as part of yang 1.1 ? (in Jason's slides)
- text for removal of histo
YANG Versioning Weekly Call Minutes - 2021-07-06
IETF 111 presentation (July 27 Tues)
- Jason present intro + module versioning (Joe as backup)
- Joe present semver
- slide preparation for module versioning:
- A) Module versioning "Updates since last time": Reshad
- closed issue
-
YANG Versioning Weekly Call Minutes - 2021-06-22
Activity from the past week:
- Rob's grammar fixes (already merged)
- use of module/submodule (sitting as pull request)
- *include* by revision label (leaving it out)
- NBC rules for 'default' statements (leave this as per 7950, no clarification.
YANG Versioning Weekly Call Minutes - 2021-06-15
We only discussed the module versioning draft today.
- remove the MUST NOT in the YANG module where it talks about substatements of
the new extensions
Include the following text as part of section 7.1 author guidelines:
In some cases a module or
om: Kent Watsen
> Sent: Monday, June 14, 2021 1:17 PM
> To: Andy Bierman
> Cc: Sterne, Jason (Nokia - CA/Ottawa) ;
> netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08
>
>
> > I meant the current work is using extensions instead o
I raised an issue in the verdt project about pyang checking for revision-label:
pyang --ietf should check if a module has a revision-label * Issue #99 *
netmod-wg/yang-ver-dt
(github.com)<https://github.com/netmod-wg/yang-ver-dt/issues/99>
From: netmod On Behalf Of Sterne, Jason (Nokia
n-key attribute), i.e. yang
library was changed to use revision label instead of revision date, then two
versions could be allowed on the same date. But that's for a YANG NEXT
discussion.
Jason
From: Andy Bierman
Sent: Tuesday, June 8, 2021 1:49 PM
To: Sterne, Jason (Nokia - CA/Ottawa)
YANG Versioning Weekly Call Minutes - 2021-06-08
Submodule vs Module in module versioning draft:
- avoid 'artifact', put "submodule or module" everywhere it is applicable
- Reshad: add "or submodules" in most places.
Non duplicate revision dates:
- revision-label is just another label for that re
YANG Versioning Weekly Call Minutes - 2021-06-01
- YANG versioning - extensions
- Reshad: integrate the text from the email thread from May 18
- Jason: create a separate issue for submodule vs module (Jan: what does
7950 do ?)
- ISSUE 83
- Jason: summarize the final changes
- All: Nee
Hi all,
In our YANG versioning work we are proposing that a revision-label is unique
and the revision history of a module must not contain the same revision-label
twice.
We're debating whether we should state the same rule for revision *date* as
well.
RFC7950 doesn't seem to explicitly say th
at
anywhere in other models).
We're taking a closer look back at our specific problem now that we know this
is valid. It looks like it may be something else on our side (and yangLint was
correct to complain).
Jason
From: Jan Lindblad
Sent: Friday, May 21, 2021 3:57 AM
To: Sterne, Jason (No
Hi all,
In any examples I've seen where a YANG model contains a set of leafrefs to a
multi-key list, or to a list key within a list, the "current()" xpath function
is only in the 2nd leafref and never the first.
EXAMPLE A - OpenConfig ACL model
list acl-set {
key "name type";
.
YANG Versioning Weekly Call Minutes - 2021-05-04
- continue IETF issues
- continue with GitHub issues
- Jason's comments on Module Versioning
IETF 110 Minutes/Feedback on Module Versioning slides
Slide 7 (when to add rev:nbc-changes tag)
- note that there are 2 slightly different discussions we
I created issues 93 and 94 for the comparison tool issues mentioned below.
Jason
From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, April 27, 2021 10:05 AM
To: netmod@ietf.org
Subject: YANG Versioning Weekly Call Minutes - 2021-04-27
YANG Versioning Weekly Call Minutes - 2021-04-27
We
1 - 100 of 255 matches
Mail list logo
