Re: [netmod] Another question about identityref with multiple base statements

Italo, Your question is difficult to parse because: 1) the example is long without an easy way to understand it. For instance: Identities: +-- base-1 | +-- a | +-- a1 +-- base-2 +-- b +-- b1 2)

Re: [netmod] ?= ?==?utf-8?q? Augment with a when and an actio

Hi Michal, > Now, I believe there is some reason why "when" is forbidden for an "action" > although I do not know what it is. Note that Martin supports, and a room full of YANG-next-ers agreed to put it in the "Definitely Dos (MUST Solve)" category. https://github.com/netmod-wg/yang

Re: [netmod] ?= Augment with a when and an actio

Hi Machal, > okay, thanks. Then it seems it should be normally supported Yes, and note the “workaround” mentioned in the GItHub issue is essentially the solution in your OP. > and made conditional. Supporting “when” under “action” would be getting ahead of the curve, so a conditional is r

[netmod] Call for 109 discussion topics

NETMOD WG, According to the preliminary agenda [1], NETMOD is scheduled to meet for 1-hour on Wednesday, November 18th from 14:30-15:30 Bangkok time (UTC +7). If you are interested in discussing one or more topics with the WG, please send requests to the "netmod-chairs" alias (CC-ed) with the f

[netmod] Draft 109 Agenda

TMOD Chairs Agenda for the NETMOD 109 WG Session - https://datatracker.ietf.org/meeting/109/materials/agenda-109-netmod Session: Wednesday, November 18 UTC+07: 14:30-15:30 WG Chairs: Lou Berger (lberger at labs dot net) Kent Watsen (kent plus iet

Re: [netmod] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances

As a contributor: I don’t like the YIN format, but Lada makes some good points below. I don’t understand the "extraction code should not be needed any more” comment, but know that Shepherds and, to a lesser extent, Copy Editors, rely on being able to extract the YANG modules and/or instance exa

Re: [netmod] I-D Action: draft-ietf-netmod-geo-location-05.txt

Chris updated the draft per comments from Tom Petch received during the WGLC back in March (yes, it’s been that long). Tom, can you review the updates to see if all your concerns were addressed? Thanks, Kent // as Shepherd > On Nov 11, 2020, at 4:26 PM, Christian Hopps wrote: > > https://

Re: [netmod] Mailing List

Hi Zidago, Please self-subscribe here: https://www.ietf.org/mailman/listinfo/netmod Thanks, Kent > On Nov 18, 2020, at 2:47 AM, z...@sakotechnologies.com wrote: > > Hi > > Asking to be added onto the mailing list. > > Thanks > > Regards > > Z

[netmod] Regarding IPR on draft-tao-netmod-yang-node-tags-06

Authors, Per the 109 session, it is the chairs intent to do another adoption call on the "yang-node-tags” draft. In preparation for that, we’ve determined both that the draft has changed significantly and that there is a new author, and therefore feel it necessary to issue another IPR call, as

Re: [netmod] Regarding IPR on draft-wwx-netmod-event-yang-10

Forwarding to public list for visibility. Kent // as co-chair > On Nov 23, 2020, at 11:05 PM, Qin Wu wrote: > > I am not aware of any IPR that applies to this draft. > > -Qin > -邮件原件- > 发件人: Lou Berger [mailto:lber...@labn.net] > 发送时间: 2020年11月24日 7:09 > 收件人: Qin Wu ; Igor Bryskin ;

Re: [netmod] Regarding IPR on draft-tao-netmod-yang-node-tags-06

Thank you, authors. All authors responded with "No, I'm not aware of any IPR that applies to this draft”. Kent (as co-chair) > On Nov 23, 2020, at 6:01 PM, Kent Watsen wrote: > > Authors, > > Per the 109 session, it is the chairs intent to do another adoption

[netmod] Adoption poll for draft-tao-netmod-yang-node-tags-06

This email begins a 2-week adoption poll for: https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-06 Please voice your support or technical objections on list before the end of December 21, any time zone. Thank yo

Re: [netmod] Regarding IPR on draft-tao-netmod-yang-node-tags-06

Correction. Some authors replied: "No, I'm not aware of any IPR that applies to this draft”. While others replied: "No, I'm not aware of any non-disclosed IPR that applies to this draft." K. > On Dec 7, 2020, at 5:28 PM, Kent Watsen wrote: >

Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags-06

mp;id=draft-tao-netmod-yang-node-tags> [2] https://datatracker.ietf.org/ipr/4216/ <https://datatracker.ietf.org/ipr/4216/> NETMOD Chairs > On Dec 7, 2020, at 5:33 PM, Kent Watsen wrote: > > This email begins a 2-week adoption poll for: > > https://tools.ietf.

Re: [netmod] Regarding IPR on draft-tao-netmod-yang-node-tags-06

Another correction, not all authors responded. We’re still pending a response from Liang. Thanks, Kent > On Dec 7, 2020, at 5:39 PM, Kent Watsen wrote: > > Correction. > > Some authors replied: > > "No, I'm not aware of any IPR that applies to this dr

Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags-06

that diffs can be tracked from the -06 baseline. PS: All IPR responses have been collected. Thank you Liang for getting yours in. Kent (and Lou) > On Dec 7, 2020, at 5:46 PM, Kent Watsen wrote: > > FYI, this is the second adoption call (the first was in July). > > Accordi

[netmod] Reminder: NETMOD Versioning Interim - Feb 20221

NETMOD is hosting a virtual interim this coming Monday (in ~45 hours).ICS file attached to this message.NETMOD Agenda for Interim (virtual)Date            February 1, 2021Start Time      14:30 UTCDuration        90 minutesTime Zone Converter:     https://www.timeanddate.com/worldclock/converter.htm

Re: [netmod] MD5 in ianach ex-RFC7317

Hi Tom, > MD5 has long been deprecated as in RFC6151, RFC8573(NTP). > > The NTP YANG I-D, ntp-yang-data-model, imports ianach without any constraint > and so goes against RFC8573. > > I think we should update ianach to deprecate MD5 by adding a status clause. > This is a permitted update per

Re: [netmod] MD5 in ianach ex-RFC7317

> I agree, but it takes an I-D to do the update, yes? > > > I don't see why; the registry is expert review and we are doing a change that > comes under permitted changes for a YANG module, ie a status change. My understanding is that a publication of a draft altering an IANA registry will tri

Re: [netmod] MD5 in ianach ex-RFC7317

> > It happens in the TLS WG, for example, where the registries of security > options are Expert Review and when an e-mail comes to IANA, which may be from > outside the IETF, the reviewers raise it on the TLS list and if they are > satisfied with the support, tell IANA to go ahead. Gotcha. R

Re: [netmod] MD5 in ianach ex-RFC7317

> > The more interesting bit is what IANA has to say about this registry: > > iana-crypt-hash YANG Module RFC 7317 >Expert Review (Expert: Unassigned) > > Perhaps we should focus more on finding a volunteer willing to take > the role of the Designated Expert..

Re: [netmod] MD5 in ianach ex-RFC7317

> On Feb 10, 2021, at 11:46 AM, tom petch wrote: > > Not quite for me. The current version is that on the IANA website, RFC7317 > is history at least for IANACH so I think that the YANG reference for the > update should be to the IANA website. > Please provide OLD/NEW text. FWIW, RFC8407

Re: [netmod] MD5 in ianach ex-RFC7317

Hi Tom, > I would start with a reference clause to the current version on the IANA > website. Please propose specific text. Thanks, Kent // expert reviewer hat ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

[netmod] Draft minutes posted

The NETMOD 110 draft minutes have been posted: https://datatracker.ietf.org/meeting/110/materials/minutes-110-netmod-00 Please provides comments/fixes to the list. Thanks, Kent and Lou __

Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match

> The chairs can guide you on procedure but it is the WG members, you, me and > everyone else who have to do the work and so declare their willingness, or > not, to take up the work which the chairs then use to decide whether or not > the work should happen in the WG. Thank you Tom for mentio

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

etf-netmod-yang-instance-file-format. > I removed already agreed items from this mail and provided answers as > BALAZS3 below. > Are you OK with my answers, corrections? What is the next step forward? > > I updated the draft to -13, but did not upload it yet. > Regards Balazs >

Re: [netmod] Please fill in WG Summaries - https://trac.ietf.org/trac/ops/wiki/IETF110summary

Oops, netconf --> netmod K. > On Apr 12, 2021, at 5:15 PM, Kent Watsen wrote: > > Joel, > > During the chair’s call, Lou and I decided to ask you to do this, if your > willing… ;) > > Kent and Lou > > > >> On Mar 11, 2021, at 1:04 PM, Warren

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

emoved already agreed parts. > What is the next step? Time for me to attempt the shepherd writeup again, and then publish it for IESG review. K. > Regards Balazs > > From: Kent Watsen mailto:kent+i...@watsen.net>> > Sent: 2021. április 2., péntek 2:20 > To: Balázs Lengye

Re: [netmod] Compatibility of config=false data

> That said I do not think this optional information fields modelling technique > was the intention in the majority of published modules that do not specify > mandatory-stmt in config=false nodes. It is just that RFC7950 has > mandatory=false specified as default and this works better for confi

Re: [netmod] Module updating rules (adding actions)

Hi Jernej, > Should I post a technical errata for this? Yes, please do - thanks! K. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref to multi-key list: can only use current() in 2nd leafref

> Thanks for the excellent detailed response Jan. +1 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

Hi Michael! There isn’t a standard of any sort, but as an active author of a large number of drafts, I’ve been force to automate as much as possible: - validating the schema - validating examples - generating tree diagrams - stitching all off the above into an XML file - on a per-build

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

> Good thing we are not discussing YANG-next... Sarcasm? ;) I do wonder if it’s not about time we make another go at that effort...perhaps a 111-hum on interest? That said, there’s a world apart from WG-interest and author-commitments. In either case, said effort wouldn’t complete for some

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

> > Good thing we are not discussing YANG-next... > > Sarcasm? ;) > > No. The NETMOD WG has repeatedly decided not to produce a new YANG language > version in which the yang-version string is changed. That’s not possibly true. It's a matter of “when", not “if”, unless you’re anticipating

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

> I meant the current work is using extensions instead of new language > statements. > Not that the yang-version will never be changed in the future. Ah, okay. > It is not a matter of "when" if new functionality is added via extensions. > In theory the WG could add new functionality to YANG 1

Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

Hi Michael, >> New assertion type for the voucher necessary for >> agent-proximity. Likely to enhance the enum in the YANG module for the >> voucher in [RFC >> 8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3) > > Kent, how do we do add a new enum? > Does the grouping help us at a

Re: [netmod] Reuse of SZTP-CSR YANG definition in BRSKI-AE

[future threads about SZTP should CC NETCONF, the WG that published/maintains SZTP] Hi Steffen, > Hi Kent, > > There is a further YANG related question in the context of BRSKI-AE. > > In one use case, the pledge has no direct connection to the registrar and a > registrar-agent communicates

Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

> On Jun 18, 2021, at 4:09 PM, Michael Richardson wrote: > > > Kent, my appologies for not putting enough context with my email. > Andy, thanks for the clarification. > > As I understand, in order to add a new assertion to RFC8366's leaf > "assertion", we have to revise RFC8366. > > Question

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

> Anyhow, cynicism aside, there is a list of eight IANA-maintained modules to > use as exemplars. > > Tom Petch And five more IANA-maintained modules to-be with "draft-ietf-netconf-ssh-client-server" and "draft-ietf-netconf-ssh-client-server". K. ___

Re: [netmod] system configuration sync mechanism

[CC-ing NETMOD, as I think this discussion belongs on that list...please consider removing NETCONF in your reply] Hi Qiufang, > Hi, Kent: > Thanks for kicking off some discussion around this draft. Please see my reply > inline. I'm interested in this work, as it seems as if the datastore wa

Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

> On Jun 29, 2021, at 8:36 PM, Michael Richardson wrote: > > > Rob Wilton (rwilton) wrote: >> An RFC8366bis is the right option. If the changes are minor then I may >> be able to ease the passage through the IESG, but I can't do much to >> affect the elapsed time. If considering a bis, can

Re: [netmod] system configuration sync mechanism

[Thanks for removing NETCONF from the CC] Hi Qiufang, > Right, the loopback interface is a common example but, more generally, I > think "resource-independent” configuration might fall into exactly two > categories: > > 1) config that is “applied” immediately >

Re: [netmod] system configuration sync mechanism

Hi Qiufang, > Hi , Kent: > Apologies for the delay. I missed your reply and never saw it in my > inbox(bugs?) L. > Thanks for the detailed examples and explanation, and now I have a better > understanding about your proposal. > Please see my reply inline. No worries about the delay. I didn’t

[netmod] The 111 Agenda has been updated

15:30 PDT) WG Chairs: Lou Berger(lberger at labs dot net) Kent Watsen (kent plus ietf at watsen dot net) Joel Jaeggli(joelja at bogus dot com) Available During Session: WG ICS: https://datatracker.ietf.org/meeting/111/sessions/netmod.ics ICS: https://datatracker.ietf.org/me

Re: [netmod] system configuration sync mechanism

ed in will be activated until client-supplied config references it. But any client able to do this already knows how merges into and is accounting for it. Thoughts? Kent > On Jul 16, 2021, at 6:24 AM, maqiufang (A) wrote: > > Hi, Kent, > Please see my reply inline. >

Re: [netmod] system configuration sync mechanism

Hi Balazs, Andy, Quifang, > I agree a new datastore will just add complexity without any value. > Your solution approach is better, but I think it would require a new YANG > version > to allow config node XPath to reference non-config nodes. In no case is there a need for a config Xpath to ref

Re: [netmod] system configuration sync mechanism

> I prefer neither. > I think NMDA with an origin-filter and/or with-origin parameter > already solves this problem. Some of the nodes defined in may be referenced by nodes defined in . There is a desire for the nodes to not be defined only in , for online/offline validation. K. _

Re: [netmod] system configuration sync mechanism

I am confused by the confusion ;) You all know that JUNOS implemented this concept before YANG was even a thing, right? Admittedly, it’s not a “datastore“, but flexing the NMDA is where we can do better. A “with-system” mechanism could also work. The only downside is the inability for a

Re: [netmod] system configuration sync mechanism

There was a request for concrete use cases. This email from before was good: https://mailarchive.ietf.org/arch/msg/netmod/v5cNLcC2F_OT8t-407F3Zj6Vws4/ More below: > On Aug 9, 2021, at 6:23 PM, Andy Bierman

Re: [netmod] system configuration sync mechanism

> It was a different email I think proposing extensions instead of a datastore. This email: https://mailarchive.ietf.org/arch/msg/netmod/SHRPSxHIDxsfF2t0GXXiyFHOnGw/ K. ___

[netmod] Draft 111 minutes posted

NETMOD WG, The draft minutes from the 111 session have been posted: https://datatracker.ietf.org/meeting/111/materials/minutes-111-netmod-00 Please take a moment to ensure that your valuable comments have been captured. Kent and Lou (and Joel) _

[netmod] virtual interim prep

WG and Authors of draft-ma-netconf-with-system, Per the 111 session, the chairs discussed having a virtual interim. If the WG agrees, we’d like to schedule one for sometime in October. Before scheduling, we feel that use-cases should be nailed down better, taking into account all the WG comme

Re: [netmod] system configuration sync mechanism

> >IMO this draft overlaps the factory-default datastore. > >Unfortunately, RFC 8808 does not document NMDA, Appendix A3 details > >https://datatracker.ietf.org/doc/html/rfc8342#appendix-A.3 > > > >It does not say if datastore feeds int

Re: [netmod] Draft 111 minutes posted - syslog

Hi Tom, > I note the reference to syslog model 26 being back in the WG. > > This puzzles me. I see that the status has been changed to 'Dead' and that > it has dropped off the datatracker for Netmod. I realise that it depends on > keystore and client-server which have moved on but I am unclea

Re: [netmod] Revision-labels within filenames

>> Sorry, I was on PTO for the meeting where this was discussed. I don't think >> that it is great that the character needs to be encoded in a URL. How often are YANG module names in URLs? A website for downloading modules would reference modules by URL but, as Joe said, the encoding would

[netmod] Doodle pool for Virtual Interim on System Configuration

As Jason just reminds us, it was proposed to have a Virtual Interim to continue the discussion on the System Configuration topic, which generated over 40 messages by Qiufang, Balazs, Andy, Fengchong (frank), Juergen, Jason, Qin, Jan, and myself. Many timezones are spanned by the contributors a

Re: [netmod] Doodle pool for Virtual Interim on System Configuration

options tied for third place... K. > On Sep 27, 2021, at 9:59 PM, Kent Watsen wrote: > > As Jason just reminds us, it was proposed to have a Virtual Interim to > continue the discussion on the System Configuration topic, which generated > over 40 messages by Qiufang, Balazs,

Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2021-10-12

Folks, Attached is a Calendar invite for next week’s virtual interim on System Configuration. FWIW, the selected time slot scored the highest on the Doodle poll. Everyone except one (Frank) could make it, with a couple being “if need be” (thank you!) Slides have been prepared summarizing the

[netmod] Call for 112 discussion topics

NETMOD WG, According to the preliminary agenda [1], NETMOD is scheduled to meet for 1-hour on Thursday, November 11th from 14:30-15:30 UTC time. If you are interested in discussing one or more topics with the WG, please send requests to the "netmod-chairs" alias (CC-ed) by October 24th with the

[netmod] NETMOD Virtual interim in less than 12 hours

In case you didn’t see other messages from the Secretariat and/or me, please ne aware that the Virtual Interim stats in ~12 hours! Details: WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=netmod Session ICS: https://datatracker.ietf.org/meeting/interim-2021-netmod-0

[netmod] Draft minutes for NETMOD 112 session uploaded

/112/session/netmod - WG Documents: https://datatracker.ietf.org/wg/netmod/documents/ ## Session: - Thursday, November 11, 2021 - Session II (14:30-15:30 UTC, 9:30-10:30 EST, 12:30-13:30 PDT) ## WG Chairs: - Lou Berger(lberger at labs dot net) - Kent Watsen (kent plus ietf at

Re: [netmod] [Errata Verified] RFC8792 (6739)

I do not think this Errata should've been verified because RFC 7991 says that use of this tag is optional. 2.9. Marks text that are phrases defined in [BCP14] such as "MUST", "SHOULD NOT", and so on. When shown in some of the output representations, th

Re: [netmod] Must offline-validation of alone be valid?

Hi Jan, > On Nov 23, 2021, at 12:56 PM, Jan Lindblad wrote: > > Sergio, Qiufang, > >> Hi Jan, >> You correctly wrote: >> >> Then the choices become: >> Offline validation of alone is NOT required >> Servers internally validate via validating >> >> SB> but in fact this is what declared

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

Hi Andy, > RFC 7950 rules about leafref validation are very clear. > Adding a new datastore to these rules requires a massive change to NMDA > and all implementations. Not really or, rather, it seems like it would be just part of adding support for , which implies adding support for (if not sup

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

Hi Juergen, > On Nov 29, 2021, at 6:49 PM, Jürgen Schönwälder > wrote: > > On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote: >> >> IMO the least disruptive solution possible should be used. >> There is a use-case for adding "origin" support to the datastore >> in the operation.

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

> On Nov 30, 2021, at 3:00 AM, Jürgen Schönwälder > wrote: > > On Tue, Nov 30, 2021 at 02:24:52AM +, Kent Watsen wrote: >> Hi Juergen, >> >> >>> On Nov 29, 2021, at 6:49 PM, Jürgen Schönwälder >>> wrote: >>> >>

Re: [netmod] Must offline-validation of alone be valid?

Hi Jan, > Here you are introducing two concepts that the RFCs (6020, 7950, 8342) are > never mentioning: online and offline validation. Then you say that because > the RFCs don't talk about these concepts, the behavior is undefined. I > strongly disagree. The RFCs talk about validation, and des

Re: [netmod] Must offline-validation of alone be valid?

Juergen/Andy, > Option #3 > > There is a client on the system that makes changes to running just > like any other remote clients can make changes to running. System > generate config that is not editable explicit config in running goes > straight into the applied config in operational. This does

Re: [netmod] Must offline-validation of alone be valid?

Hi Jason, > I think we have a potential solution for this system config that keeps the > running valid. But I'm far more worried about configuration templates. I > don't see how we can possibly keep valid with config templates. > That seems like a major problem to me. But if we ever declare th

Re: [netmod] Must offline-validation of alone be valid?

Hi Jason, > 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 >

Re: [netmod] "immutable" flag

Hi Jason, Quifang, > I think there are use-cases for "immutable" even outside of system config so > we may not want to restrict it to system config. > [Qiufang Ma] Agree that we can just define such an “immutable” flag without > restricting it to decorating system configuration. In that way, ma

Re: [netmod] Must offline-validation of alone be valid?

> On Dec 8, 2021, at 5:50 PM, Andy Bierman wrote: > > 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

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

Hi Jason, > The primary config use cases I see aren't so much interfaces, cards, > etc. It is more for things like built in qos profiles and other handy policy > objects that are more static (e.g. like Kent's JUNOS examples he has > described). I'm not necessarily saying we preclude some of t

Re: [netmod] too long lines from IANA module inclusion

> On Dec 12, 2021, at 5:11 PM, Michael Richardson wrote: > > > Carsten Bormann wrote: >> On 2021-12-12, at 22:17, Michael Richardson wrote: > >>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it RFC8791. >> […] >>> What I don't know how to deal with: > >> RFC 8792? > >

Re: [netmod] Must offline-validation of alone be valid?

Hi Andy, > I do not have any problem with containing active and inactive nodes. > That's what has been in place for over 10 years. That's what is written in > NMDA. For posterity, it’s been “in place” only in proprietary implementations. It would be nice to resurrect the “conditional-enableme

Re: [netmod] Must offline-validation of alone be valid?

Hi Andy, >> 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

Re: [netmod] Must offline-validation of alone be valid?

Hi Andy, >> 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 doesn't validate against the YANG model.

Re: [netmod] Must offline-validation of alone be valid?

Hi Jan, >> Of course, some will point to Section 5.1.3: >> >>However, MUST always be a valid configuration data tree, >>as defined in Section 8.1 of [RFC7950] >> . >> >> But it has to be obvious that this is a bug. For instanc

Re: [netmod] Must offline-validation of alone be valid?

Hi Jan, >> It is also notable that RFC 8341 say nothing about the fact that clients >> effected by NACM may not be able to pass validation (it’s not even >> mentioned). > > That a client with insufficient privileges may have trouble understanding or > controlling a server is no surprise to me.

Re: [netmod] Must offline-validation of alone be valid?

>> Right, and in both cases, the idea was that contains all >> data needed for the transformation into . So a client that >> wants to do "offline" validation would need the data + the >> transformation algorithms. But no additional data. >> > > Having to know proprietary transformation algor

Re: [netmod] too long lines from IANA module inclusion

Hi Benoit, >>> `pyang` and I think `yanglint` also know how to extract folded >>> and elements. >> Just a correction; pyang doesn't extract anything, but rfcstrip does, >> and it supports folded artwork, and in the latest greatest 1.3 release >> it even reconizes the proper RFC8792-defined magic

Re: [netmod] Must offline-validation of alone be valid?

Andy, et. al., >> I cannot find any RFC text that says has only nodes created by a >> client. > > Really? Interesting. Still, I know it’s a mantra we’ve held closely for > many year, right? > > No. Quite the opposite. There was a brouhaha back when I proposed the "keystore” draft have

Re: [netmod] too long lines from IANA module inclusion

> (15 equals signs left, 16 equals signs right) seems to be the favorite > lead-in; however, draft-wing-dnsop-structured-dns-error-page-01.txt had a > version indented by 2 characters that has 14+15 accordingly. About 5 % > 10+11, apparently before RFC 8792 was published so there was less spa

Re: [netmod] too long lines from IANA module inclusion

Hi Carsten, >>> Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn’t have any >>> “===“ decoration, though. (Why the heck was this left open as a choice for >>> the author? I like “%%%” decoration instead, should I use that as a >>> personal fashion statement?) >> >> Because some

Re: [netmod] Must offline-validation of alone be valid?

I cannot find any RFC text that says has only nodes created by a client. >>> >>> Really? Interesting. Still, I know it’s a mantra we’ve held closely >>> for many year, right? >>> >>> No. Quite the opposite. >> >> There was a brouhaha back when I proposed the "keystore” draft have

Re: [netmod] Camel Case versus hyphenation

The fist couple paragraphs here apply: https://datatracker.ietf.org/doc/html/rfc8407#section-4.3.1 I think that it should be “open-wait” (not openwait). Mimicking RFC values is not as important as having consistency in YANG-driven UI. Happy 2022 y’all! :) K. > On Dec 31, 2021, at 7:50 AM,

[netmod] Regarding IPR on draft-ietf-netmod-rfc6991-bis-11

Authors, Contributors, WG, As part of WG Last Call: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft” or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclo

[netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Dear NETMOD WG, This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th. Here is a direct link to the HTML version of the draft: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html Positive comments, e.g., "I've

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

; > I have reviewed this document, no concerns. I believe it is ready for > publication. > > Regards, > Reshad. > > On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen > wrote: > > > Dear NETMOD WG, > > This message begins a two-week WGLC for

[netmod] The new "with-system" I-D

[As a contributor] This message merely provides some insight behind the latest update to the "with-system" draft. [PS: “with-system” is now a misnomer, it is a holdover from when the solution mimicked the “with-defaults” RFC.] The latest “with-system” draft is nearly the polar-opposite of the

[netmod] The "resolve-system" parameter in the new "with-system" I-D

[As a contributor] This message regards the value of the "resolve-system” parameter defined in the latest “with-system” draft. The "resolve-system” parameter is defined in its own optional-to-implement module. The question is if the WG believes the parameter is valuable or if the module shou

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Move to close this Errata without accepting it. Kent // as co-chair > On Feb 17, 2022, at 5:53 PM, Randy Presuhn > wrote: > > Hi - > > On 2022-02-17 1:01 PM, SADOVNIKOV, ALEXEI wrote: >> Randy, >> I definitively see that point, and the line of sparing usage can be somewhat >> subjective.

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

> after being fully processed/loaded it should be non-ambiguous if you >> > assumed every statement was applied at the same instant) ? >> > >> > Some examples: >> > - a YANG container shouldn't appear twice in a single edit-config (i.e. >&

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Thank you everyone that participated, the Last Call for this draft is closed successfully! Authors, please let the chairs know when the issues have been resolved and the draft is ready to be progressed for IESG review. Kent > On Feb 3, 2022, at 9:54 PM, Kent Watsen wrote: > > De

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

ing I-Ds over the > weekend. This change probably requires a check with the WG. (If we > were to put it back, I would still suggest to call it revision-date as > this is also how this thing is called in RFC 7950). > > /js > > On Mon, Feb 28, 2022 at 11:34:19PM +, Ke

Re: [netmod] Taking up the syslog mantle

[adding "netmod-chairs" to CC, moving "netmod" to BCC] Joe, Thank you! Here's the XML for v23 (note: v26 is current, hopefully the diffs aren't too bad): https://www.ietf.org/archive/id/draft-ietf-netmod-syslog-model-23.xml

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi Andy, The draft allows individual data instance nodes (e.g., in a list) to be flagged as immutable: The following terms are defined in this document: immutable: A metadata annotation indicating the immutability of a data node. An immutable data node is read-only to clients. N

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

> I assume that the etag defined in your I-D is the same as the one defined in > Restconf. Does or should your draft include a statement like: > “The etag values maintained by the server are protocol/interface independent. > If requested the same etag values will be visible on all interface inc

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

Hi Jan, > On Mar 24, 2022, at 4:37 PM, Jan Lindblad wrote: > > f this isn't obvious, here's an example: > 1. Client A sends an edit to the server If-Unmodified-Since t0. Successful. > Receives a Last-Modified timestamp t1. > 2. Client B sends a an edit to the server. Last-Modified timestamp on

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

> I don’t see a specific need for timestamps, so I can accept your arguments > against it. Just add a sentence about it somewhere into the draft. It can be > an appendix. > > > OK with me. > A timestamp could be added in the future if it is really important enough. LastModified is drop-dead

<    3   4   5   6   7   8   9   10   11   >