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

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

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

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] 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 ?

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

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

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,

[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

[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:

[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

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

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

of 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,

[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

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

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

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

[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

[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)

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. ___

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

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

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

fined 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. >

[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

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

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] [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

[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

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] [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. > >

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)

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

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

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

> 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] [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

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

[netmod] Publication has been requested for draft-ietf-netmod-yang-instance-file-format-13

Kent Watsen has requested publication of draft-ietf-netmod-yang-instance-file-format-13 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format

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] 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

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] 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

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] 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

[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] 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

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

> > 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

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.

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

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

[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:     

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

), so 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] Publication has been requested for draft-ietf-netmod-geo-location-07

Kent Watsen has requested publication of draft-ietf-netmod-geo-location-07 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ ___ netmod

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 draft”.

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

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.org/html/draft-t

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: > > Than

[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

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 call

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

[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,

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 > >

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: > >

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

[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

[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

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

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.

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

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

consider updating the draft by 1) removing and/or clarifying the concerning parts and 2) presenting compelling examples, to bring this idea forward again for a future adoption call. Thanks you, Netmod Chairs > On Aug 17, 2020, at 6:05 PM, Kent Watsen wrote: > > This email begins

Re: [netmod] Draft minutes uploaded

Link still showing double periods (e.g., “..html”). Trying one last time: https://www.ietf.org/proceedings/108/minutes/minutes-108-netmod-02.html <https://www.ietf.org/proceedings/108/minutes/minutes-108-netmod-02.html> > On Aug 20, 2020, at 12:05 AM, Kent Watsen wrote: >

Re: [netmod] Draft minutes uploaded

Fixed link: https://www.ietf.org/proceedings/108/minutes/minutes-108-netmod-02.html > On Aug 19, 2020, at 5:05 PM, Kent Watsen wrote: > > > Draft minutes from the 108 NETMOD session have been uploaded here: > >https://www.ietf.org/proceedings/108/minutes/minutes-

[netmod] Draft minutes uploaded

Draft minutes from the 108 NETMOD session have been uploaded here: https://www.ietf.org/proceedings/108/minutes/minutes-108-netmod-02.html NETMOD Chairs ___ netmod

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

This email begins a 2-week adoption poll for: https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-05 Please voice your support or objections on list before August 31. Notes: 1) -03 was presented during the 108 session, hence the I-D has been updated twice since then. 2)

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

Folks, Many messages for this thread are being blocked by the list server, requiring manual effort by the chairs to release them. Here are the headers from one such message: To: Tarek Saad , tom petch , "Rob Wilton (rwilton)" , RFC Errata System , "lho...@nic.cz" , "yingzhen...@huawei.com"

Re: [netmod] rfc6991bis: loopback addresses

> Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang. > With that, your request is relatively clear now Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” that constrains inet:ipv[46]-address so that it can only contain loopback address values. >

Re: [netmod] Preliminary agenda

Session - https://datatracker.ietf.org/meeting/108/materials/agenda-108-netmod Session: Thursday July 28th UTC: 14:10-15:50 WG Chairs: Kent Watsen (kent plus ietf at watsen dot net) Lou Berger (lberger at labs dot net) Joel Jaeggli (joelja

Re: [netmod] Preliminary agenda

ssion: Thursday July 28th UTC: 14:10-15:50 WG Chairs: Kent Watsen (kent plus ietf at watsen dot net) Lou Berger (lberger at labs dot net) Joel Jaeggli (joelja at bogus dot com) Available During Session: ICS:https://datatracker.ietf.org/meeting/108/sessions/netmo

Re: [netmod] Call to presentations (was: Fwd: IETF 108 Preliminary Agenda)

IETF 108 Presenters, Please send a first draft of your presentations by Monday (a week from today), and plan to send the final version by Wednesday. Thanks you, NETMOD Chairs > On Jul 2, 2020, at 11:58 AM, Kent Watsen wrote: > > [changing the Subject line for better visibility] &g

Re: [netmod] Preliminary agenda

NETMOD WG. The agenda has been updated. Only the MeetEcho URLs changed. K. Agenda for the NETMOD 108 WG Session - https://datatracker.ietf.org/meeting/108/materials/agenda-108-netmod Session: Thursday July 28th UTC: 14:10-15:50 WG Chairs: Kent

[netmod] Preliminary agenda

: Kent Watsen (kent plus ietf at watsen dot net) Lou Berger (lberger at labs dot net) Joel Jaeggli (joelja at bogus dot com) Available Only During Session: ICS:https://datatracker.ietf.org/meeting/108/sessions/netmod.ics Jabber: xmpp:net...@jabber.ietf.org?join

[netmod] Call for presentations

[fixing typo - silly me] K. > On Jul 2, 2020, at 11:58 AM, Kent Watsen wrote: > > [changing the Subject line for better visibility] > > > All, please see the message below. > > For those that already submitted requests, there is no need to submit agai

[netmod] Call to presentations (was: Fwd: IETF 108 Preliminary Agenda)

[changing the Subject line for better visibility] All, please see the message below. For those that already submitted requests, there is no need to submit again. NETMOD Chairs > On Jun 29, 2020, at 1:53 PM, Kent Watsen wrote: > > NETMOD WG, > > According to the prelimin

[netmod] Fwd: IETF 108 Preliminary Agenda

NETMOD WG, According to the preliminary agenda (see below), NETMOD is scheduled to meet for 100-minutes on Tuesday, July 28th from 11:00-12:40 UTC. If you are interested in presenting to the WG, please send your presentation requests to the "netmod-chairs" alias (CC-ed) with the following

Re: [netmod] operation with "table join" capability

[moving 'netmod' to BCC since this question has no modeling impact] > The desired capability is: > > When a leafref or multiple leafrefs reference one or more objects specified > in other parts of the schema, the operator can use a single > operation to retrieve all attributes of the object

[netmod] Fwd: Reminder: Survey on planning for possible online IETF meetings

NETMOD WG, Please fill out this survey. Thanks! > Begin forwarded message: > > From: Alissa Cooper > Subject: Fwd: Reminder: Survey on planning for possible online IETF meetings > Date: May 5, 2020 at 7:48:03 AM EDT > To: IETF WG Chairs > > Please circulate this to your working group lists.

Re: [netmod] Erratum 5514 on NMDA [RFC 8342]

> Martin writes: >> Juergen writes: >> If I put an origin on every config leaf and config p-container, why >> would I need another origin somewhere up in the np-container hierachy? >> We seem to make rules that to some extend miss the point we are really >> trying to make, namely that every

Re: [netmod] Erratum 5514 on NMDA [RFC 8342]

One small concern with the proposed NEW text is that it suggests that an NP-container is configuration, which I think is untrue. Thusly, maybe the following tweak is better? s/except/which excludes/ NEWER: The origin for any top-level configuration data nodes, which excludes

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

ow this if possible.” > > Does anyone object to this course of action (or wishes to refine my errata > notes)? > > Regards, > Rob > > > From: Kent Watsen > Sent: 23 April 2020 17:59 > To: Andy Bierman > Cc: Radek Krejci ; Juergen Schoenwaelder > ; Martin

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

d and the issue > resolved in yang-next. > No IETF module should use this construct. It is easy to convert to an > equivalent form that is not under dispute. > > > Andy > > > On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci <mailto:rkre...@cesnet.cz>> wrote: &

Re: [netmod] Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)

[Roman: for this draft, the takeaway is that Qin’s section deviates from the template because the module doesn’t define all the parts typically found in a YANG module] Hi Rob, > [RW] > Perhaps add such as section in [], and mark it to be removed before > publication. > > E.g. [RFC Editor:

Re: [netmod] Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)

Hi Roman, > -- > DISCUSS: > -- > > Please use YANG security considerations template from > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.

[netmod] Add "token" to rfc6991-bis? (was: Re: Add "node-instance-identifier" to rfc6991-bis?)

[changing subject line] > On Apr 17, 2020, at 4:16 AM, Juergen Schoenwaelder > wrote: > > On Fri, Apr 17, 2020 at 01:13:54AM +, Kent Watsen wrote: >> >>>>>> PS: the "token” type add discussion from before never completed (again, >>>

Re: [netmod] Add "node-instance-identifier" to rfc6991-bis?

PS: the "token” type add discussion from before never completed (again, modeled after xsd:token) >> >> What about this? >> > > What would this type be good for? Any models already using something > like this? Not in a standard model, that I’m aware of but, back at Juniper, I had a

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

Hi Balazs, > P.S. Kent, if further edits are needed, shall I do them via new uploaded > versions, or shall I just send the update for checking to you? I prefer uploaded versions so I (everyone) can easily see the diffs and verify the changes made. Thanks for asking. > Because it’s a

Re: [netmod] YANG Versioning weekly meeting (not a VI!)

;UNTIL=20200811T14Z;BYDAY=TU BEGIN:VALARM X-WR-ALARMUID:55A190FE-533F-48CC-9563-CD24226D8FF6 UID:55A190FE-533F-48CC-9563-CD24226D8FF6 TRIGGER:-PT15M ATTACH;VALUE=URI:Chord ACTION:AUDIO END:VALARM END:VEVENT END:VCALENDAR > On Apr 14, 2020, at 2:25 PM, Kent Watsen wrote: > >

[netmod] YANG Versioning weekly meeting (not a VI!)

For those interested in participating in discussions on the YANG Versioning set of drafts, the following weekly 1-hour meeting has been created by request of the authors for that purpose. ICS file attached (includes a 15-minute alarm) PS: this is NOT a virtual interim! Kent // as co-chair

Re: [netmod] Add "node-instance-identifier" to rfc6991-bis?

Hi Juergen, > The definition is already in draft-ietf-netmod-rfc6991-bis-02.txt My bad (good to see it’s in there already) > but also see the DISCUSS items related to it. True, but there is a related DISCUSS under "typedef xpath1.0”... >> PS: the "token” type add discussion from before

[netmod] Add "node-instance-identifier" to rfc6991-bis?

draft-ietf-netconf-notification-capabilities imports "ietf-netconf-acm” solely to access "nacm:node-instance-identifier”. This typedef seems generally useful, would it make sense to move to rrc6991-bis? PS: the "token” type add discussion from before never completed (again, modeled after

<    1   2   3   4   5   6   7   8   9   10   >