Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis
Christian Hopps on Friday, March 15, 2024 20:10: >> On Mar 15, 2024, at 13:26, mohamed.boucad...@orange.com wrote: >> >> Re-, >> I’m not sure to agree with your last statement, Andy. >> The reality is that the OLD reco is inducing many cycles and waste of time >> for no obvious technical reason: see an example >> herehttps://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/ >> Let’s save the authors time with a clear guidance: >> • Pick ietf- or iana- as a function of the module > > I disagree with this guidance. Can you explain your motivation? -- Per ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis
Andy Bierman on Tuesday, March 12, 2024 15:14: > On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad > mailto:j...@tail-f.com>> wrote: >> Then we have the other thing with RESTCONF where the module names are used >> instead, which also causes some (unnecessary) confusion. If NETCONF and >> RESTCONF could use the same "prefixes", things would be easier. In the early >> days of programming (I mean in the 60's), FORTRAN programmers were told to >> choose short function and variable names. This mindset has long since been >> abandoned. Why is this still a good practice in YANG prefixes? > > I disagree with any changes to module prefixes. > They are not confusing to anybody who bothers to learn a little about YANG. > Long prefixes make YANG harder to read, not easier. I disagree with this (hence agree with Jan). It was confusing to learn that RESTCONF and NETCONF use different prefixes. Short prefixes are nice when writing, longer descriptive prefixes are better when reading. Why would otherwise other identifiers have these long form names, and not have short identifiers too? -- Per ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis
Hi! Jürgen Schönwälder on Tuesday, March 5, 2024 10:38: > I believe it is a misconception that text not written in capital letters > is not normative. Indeed. RFC 8174 Section 2. Clarifying Capitalization of Key Words states: In many IETF documents, several words, when they are in all capitals as shown below, are used to signify the requirements in the specification. These capitalized words can bring significant clarity and consistency to documents because their meanings are well defined. This document defines how those words are interpreted in IETF documents when the words are in all capitals. o These words can be used as defined here, but using them is not required. Specifically, normative text does not require the use of these key words. They are used for clarity and consistency when that is what's wanted, but a lot of normative text does not use them and is still normative. o The words have the meanings specified herein only when they are in all capitals. o When these words are not capitalized, they have their normal English meanings and are not affected by this document. -- Per ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Proposed date for Interim on system-config-04
Hi! Tuesdays 3pm-4pm CET conflicts with the module versioning meetings. -- Per From: netmod on behalf of Kent Watsen Sent: Tuesday, December 5, 2023 00:18 To: netmod@ietf.org Subject: [netmod] Proposed date for Interim on system-config-04 Dear NETMOD WG, Following up on an action from the 118 session, the chairs would like to schedule an Interim meeting to discuss draft-ietf-netmod-system-config. Considering various time-options with Qiufang, as author, it seemed that the following 2-hour slot was best for all (see table at bottom for details): Tue, Jan 23, 2024: - PST: 6am-8am - EST: 9am-11am - CET: 2pm-4pm - CST: 10pm-12am Please let us know this week if there is a conflict. Kent and Lou CET EST PST CST === === === === 10pm 5pm 2pm 6am <— maybe okay? 11pm 6pm 3pm 7am <— a little too late CET 12am 7pm 4pm 8am <— way too late CET 1am 8pm 5pm 9am <— way too late CET 2am 9pm 6pm 10am <— way too late CET 3am 10pm 7pm 11am <— way too late CET 4am 11pm 8pm 12pm <— way too early CET, a little too late EST 5am 12am 9pm 1pm <— too early CET, too late EST 6am 1am 10pm 2pm <— way too late EST 7am 2am 11pm 3pm <— way too late EST 8am 3am 12am 4pm <— way too late EST, too late PST 9am 4am 1am 5pm <— way too late EST, way too late PST 10am 5am 2am 6pm <— a little too early EST, way too late PST 11am 6am 3am 7pm <— way too early PST 12pm 7am 4am 8pm <— way too early PST 1pm 8am 5am 9pm <— a little too early PST 2pm 9am 6am 10pm <— maybe okay? ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] IETF 118 Hackathon for Revision Label in YANG tooling
Hi! I just registered the following project for the IETF 118 Hackathon. You are very welccome to join! Any feedback, experiences, or suggestions is appreciated. Revision Label in YANG tooling Champions Per Andersson peran...@cisco.com Project Info draft-ietf-netmod-yang-module-versioning defines the revision-label extension, this change also also updates the specified filename schema for YANG modules (currently module.yang or mod...@-mm-dd.yang) to also support module#revision-label.yang. Currently there are ongoing discussions about this change, if it should be or not. One question raised was that it could require a big effort to update tooling to understand the assumed filenames for a YANG module. During this hackathon we explore if changing the assumptions on filenames, and other revision label extensions, for YANG modules requires a big effort. Documentation Updated YANG Module Revision Handling YANG Semantic Versioning Code https://github.com/mbj4668/pyang https://github.com/mbj4668/yanger https://github.com/CESNET/libyang -- Per ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Poll on YANG Versioning NBC Approach
Hi! > Andy Bierman on Thursday, September 14, 2023 18:40: >> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem >> mailto:acee.i...@gmail.com>> wrote: >>> On Sep 13, 2023, at 10:36, Ladislav Lhotka >>> mailto:40nic...@dmarc.ietf.org>> >>> wrote: (...) >>> We have already seen cases that the update rules prevented fixing problems >>> in YANG modules in a straightforward way, and backward-compatible fixes >>> negatively affected module readability. This is inevitable until the >>> ecosystem of YANG modules stabilizes. That's why I think changing update >>> rules from MUST to SHOULD is appropriate - it should have been so from the >>> beginning. >> >> I wholeheartedly agree. We need to be able to fix YANG modules with NBC >> changes. I know of at least one implementation that support NBC changes for >> proprietary models with node-specific translation > > Some of us do not think a bugfix counts as an NBC change. > If the YANG definition is wrong and has been wrong from the start, then BC is > not important. > Fixing the YANG module so the definitions match the intent of the authors is > important. I don't understand why the motivation for a particular change should come into play. Either the change is NBC or BC, whether it being a bugfix or not, and the text in RFC 7950 states how it should be handled. Although I am on the vendor side in this context, as a user I find it important to be notified if a change is NBC even if it is a bugfix. It is also important to be able to both publish and consume compatibility levels on dependencies and imports, e.g. recommended-min. > IMO this new draft is not really needed at all, since bugfix exceptions > should be allowed > and should have always been allowed. I was not involved when YANG was defined, so I know little to nothing of these discussions. What I follow is the actual text in the standard, and it does not discern between classes of motivation for changes (e.g. bugfix, feature) and how they should be allowed or not. -- Per ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-08
No, I'm not aware of any IPR that applies to this draft. -- Per From: Lou Berger Sent: Monday, January 16, 2023 23:53 To: benoit.cla...@huawei.com; lana.w...@huawei.com; e...@juniper.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 Cc: NetMod WG Chairs; NETMOD Group Subject: Regarding IPR on draft-ietf-netmod-yang-module-versioning-08 Authors, Contributors, WG, In preparation for 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 disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see https://www.ietf.org/standards/ipr/ Thank you, Lou and Kent PS Please include all listed in the headers of this message in your response. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
