[netmod] Re: Rob's comment to the security template

, 5 November 2024 at 08:24 To: Rob Wilton (rwilton) Cc: netmod@ietf.org Subject: [netmod] Rob's comment to the security template Hi Rob, An attempt to address a comment your raised in the netmod session can be found at: https://github.com/netmod-wg/rfc8407bis/pull/73/files. Let me know if

[netmod] Re: Regarding IPR on draft-ietf-netmod-yang-module-versioning-12

Hi, No, I am not aware of any IPR which applies to this draft. Sorry for the delayed response, Rob From: Lou Berger Date: Tuesday, 17 September 2024 at 23:07 To: Rob Wilton (rwilton) , Reshad Rahman , Balazs Lengyel , Joe Clarke (jclarke) , Sterne, Jason (Nokia - CA/Ottawa) Cc: NetMod WG

[netmod] Re: Regarding IPR on draft-ietf-netmod-yang-semver-17

Hi, No, I am not aware of any IPR which applies to this draft. Sorry for the delayed response, Rob From: Lou Berger Date: Tuesday, 17 September 2024 at 23:09 To: Rob Wilton (rwilton) , Joe Clarke (jclarke) , Balazs Lengyel , Sterne, Jason (Nokia - CA/Ottawa) , Benoit Claise Cc: NetMod WG

[netmod] Re: Regarding IPR on draft-ietf-netmod-intf-ext-yang-14 AND draft-ietf-netmod-sub-intf-vlan-model-11

Hi, No, I am not aware of any IPR which applies to either of these drafts. Sorry for the delayed response, Rob From: Lou Berger Date: Tuesday, 17 September 2024 at 22:58 To: Rob Wilton (rwilton) , Scott Mansfield Cc: NetMod WG Chairs , NetMod WG Subject: Regarding IPR on draft-ietf-netmod

[netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions

Mohamed IMT/OLN , netmod@ietf.org , Rob Wilton (rwilton) Subject: Re: [netmod] Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions [CC-ing Med] I wonder if rfc8047bis should have a recommendation to use groupings extensively? FWIW, my "c

[netmod] Re: WGLC on system-config-05

Hi authors, chairs, WG, I’m generally supportive of this work, but I think that there are still some potential corner cases that are not covered, or it isn’t entirely obvious how they are handled. Comments below. Moderate level comments: (1) p 7, sec 2.3. Inactive-Until-Referenced

[netmod] Re: WGLC on system-config-05

[Resending due to mailer issues.] Hi authors, chairs, WG, I’m generally supportive of this work, but I think that there are still some potential corner cases that are not covered, or it isn’t entirely obvious how they are handled. Comments below. Moderate level comments: (1) p 7, sec

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

to a separate experimental draft to unblock taking the module versioning draft to last call? Regards, Rob From: Andy Bierman Date: Wednesday, 10 April 2024 at 22:11 To: Rob Wilton (rwilton) Cc: Jason Sterne (Nokia) , netmod@ietf.org , Joe Clarke (jclarke) Subject: Re: [netmod] YANG Versioning

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

Hi Andy, For me, it seems likely that vendors using YANG Semver will want to use a filename that can contain the Semver label, and I still see some advantages for everyone to do it in a similar way. E.g., it is very likely that internally we will just use this format, but will probably strip o

Re: [netmod] Modeling of veth pairs

Yes possibly. Florian would you be interested in helping if we were to do that? Regards, Rob From: Scott Mansfield Date: Tuesday, 27 February 2024 at 14:16 To: Rob Wilton (rwilton) , Florian Kauer , netmod@ietf.org Subject: RE: Modeling of veth pairs Could we add this case to the intf-ext

Re: [netmod] Modeling of veth pairs

netmod-intf-ext-yang. From: Florian Kauer Date: Tuesday, 27 February 2024 at 09:02 To: netmod@ietf.org Cc: Rob Wilton (rwilton) , scott.mansfi...@ericsson.com Subject: Modeling of veth pairs Hi, I would like to model a veth pair in YANG, preferrably without proprietary models. In Linux, thes

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

could also be updated to clarify these two points. Any thoughts for the authors or WG on how to process this errata? Regards, Rob > -Original Message- > From: RFC Errata System > Sent: Tuesday, July 12, 2022 4:42 PM > To: m...@tail-f.com; war...@kumari.net; Rob Wilto

[netmod] Aiming to charter a new "Network Management Operations" WG

Hi, I just wanted to let everyone know that I'm trying to charter a new "Network Management Operations" WG. We are in the process of discussing the charter scope, WG name, and initial work, currently on the ne...@ietf.org open mailing list. I'm hoping to get put a draft version of the charter

Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

Specifically regarding MUST statements on state date, RFC 8342 section 5.3, also has this statement (which effectively aligns to Jürgen's last paragraph): SHOULD conform to any constraints specified in the data model, but given the principal aim of returning "in use" values, it is possi

Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

Hi, Looking at this erratum, I agree that it would be better that the module prefix is used consistently for references to other types within the same module, but the existing YANG is not wrong. In YANG, I generally expect prefixes are used when referencing data nodes or types in other importe

Re: [netmod] Poll on YANG Versioning NBC Approach

The two options mix things together. Option 1 says updating YANG 1 and > YANG 1.1 to allow YANG modules to be modified _based on > draft-ietf-netmod-yang-module-versioning_ but this document has much > more in it than just changing a MUST to SHOULD. [Rob Wilton (rwilton)] I think that for this

Re: [netmod] Poll on YANG Versioning NBC Approach

Further to Jan's comments, given that all organizations (vendors, SDOs, and industry consortia) producing YANG modules all occasionally update then in NBC ways to fix bugs and issues, then I presume that all pragmatic YANG tooling is obliged to handle cases where modules change in NBC ways. Hen

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

As a contributor. I think that Jeff has obviously found a modelling issue, and documenting some collective guidance on how to handle that is useful. IIRC, an effort was recently started to do an RFC 8407 (YANG Author Guidelines) bis document and depending on what and how much needs to be writt

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

Hi Martin, You may have just seen my comment to Juergen, but with an AD hat on, I think that what you propose is not a valid option. My understanding is that the IETF process does not allow an RFC to choose to ignore a MUST statement in another RFC for pragmatic reasons (I would DISCUSS on thi

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

Hi Jürgen, WG, Writing as an author: I think that the authors, who have invested a lot of time and effort in this, are really just looking for a path forward to reach consensus, if that is possible. I don't think that presenting the 3 options was intended to mean that participants just have to

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

: 09 June 2023 16:39 To: Rob Wilton (rwilton) Cc: Kent Watsen ; Jan Lindblad (jlindbla) ; Jürgen Schönwälder ; Andy Bierman ; netmod@ietf.org Subject: RE: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt Hi, Rob Thanks for sharing your concerns, but I think there

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

> -Original Message- > From: tom petch > Sent: 26 June 2023 16:41 > To: Rob Wilton (rwilton) ; Martin Björklund > > Cc: netmod@ietf.org > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts > > From: Rob Wilton (r

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

Hi Tom, > -Original Message- > From: tom petch > Sent: 26 June 2023 12:57 > To: Rob Wilton (rwilton) ; Martin Björklund > > Cc: netmod@ietf.org > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts > > From: netm

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

gt; > Hi, > > But the two drafts go way beyond fixing the problem your three > examples illustrate. [Rob Wilton (rwilton)] The actual goals of this work (i.e., the set of drafts) is aiming to address the requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf-netm

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

I'm wondering whether we are in the realm of missing the bigger picture here, or perfection being the enemy of good enough. My first example: The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has recently been rechartered to respecify the meaning of the date string in a non-backward

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

e there is definitely interest in this work, but personally I would like to see quite significant changes, and I suspect that more work is required to reach consensus. Regards, Rob From: Kent Watsen Sent: 01 June 2023 21:55 To: Jan Lindblad (jlindbla) ; Jürgen Schönwälder ; Andy Bierman ; Rob Wilto

Re: [netmod] Comments on draft-ietf-netmod-yang-module-versioning-09

Hi Juergen, Andy, With an author/contributor hat on ... It is unclear to me, from an RFC document perspective, what is being proposed here, and appreciate that each of you may have different thoughts as to what is being proposed. E.g., are you proposing: (1) That the yang module versioning dr

Re: [netmod] Unknown bits - backwards compatibility

I was looking at this draft again, and since I had read the -02 version of the draft I thought that I would send the comments here. My no hats view here (looking at the latest draft) is: * documenting something here is probably helpful because this is an issue that folks are experiencing an

Re: [netmod] Unknown bits - backwards compatibility

To: Rob Wilton (rwilton) ; Italo Busi ; Jeffrey Haas Cc: netmod@ietf.org Subject: RE: [netmod] Unknown bits - backwards compatibility Rob & Italo - are you proposing that the "raw-bits" are all always returned (whether they are known or not)? Jason From: netmod mailto:netmod-bo

Re: [netmod] Unknown bits - backwards compatibility

Italo's suggest was also how I was thinking of this. We could define a convention for how the "raw" leaf should be named relative to the bits decoded leaf, and also what type the "raw" leaf should use. E.g., in the case where the length of the bits field is known (e.g., it is defined/constrain

Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

: Kathleen Moriarty Sent: 04 April 2023 19:14 To: Stephan Wenger Cc: Rob Wilton (rwilton) ; Jürgen Schönwälder ; Joel Halpern ; Deen, Glenn ; trust...@ietf.org; netmod@ietf.org; The IESG Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata Rob, Multiple instances could be

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

:23 To: Rob Wilton (rwilton) Cc: Jan Lindblad (jlindbla) ; netmod@ietf.org Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06 Hi Rob, - In terms of properties that cannot be changed once written, I would rather see this issue framed more in the direction of it just being extra

Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

ginal Message- > From: Jürgen Schönwälder > Sent: 04 April 2023 16:43 > To: Stephan Wenger > Cc: Joel Halpern ; Rob Wilton (rwilton) > ; Kathleen Moriarty ; > Deen, Glenn ; trust...@ietf.org; > netmod@ietf.org; The IESG > Subject: Re: [netmod] [Trustees] draft-moriarty-y

Re: [netmod] draft-moriarty-yangsecuritytext vs errata

s, not giving an overview of all paths/subtrees in the module. Hence, I think that this would end up somewhat changing the template text, and having one less copy of it seems easier. Thanks, Rob > -Original Message- > From: Kathleen Moriarty > Sent: 03 April 2023 21:14 > T

Re: [netmod] draft-moriarty-yangsecuritytext vs errata

I'm getting an out-of-office bounce from Glenn, so adding trust...@ietf.org in the hope that either Kathleen or one of the other trustees is give an answer more quickly. Thanks, Rob > -Original Message- > From: Rob Wilton (rwilton) > Sent: 03 April 2023 18:19 > To: ka

[netmod] draft-moriarty-yangsecuritytext vs errata

Hi Glenn, Kathleen, In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD WG session on Friday (where the conclusion was to go the AD sponsored path), I also raised this issue with the IESG/IAB at the end of the IETF week, and someone had the suggestion of filling an errata ag

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Hi, I think that we need to be careful here. In summary, I agree with a lot of the concerns flagged by Jan, both in ensuring that we don't break existing NETCONF*/YANG configuration paradigms (*, by NETCONF, I mean NETCONF or RESTCONF), but also the approach of considering the best long-term

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

ystore drafts (since they currently state that the keys/certificates must be copied into , and I think that we are saying with NMDA that this is not required). Thanks, Rob > -Original Message- > From: Jürgen Schönwälder > Sent: 26 March 2023 13:24 > To: Rob Wilton (rwilton)

[netmod] system configuration/datastore and the keystore/truststore drafts

Hi, I'm in the process of AD reviewing Kent's keystore and truststore drafts in NETCONF. In both of these drafts, there is a desire to be able to use keys or certificates that are managed on the device, potentially as part of a TPM, and yet be able to reference those keys/certificates from the

[netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

Hi Jürgen, Netmod, & rfc6874bis interested parties, In my AD review of draft-ietf-netmod-rfc6991-bis-15, Jurgen has proposed a change to definition of the zone-id in the ip-address, ipv4-address, and ipv6-address types. These changes move the definition somewhat closer to what is in rfc6874bis

[netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

Hi Jürgen, Thanks for the draft. Please see my AD review comments below, except for a couple of comments related to the change to ipv6-address definition that I've spun into a separate thread so that I can include the interested parties of draft-ietf-6man-rfc6874bis into the discussion. Mode

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-08

.net; > lind...@cisco.com; j.shoenwael...@jacobs-university.de; > mjethanand...@gmail.com; wangzi...@huawei.com; Per Andersson > (perander) ; bill...@huawei.com; Rob Wilton (rwilton) > ; res...@yahoo.com; balazs.leng...@ericsson.com; Joe > Clarke (jclarke) ; jason.ste...@nokia.com >

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

"No, I'm not aware of any IPR that applies to this draft" Regards, Rob > -Original Message- > From: Kent Watsen > Sent: 16 January 2023 23:00 > To: netmod@ietf.org > Cc: Joe Clarke (jclarke) ; Rob Wilton (rwilton) > ; Reshad Rahman ; Balázs Lengyel &g

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

which we do not really have formal syntax. [Rob Wilton (rwilton)] +1. It is quite likely that implementations will choose some reasonable limit for most of these unlimited strings, so it isn't really that they are unlimited, but the limit is set by the implementation rather than at t

[netmod] Change in NETMOD Chairs

I've decided to reduce the number of NETMOD chairs from 3 chairs down to 2. Kent and Lou will continue as NETMOD chairs, Joel is stepping down. For the current amount of work in NETMOD, having two chairs is the optimal number. In addition, having a free third chair slot potentially allows com

[netmod] YANG module versioning: Proposed change to "Import by derived revision"

Hi Juergen, WG, draft-ietf-netmod-yang-module-versioning defines section "4. Import by derived revision" that allows an author to specify a minimum revision of a module that is allowed to satisfy a YANG import. IIRC, and hopefully you will correct me if I am wrong, you had two concerns about

Re: [netmod] [Technical Errata Reported] RFC6991 (7062)

Thanks Jurgen. I agree, I have rejected this errata. Regards, Rob > -Original Message- > From: Jürgen Schönwälder > Sent: 29 July 2022 17:21 > To: RFC Errata System > Cc: war...@kumari.net; Rob Wilton (rwilton) ; > kent+i...@watsen.net; joe...@bogus.com; lber...@la

[netmod] RFC 6991 definition of ipv4-address

Hi, Putting aside the discussion about whether we should be changing the use of ip-address vs ip-address-no-zone in existing YANG modules for the moment, I believe that the current ipv4-address|ipv6-address|ip-address definitions is either wrong, or unhelpful for two reasons: (1) It specifies

Re: [netmod] yang versioning solution complexity and alternative approaches

Hi Juergen, Thanks, please see inline ... At the moment I would like to try and make sure that I accurately understand the difference in opinion. > -Original Message- > From: Jürgen Schönwälder > Sent: 08 June 2022 16:38 > To: Rob Wilton (rwilton) > Cc: netmod@ietf.or

Re: [netmod] yang versioning solution complexity and alternative approaches

Hi Jürgen, Thank you for your feedback and apologies for the very delayed reply. The versions authors have been discussing some of the points that you raised in a lot of detail and hence I was waiting for this discussion to converge before replying to you. > -Original Message- > From

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Randy, Thanks for summarizing, but I don't really agree with your categorization for (1) or (3). My interpretation of ip-address and the related v4/v6 types, based on RFC 7950, is that implementations MUST allow clients to configure zoned IP addresses to be fully complaint with the modu

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

essage- > From: Martin Björklund > Sent: 12 April 2022 08:26 > To: Rob Wilton (rwilton) > Cc: netmod@ietf.org; l...@ietf.org > Subject: Re: [netmod] [Lsr] I-D Action: > draft-ietf-lsr-ospfv3-extended-lsa-yang- > 10.txt > > Hi, > > Here's anothe

[netmod] IP address zones in YANG

Spinning off part of the discussion into a separate thread, but keeping lsr cc'ed on the discussion. I'm trying to get a better understand of how and where zoned IP addresses should be used in YANG data models. RFC 4007 defines zones for IPv6 addresses, but not for IPv4. Even though RFC 6

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Tom, Please see inline ... > -Original Message- > From: tom petch > Sent: 13 April 2022 10:22 > To: Rob Wilton (rwilton) ; netmod@ietf.org; > l...@ietf.org > Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa- > yang-10.txt > > Fro

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi all, Thanks for the comments on this thread so far. It would be nice if we are able to come to some sort of rough consensus to a solution. I think that there is consensus that the YANG type ip-address (and the v4/v6 versions) are badly named as the prominent default type name has been given

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

I basically agree with Acee, and I think that we should do (b): b) Change the types as suggested and accept that doing so breaks modules where zone indexes are meaningful. I appreciate that this is an NBC change, but I believe that this is the most intuitive definition and is the

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

link will be in the Netmod mail archives) are open to all participants. Regards, Rob > -Original Message- > From: Jürgen Schönwälder > Sent: 16 March 2022 06:13 > To: RFC Errata System > Cc: m...@tail-f.com; war...@kumari.net; Rob Wilton (rwilton) > ; kent+i..

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

Hi William, IANA have published a new revision with the revision history fixed. iana-if-type YANG Module<https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml> Regards, Rob From: netmod On Behalf Of Rob Wilton (rwilton) Sent: 04 March 2022 14:37 To: William Lupton ; Benoit

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

Hi Andy, YANG packages are aimed at partly solving the problem you describe below. In the -00 revision of the packages draft, it included SHA hashes* (YANG leaf “checksum”) of the included modules and packages so that a client can determine that its local copy of module@A.B.C

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

Hi Andy, On this specific point: Note that with multiple release trains and the new SERMVER, it is likely that multiple [name, date, label] tuples resolve to the same [name, date] pair, making the uniqueness problem even worse. The module versioning draft explicitly disallows this. Even when us

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

Hi William, I have asked Sabrina in IANA to please publish a new revision with the history fixed. Regards, Rob From: netmod On Behalf Of William Lupton Sent: 04 March 2022 10:15 To: Benoit Claise Cc: NetMod WG Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same dat

[netmod] Last call on YANG module versioning and Semver

Hi Netmod WG, As many of you may already aware, I've been closely involved in authoring both the YANG module versioning draft (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/) and (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/). I will of course fol

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

From: Kent Watsen Sent: 22 February 2022 15:05 To: Rob Wilton (rwilton) Cc: SADOVNIKOV, ALEXEI ; RFC Errata System ; m...@tail-f.com; war...@kumari.net; Joel Jaeggli ; Lou Berger ; Randy Presuhn ; netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855) Move to cl

Re: [netmod] Use XML namespaces in YANG document examples

To: Rob Wilton (rwilton) Cc: netmod@ietf.org Subject: Re: [netmod] Use XML namespaces in YANG document examples Going back to the original issue and so top-posting. NSF Monitoring Interface YANG Data Model is on the IESG Telechat 17feb2022. It contains the text - not an easy read unless you are

Re: [netmod] Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

"No, I'm not aware of any IPR that applies to this draft" Thanks, Rob -Original Message- From: Lou Berger Sent: 31 January 2022 21:57 To: Joe Clarke (jclarke) ; Rob Wilton (rwilton) ; res...@yahoo.com; balazs.leng...@ericsson.com; jason.ste...@nokia.com; benoit.cla..

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

"No, I'm not aware of any IPR that applies to this draft" Thanks, Rob -Original Message- From: Lou Berger Sent: 31 January 2022 21:54 To: Joe Clarke (jclarke) ; res...@yahoo.com; Rob Wilton (rwilton) ; balazs.leng...@ericsson.com; jason.ste...@nokia.com Cc: NetMod

Re: [netmod] Schema Mount

Hi Michal, This isn't directly answering your questions, but I wanted to point out that YANG versioning work is currently discussing YANG packages, and how they work with Schema mount. There are weekly calls (which starts in just under half an hour), that are open to all: https://ietf.webex.c

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

Hi Martin, I think that the proposal is that should feed into rather than directly into . The reasoning for this is to allow configuration to depend on system defined configuration during validation without requiring that configuration to be copied into . Clients would still be allowed to

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

+1 to Juergen's comment. // As a contributor. -Original Message- From: netmod On Behalf Of Jürgen Schönwälder Sent: 24 November 2021 09:25 To: maqiufang (A) Cc: netmod@ietf.org Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

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

ehalf Of Kent Watsen Sent: 19 November 2021 17:06 To: Rob Wilton (rwilton) Cc: Erik Auerswald ; netmod@ietf.org; i...@ietf.org; adr...@olddog.co.uk; rfc...@rfc-editor.org; Qin Wu ; m...@lowentropy.net Subject: Re: [Errata Verified] RFC8792 (6739) I do not think this Errata should've been verif

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-08.txt

Hi Juergen, My preference would be to last call this document so that other YANG modules can make use of the new types. We can always spin a future bis document if further common types are useful. draft-ietf-netmod-yang-module-versioning also makes use of the revision-identifier type defined

Re: [netmod] Tree diagrams

Hi Tom, Med, Authors Tom, thanks for flagging these. Med, authors, please can you check if the tree diagrams in draft-ietf-opsawg-vpn-common-12 or draft-ietf-opsawg-l3sm-l3nm-18 need to be updated. If they do, then given that these documents are in the RFC editor queue then we will need to co

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

Carsten & Med, Thanks for raising this. I agree with the errata, but this will need to be hold for doc update, because we cannot create a different revision of a YANG module through the errata process. Thanks, Rob From: iesg On Behalf Of Francesca Palombini Sent: 05 October 2021 15:12 To: C

Re: [netmod] Revision-labels within filenames

> -Original Message- > From: Joe Clarke (jclarke) > Sent: 14 September 2021 20:38 > To: Rob Wilton (rwilton) ; netmod@ietf.org > Subject: Re: Revision-labels within filenames > > > I wasn't thinking of a URL to get the revision-label, I was more thinkin

Re: [netmod] Revision-labels within filenames

Hi Kent, It was the YANG package definitions that I had in mind. More details in the response that I have just sent back to Joe. Regards, Rob > -Original Message- > From: Kent Watsen > Sent: 14 September 2021 18:19 > To: Joe Clarke (jclarke) > Cc: Rob Wilton (rw

Re: [netmod] Revision-labels within filenames

> -Original Message- > From: Joe Clarke (jclarke) > Sent: 14 September 2021 17:57 > To: Rob Wilton (rwilton) ; netmod@ietf.org > Subject: Re: Revision-labels within filenames > > On 9/14/21 12:01, Rob Wilton (rwilton) wrote: > > Hi Joe, > > > &

Re: [netmod] Revision-labels within filenames

Hi Joe, 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. It would seem to make references to YANG files in YANG packages a lot more awkward to read/write. Perhaps reusing '@' is pragmatically the bes

Re: [netmod] yang-instance-file include-defaults leaf

operational state datastore [RFC 8342], then include-defaults aligns to the definition of that datastore in RFC 8342.”; Would text along these lines work? Thanks, Rob From: Balázs Lengyel Sent: 28 July 2021 23:08 To: Rob Wilton (rwilton) ; Andy Bierman Cc: NetM

Re: [netmod] yang-instance-file include-defaults leaf

Sent: 27 July 2021 18:00 To: Rob Wilton (rwilton) Cc: Balázs Lengyel ; NetMod WG Subject: Re: [netmod] yang-instance-file include-defaults leaf Hi, None of this addresses my point that a default value of "trim" is not appropriate. Simply remove the default-stmt so that a missing lea

Re: [netmod] yang-instance-file include-defaults leaf

default “trim”. Regards, Rob From: Andy Bierman Sent: 10 July 2021 17:41 To: Rob Wilton (rwilton) Cc: NetMod WG ; Balázs Lengyel Subject: Re: [netmod] yang-instance-file include-defaults leaf On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com>> wrote: Andy

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

Hi Ben, Chris, I wanted to check whether this discussion has progressed at all. This is the only remaining discuss after Roman has cleared his based on the IESG telechat discussion yesterday (thanks Roman). Regards, Rob > -Original Message- > From: netmod On Behalf Of Christian Hopp

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

Juergen, Yes, I agree that is a better phrasing. Thanks for suggesting it. Rob > -Original Message- > From: Juergen Schoenwaelder > Sent: 09 July 2021 12:50 > To: Rob Wilton (rwilton) > Cc: Balázs Lengyel ; Andy Bierman > ; netmod@ietf.org; Benoit Claise > >

Re: [netmod] yang-instance-file include-defaults leaf

Andy, Yes, when I suggested this, I was thinking that a boolean flag might be sufficient. My point being that automatically filtering out default values isn’t always the right thing to do. E.g., something along these lines: leaf exclude-defaults { type boolean; default true; description

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

but perhaps YANG metadata annotations would also work (RFC 7952). Regards, Rob From: Andy Bierman Sent: 08 July 2021 21:38 To: Rob Wilton (rwilton) Cc: Juergen Schoenwaelder ; Balázs Lengyel ; netmod@ietf.org; Benoit Claise Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-form

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

-list. If they are excluded then the consumer of the instance data file can choose any versions of the YANG modules that satisfy the import dependency." Regards, Rob > -Original Message- > From: Balázs Lengyel > Sent: 09 July 2021 08:25 > To: Rob Wilton (rwilton) ;

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

Hi Balazs, Would your inline schema not also need to specify the ietf-yang-types dependency? E.g., should it be: ietf-netconf-acm@2018-02-14 ietf-yang-types@2013-07-15 Thanks, Rob > -Original Message- > From: Balázs Lengyel > Sent: 08 July 2021 12:48 > To: Rob Wil

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

y as helpful. Regards, Rob > -Original Message- > From: Juergen Schoenwaelder > Sent: 08 July 2021 11:35 > To: Balázs Lengyel > Cc: Andy Bierman ; Rob Wilton (rwilton) > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-fi

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

Yes, I would be okay with that too. Regards, Rob > -Original Message- > From: Juergen Schoenwaelder > Sent: 08 July 2021 11:13 > To: Rob Wilton (rwilton) > Cc: Balázs Lengyel ; Andy Bierman > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review o

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

: Juergen Schoenwaelder ; Rob Wilton (rwilton) ; netmod@ietf.org; Benoit Claise Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format See inline, Balazs From: Andy Bierman mailto:a...@yumaworks.com>> Sent: 2021. július 7., szerda 20:50 To: Balázs Lengyel mailto:balaz

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

Original Message- > From: Balázs Lengyel > Sent: 07 July 2021 08:49 > To: Rob Wilton (rwilton) ; 'netmod@ietf.org' > ; a...@yumaworks.com; Juergen Schoenwaelder > > Cc: Benoit Claise > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format &

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

ules to be identified using revision labels as well as revision dates. Balazs, I'm good with most of your proposed resolutions, but have answered one further question inline below. > -Original Message- > From: Balázs Lengyel > Sent: 05 July 2021 13:47 > To: 'netmod

Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities

time. I assume that the updates to the instance-data doc are also in progress? Thanks, Rob From: Benoit Claise Sent: 05 July 2021 11:53 To: Rob Wilton (rwilton) ; netmod@ietf.org; draft-ietf-netconf-notification-capabilit...@ietf.org Cc: NetMod WG Chairs Subject: Re: AD review of draft-ietf

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

Hi Michael, > -Original Message- > From: Anima On Behalf Of Michael Richardson > Sent: 25 June 2021 21:41 > To: Toerless Eckert ; Fries, Steffen > ; an...@ietf.org; netmod@ietf.org; Kent > Watsen ; Rob Wilton (rwilton) > Subject: [Anima] revising RFC8366 -- Re

[netmod] AD review of draft-ietf-netconf-notification-capabilities

Hi, Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16 Thanks for this draft, sorry for the delay in reviewing. It looks like it is in good shape. I think that most of my comments are minor or cosmetic suggestions to potentially improve the phrasing of the text. 1. Abst

[netmod] AD review of draft-ietf-netmod-yang-instance-file-format

Hi, Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. Thanks for this document, I think that it represents important useful work for advancing the YANG ecosystem. This document is in good shape, and I mostly have minor comments but with a few more significant comments. Mai

Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07

oel jaeggli ; Rob Wilton (rwilton) > > Cc: NetMod WG Chairs ; draft-ietf-netmod-nmda- > diff@ietf.org; netmod@ietf.org > Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07 > > Hi all, > > Rob, thank you very much for your AD review!  We have just posted a new > re

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

c-editor.org > Cc: war...@kumari.net; Rob Wilton (rwilton) ; > joe...@bogus.com; kent+i...@watsen.net; lber...@labn.net; netmod@ietf.org > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6570) > > Hi, > > This errata is correct and should be verified. > > &g

Re: [netmod] Network Modeling (Concluded WG) ???

Hi Balazs, I think that you can rest easy - Netmod has not been closed. The link below looks fine now for me. Are you still seeing the same page? I presume that it was just a transient bug on the tools.ietf.org pages, and I would generally trust the datatracker pages over the "tools" ones. Re

Re: [netmod] AD review of draft-ietf-netmod-geo-location-07

Hi Chris, Thank you and the WG for your work on this document. I've requested IETF LC. Regards, Rob From: Christian Hopps Sent: 16 April 2021 22:30 To: Rob Wilton (rwilton) Cc: netmod@ietf.org; draft-ietf-netmod-geo-location@ietf.org Subject: Re: AD review of draft-ietf-netmo

Re: [netmod] AD review of draft-ietf-netmod-geo-location-07

Hi Chris, > -Original Message- > From: Christian Hopps > Sent: 13 April 2021 03:38 > To: Rob Wilton (rwilton) > Cc: Christian Hopps ; netmod@ietf.org; draft-ietf- > netmod-geo-location@ietf.org > Subject: Re: AD review of draft-ietf-netmod-geo-location-07 >

  1   2   3   4   >