Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

> JANL: I could accept watering down MUST NOT to SHOULD NOT. > BALAZS3: Sorry, I know system-set data has its problems, but my arguments > still stand. > > [Qiufang] SHOULD NOT is fine from my perspective. > > SHOULD NOT is fine from my perspective also. Clearly best practice. The focus sh

[netmod] Does defining a feature require the module be implemented?

YANG Doctors, Does "foo" need to be "implemented", in order for its feature to be define? module foo { yang-version 1.1; namespace "https://example.net/foo";; prefix "f"; feature foo-feature; ... } Specifically, using the pr

Re: [netmod] Does defining a feature require the module be implemented?

must implement a module to enable > its features. > > Regards, > Michal > > [1] https://www.rfc-editor.org/rfc/rfc8525#page-11 > > On 9. 5. 2022 19:43, Kent Watsen wrote: >> YANG Doctors, >> >> >> Does "foo" need to be "implem

Re: [netmod] Does defining a feature require the module be implemented?

t; > On Fri, May 13, 2022 at 8:49 AM Robert Varga mailto:n...@hq.sk>> > wrote: > On 13/05/2022 17:03, Kent Watsen wrote: > > True, the current YANG Library structure allows features to be declared > > only for implemented modules, but I'm unsure how intentional tha

Re: [netmod] Does defining a feature require the module be implemented?

> On May 18, 2022, at 2:05 AM, Martin Björklund wrote: > >> PS: the answer to this impacts the "crypto-types and friends" drafts >> in the NETCONF WG, where it is assumed (and various tools agreed, sans >> a recent change in `yanglint`) that the implementation-status of a >> module is orthogona

Re: [netmod] Does defining a feature require the module be implemented?

Martin, Andy, > > 2) If it is the case that the module must be implemented to use its > > features, then I need to update some of my modules (e.g., crypto-types > > and friends) to explicitly disable the protocol-accessible tree when > > the module is implemented *only* to use its features. > > S

Re: [netmod] Does defining a feature require the module be implemented?

Hi Andy, > I feel vindicated, but also feel that Martin is right about this being the > solution for now. I don't even feel that it is necessarily bad. But I do > think we should act on this in some way. Here are some options: > > 1) put a "document only" errata on RFC 8525. > 2) put a "docu

Re: [netmod] Does defining a feature require the module be implemented?

Hi Lada, > But the alternative behaviour exists as well. I don't think this can be fixed > by an erratum. Please say some more. Are you referring to now-obsolete RFC 7895? What does Yangson support? K. ___ netmod mailing list netmod@ietf.org htt

Re: [netmod] 答复: 答复: A question about YANG identifier design

> On May 25, 2022, at 4:18 AM, Jürgen Schönwälder > wrote: > > I do not think there is currently a way to specify in YANG that a key > of a list is globally unique and hence a generic protocol engine won't > know which list key's have this property. I assume the current text is > there to cove

Re: [netmod] A question about YANG identifier design

> Thank you all the same for your comments! > And I also find peaple who are designing YANG module in IETF don’t like to > use uuid. They prefer to use a string for identifier. String type is generic > and easy for implementation but there is not a good way to make it global > unique and easy f

Re: [netmod] Does defining a feature require the module be implemented?

> Kent Watsen wrote: >> YANG Doctors, >> >> >> Does "foo" need to be "implemented", in order for its feature to be >> define? >> >> module foo { >>yang-version 1.1; >>namespace "

Re: [netmod] Does defining a feature require the module be implemented?

Hi Robert, >> 3) I wish more modules would following the pattern of having the global >> protocol accessible tree be defined via a "uses" of a grouping defined in >> the module. In another recent project, I had to hack the topology modules >> defined in RFC 8345 (to convert the containers to

Re: [netmod] Question about tooling for YANG Instance Data

Hi Scott, I consider myself a heavy `yanglint` user, as all examples in all my drafts are validated each time I "make" each draft, and I have several other projects that make heavy use of `yanglint` validation. I have run into a number of validation issues over years and generally first try t

Re: [netmod] Question about tooling for YANG Instance Data

t; > > From: Michal Vasko > Sent: Monday, June 6, 2022 1:59 AM > To: Scott Mansfield; Kent Watsen > Cc: netmod@ietf.org <mailto:netmod@ietf.org> > Subject: Re: [netmod] Question about tooling for YANG Instance Data > > Hi Scott, > the main developer of libyang

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

The WG State for this draft is currently: Waiting for WG Chair Go-Ahead Awaiting Expert Review/Resolution of Issues Raised What is the current status? No impact from the ip-address, ipv4-address, and ipv6-address types discussion? Ready for Shepherd writeup? Kent // as Shepher

Re: [netmod] [Technical Errata Reported] RFC7951 (7020)

> On Jul 11, 2022, at 5:17 AM, Ladislav Lhotka wrote: > > Hi, > > this erratum should be verified. > > Lada (author of the RFC) > Agreed. Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

[netmod] Draft NETMOD agenda published

July 27, 2022 15:00-17:00 Wednesday Session III Room: Independence C ## 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: ICS: https://datatracker.ietf.org/meeting/114/ses

[netmod] Must expression: how to test all instances?

Given a must-expression like this: uses ts:local-or-truststore-public-keys-grouping { refine "local-or-truststore/truststore/truststore-reference" { must 'derived-from-or-self(deref(.)/../ts:public-key/ts:public-key-format, "ct:ssh-public-key-format")'; } } Where "t

Re: [netmod] Must expression: how to test all instances?

must' expression only needs to test for "self" equivalency (i.e., the "derived-from" part is unneeded). K. > On Aug 17, 2022, at 5:08 PM, Kent Watsen wrote: > > > Given a must-expression like this: > > uses ts:local-or-truststore-public-keys-groupin

Re: [netmod] Must expression: how to test all instances?

466313a0c6f33a42a0141d1d77d81f844c> Thanks! Kent > On Aug 18, 2022, at 3:15 AM, Ladislav Lhotka > wrote: > > Hi Kent, > > can you show the schema tree, or a relevant part of it? > > Lada > > Dne 17. 08. 22 v 23:08 Kent Watsen napsal(a): >> Given a must-exp

Re: [netmod] Must expression: how to test all instances?

Hi Jernej, > Lada's second example selects everything that does not match a condition then > states such a selection should return nothing: > > not(deref(.)/../ts:public-key/ts:public-key-format[not(derived-from-or-self(., > "ct:ssh-public-key-format"))]) It works - thank-you! :) > Check i

Re: [netmod] Confused about interface type

Ensure that all modules defining identities are *implemented*. In yanglint, the -i parameter or passing each module on the command line causes them them be implemented. K. > On Aug 27, 2022, at 12:20 AM, Mahesh Jethanandani > wrote: > > I need some help figuring out why yanglint is givi

Re: [netmod] Must expression: how to test all instances?

- CA/Ottawa) > wrote: > > Hi all, > Not many people are going to understand a must statement like that. Maybe a > good idea to also describe this constraint in a description statement > somewhere in the model ? > Jason > >> -Original Message- >> F

Re: [netmod] Expiration impending:

NETMOD WG, The chairs received and discussed the following message recently: > On Sep 11, 2022, at 3:00 AM, IETF Secretariat > wrote: > > The following draft will expire soon: > > Name: draft-ietf-netmod-rfc6991-bis > Title:Common YANG Data Types > State:I-D Exists > Expires: 202

[netmod] IPR Poll on draft-ietf-netmod-with-system

[NOTE: A response is needed from all listed in this message's "To" line, the authors and contributors listed in the draft] Authors, Contributors, WG, In preparation for a WG Adoption Call: Are you aware of any IPR that applies to drafts identified above? Please state either:

Re: [netmod] IPR Poll on draft-ma-netmod-with-system (was: draft-ietf-netmod-with-system)

12, 2022, at 9:23 PM, Kent Watsen wrote: > > [NOTE: A response is needed from all listed in this message's "To" line, the > authors and contributors listed in the draft] > > > Authors, Contributors, WG, > > In preparation for a WG Adoption Call: >

Re: [netmod] IPR Poll on draft-ietf-netmod-with-system

As a named-contributor in the draft: No, I'm not aware of any IPR that applies to this draft. Thanks, Kent > On Oct 12, 2022, at 9:23 PM, Kent Watsen wrote: > > [NOTE: A response is needed from all listed in this message's "To" line, the > author

[netmod] Adoption call for draft-ma-netmod-with-system-05

NETMOD WG, This email begins a 2-week adoption poll for: https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-05 Please voice your support or objections on list before Nov 1st. Notes: 1) The authors addressed the issues raised in the 114 meeting. 2) No IPR has been dec

[netmod] Draft 115 NETMOD Agenda posted

The NETMOD 115 Draft Agenda has been posted (and attached below): https://datatracker.ietf.org/meeting/115/materials/agenda-115-netmod Please let the NETMOD Chairs (CC-ed) is any adjustments are needed. Important Notes: - Presenters, please send your slides to the NETMOD Chairs (CC-e

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

I agree with this update. Regarding the Subject line on the earlier message, no, I do not think the immutable-flag solution should be an update to NACM. Thanks, Kent // as a Contributor > On Oct 20, 2022, at 4:32 AM, maqiufang (A) > wrote: > > Hi, all > > As mentioned in the previous email

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt

Reshad, Which text in the draft are you pointing to? Thanks, Kent // as Shepherd > On Oct 17, 2022, at 10:33 AM, Reshad Rahman wrote: > > Hi, > > I believe this model is hard (impossible?) to implement with rsyslog since > with rsyslog as soon as a message is blocked/discarded, no further p

Re: [netmod] Adoption call for draft-ma-netmod-with-system-05

t all, for the the "Inactive-Until-Referenced" nodes. Whilst I recognize that it must be done for YANG 1.1, it is not nice solution (polluting and such). My only solace is in knowing that YANG-next can make it right. K. > On Oct 17, 2022, at 10:53 AM, Kent Watsen wrote: > &

Re: [netmod] Adoption call for draft-ma-netmod-with-system-05

poll that they were unaware of any IPR pertaining to this draft: https://mailarchive.ietf.org/arch/msg/netmod/l3Uwh11LfLM6VQ2psvs60-PADSY <https://mailarchive.ietf.org/arch/msg/netmod/l3Uwh11LfLM6VQ2psvs60-PADSY>. Kent and Lou > On Oct 17, 2022, at 10:53 AM, Kent Watsen wrote: >

Re: [netmod] Adoption call for draft-ma-netmod-with-system-05

Fixing typos in message below - need more coffee ;) K. > On Nov 2, 2022, at 10:00 AM, Kent Watsen wrote: > > > This draft is successfully adopted as a NETMOD WG chartered document. > > Authors, when the draft-submission window re-opens, please submit > draft-ma-net

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

Thanks for this update Juergen. I was just thinking this morning to ping you on it. ietf-yang-types: 1) The table in the "Overview" section needs to reflect new names (e.g., s/date/date-with-zone-offset/) 2) The "revision" statement needs to reflect new names (e.g., s/with-zone/with-zone-off

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

Hi Juergen, >> 3) There are two "time-with-zone-offset" typedefs (one should be >> "time-without-zone-offset"?) > > No, I only see one. My bad, I didn't see the subtype. But I may've been thrown off by the following "no-zone" types...should they be named consistently? - date-no-zone

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

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the >> most disruptive >> change to YANG that one could make. No, the most disruptive thing would be to do what roughly 1/2 of the WG was proposing before, which is to introduce now a non-backwards compatible change i

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

> The idea to encode all relevant semantics of a type in a type's name > has far-reaching consequences: > > - Are we going to deprecate counter32 and introduce > non-zero-based-counter32 because we have also zero-based-counter32? > > - Do we introduce date-and-time-with-optional-zone-offset a

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

Hi Juergen, >> I may've been thrown off by the following "no-zone" types...should they be >> named consistently? >> >> - date-no-zone --> date-no-zone-offset or date-without-zone-offset >> - time-no-zone --> time-no-zone-offset or time-without-zone-offset > > The 'no-zone' indicat

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

> On Dec 9, 2022, at 11:27 AM, Jürgen Schönwälder > wrote: > > On Fri, Dec 09, 2022 at 03:41:05PM +, Kent Watsen wrote: >> >> The current date-and-time is not ambiguous because it asserts that either a >> 'Z' or an offset is present, making imposs

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

> Nobody has asked for a 'name' version yet. I just wanted to use this > example that demonstrate that it is hard to future proof name > choices. Fine. The intended pattern wasn't clear. Knowing that there is a pattern, it's fine to not have a "name" version. Should the draft capture the int

Re: [netmod] Regarding IPR on draft-dbb-netmod-acl-03

Samier's response is needed to initiate the adoption call. Kent // co-chair > On Dec 6, 2022, at 1:15 PM, Oscar González de Dios > wrote: > > Dear NETMOD WG chairs, all, > >No, I'm not aware of any IPR that applies to this draft. > >Our co-author Samier has changed affiliat

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt

ere's anyone who's managed to make it work > > And JTBC, I'm not saying the model is wrong since it probably matches how > many/most network OSes behave. > > Regards, > Reshad. > > > On Monday, October 31, 2022, 08:03:50 PM EDT, Kent Watsen > wrote: &

[netmod] WGLC on draft-ietf-netmod-syslog-model-28

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

Re: [netmod] What to reference when importing an IANA module?

> On Jan 13, 2023, at 11:25 AM, Benoit Claise > wrote: > > Hi Tom, >> Yes I do think that people outside the IETF may be ignorant of the nuances >> of the way the IETF works and may not realise that a URL to the IANA >> website must be used in preference to an RFC. There is more to YANG m

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

[NOTE: A response is needed from all listed in this message's "To" line, the authors and contributors listed in the draft] Authors, Contributors, WG, In preparation for a WGLC Call: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'

Re: [netmod] [Editorial Errata Reported] RFC8519 (7312)

Rob, Errata should be accepted. Kent > On Jan 18, 2023, at 9:29 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8519, > "YANG Data Model for Network Access Control Lists (ACLs)". > > -- > You may review the report

Re: [netmod] [Editorial Errata Reported] RFC8519 (7313)

Rob, Errata should be accepted. Kent > On Jan 18, 2023, at 10:02 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8519, > "YANG Data Model for Network Access Control Lists (ACLs)". > > -- > You may review the report

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

Thank you all! Everyone replied: "No, I'm not aware of any IPR that applies to this draft". We'll move to WGLC as soon as the IPR call on "yang-module-versioning" completes. Kent > On Jan 16, 2023, at 5:59 PM, Kent Watsen wrote: > > [NOT

Re: [netmod] [netconf] Security text for I-D with YANG modules

[-netconf, +netmod] True, that claim seems overstated and one would think that such should be in NETMOD. Searching OPSAWG, I don't see it. Can you provide a link? K. > On Feb 20, 2023, at 12:27 PM, tom petch wrote: > > I see an I-D has appeared recently with the title > Security Cons

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

This was discussed in late 2021. I switched from: base64encodedvalue== to: BASE64VALUE= in all my drafts then. Which document are you looking at? Kent > On Feb 27, 2023, at 9:24 AM, Carsten Bormann wrote: > > On 2023-02-27, at 15:04, Ladislav Lhotka wrote: >> >> Unli

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

>> This was discussed in late 2021. I switched from: >> >> base64encodedvalue== >> >> to: >> >> BASE64VALUE= >> >> in all my drafts then. Which document are you looking at? > > RFC 8366 (from 2018). That document was published before the issue was discovered. File an Errata f

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

> On Feb 28, 2023, at 2:25 AM, Ladislav Lhotka wrote: > > Was it this thread? > > https://mailarchive.ietf.org/arch/msg/netconf/ra_KfLp2HPUZajLIYQ_MBLf-sfw/ > No, it didn't regard the sztp-csr draft's IESG LC. K. > Lada > ___ netmod mailing li

Re: [netmod] WGLC on draft-ietf-netmod-syslog-model-28

s for some time, with numerous reviews, I (as Shepherd and co-Chair) am thinking to progress it now, even though the most recent WGLC solicited only one response, being Reshad's. Are there any objections to this proposal? Thanks, Kent > On Jan 13, 2023, at 8:04 AM, Kent Watsen wrote

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

o separate Acknowledgement and Contributor sections before moving forward on this document. Once we have the new version, we can then judge if there are any missing IPR statements. Thank you, Kent and Lou > On Jan 16, 2023, at 5:59 PM, Kent Watsen wrote: > > [NOTE: A response is needed from

Re: [netmod] Changing an identity base

Italio, Can you add an item for this issue here: https://github.com/netmod-wg/yang-next/issues Including a pointer to this thread in the mail archive would be most excellent. K. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/ma

[netmod] NETMOD Agenda Updated

/agenda-116-netmod https://datatracker.ietf.org/meeting/116/session/netmod ## Session: Friday 2023-03-31 09:30-11:30 JST (00:30 - 02:30 UTC) Room: 4FG412-G413 ## WG Chairs: Lou Berger(lberger at labs dot net) Kent Watsen (kent plus ietf at watsen dot net) ## WG Secretary Jason Sterne (jason

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

This is my reading as well. Despite being published 5 years ago, the pushback comes because there’s no *programmatic* way to prevent client breakage. There is a need to have a mechanism, like the “critical” flag (1), to signal when new behavior is required. (1) https://github.com/netmod-wg/

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

Hi Andy, > No customer would ever let us take away this tenet, no matter what RFC comes > out. What tenet? That is valid or that the representation returned to clients is valid? No one is talking about (on the server) not being valid, the only nuance is in *how* the server validates , whic

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

> Perhaps Kent can help us by summarizing why he believes copying is > needed, i.e., why lazy references by name do not work for credentials > stored in TPMs. The truststore and keystore use-case entails the following concepts from the system-config draft: - Inactive Until Referenced https

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

> The fact that a draft has been adopted by a WG does not mean it will > get finished and published as a standard. I have seen documents dying, > I have seen entire WGs dying. Sure, okay, and funny. > So do the client/server/crypto/... configuration modules need any > special handling by the s

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 > documentation written in a machine-readable way. Specifically, using the > annotation to give an indication that servers MAY reject requ

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

er overall > solution. Specifically, is there a compromise that can meet 3GPP’s and ITU’s > goals without eroding the underlying NETCONF/YANG architecture? > > Regards, > Rob > > // Still no hats. > > From: netmod mailto:netmod-boun...@ietf.org>> On > Behalf Of

Re: [netmod] I-D Action: draft-ietf-netmod-node-tags-09.txt

I received a warning today that this draft will expire in 6 days. IIRC, the authors are waiting for a response from Juergen (see below). Juergen, if you can respond, that would be best. Otherwise, I'll start another round of WGLC and IPR calls tomorrow. Kent // chair > On Oct 17, 2022, at 9:14 P

Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt

> I agree. If we end up with "yang-next" as I've heard it called, this would > be a useful case to resolve. > > If we ended up with such a thing, it'd be nice to simply deprecate the > "unknown" leaves, upgrade the type from "bits" to "bits-with-unknown" (or > similar) and work from there. >

[netmod] WGLC on node-tags-09

This email begins a two-week WGLC on: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09 Please take time to review this draft and post comments by May 2nd. Favorable comments are especially welcomed. This draft went through a WGLC a year ago. The authors addressed

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

"immutable=true", unless toggled back to "immutable=false" by a descendent node. Thoughts? Kent // contributor > On Apr 17, 2023, at 5:29 AM, maqiufang (A) wrote: > > Hi, Jan > > Thank you so much for the follow-up, please see

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

Hi Qiufang, > I support ensuring XC/Y remains transactional, such that a client can always > move from valid config-A to valid config-B in a single update. I also > support requiring a "with-immutable" flag in client-requests in order for the > "immutable" annotations to be returned (like "wit

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

): > Bo Wu > lana.w...@huawei.com > > Jan Lindblad > jlind...@cisco.com > > Rgds, > Jason > >> -Original Message- >> From: netmod On Behalf Of Kent Watsen >> Sent: Monday, March 13, 2023 7:35 PM >> To: netmod@ietf.org >> Cc: Ro

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

Hi Jürgen, > My assumption so far is that an interface configuration is matched > against hardware and it is applied if there is matching hardware. In > other words, if an edit makes the interface configuration not match > the hardware anymore, then the config is simply not applied anymore > and

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

> Which merge fails? + = > If the mac-addr in running does not match the > hardware (and it has to match according to the model), then the > interface config simply will not be applied. Maybe that’s the answer. I was thinking that just the ‘key’ fields were used to “match the hardware”.

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

Hi Andy, > I hope the immutable flag will work with non-NMDA as well as the current NMDA. Yes. A non-NMDA server can still: Present YANG modules having the "immutable" extension statements. It's up to the clients if they understand it and, if not, then nothing changes. Return the "immutable

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

7; should not be changed. > So it's marked with 'immutable' is reasonable. If someone try to modify it, > reporting error from server should be acceptable. I take this as an agreement to the below discussion. Thanks, Kent > > > > -邮件原件- > 发件人:

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

Hi Jürgen, > I am not sure I follow. If I replace the line card, I may have to > update the type of the interface config. Why would this be disallowed? Nothing is being disallowed, by this proposal. There is no new server behavior. The proposal only enables a server to programmatically describ

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

> Where in the NC or YANG RFCs do we talk about immutable data? Where in > the interfaces data model do we define that the type leaf becomes > immutable once a line card has been plugged into a slot? Following is from RFC 7223. Note that the description statement almost says that the value is

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

Hi Qiufang, > I think that it is undesirable to support the "with-immutable" request > parameter on non-configuration datastores. The reason why is that I believe > the "with-origin" flag is more useful. If the "origin" is "system", then > immutability is "true". > Is this true: If the “origi

Re: [netmod] WGLC on draft-ietf-netmod-syslog-model-28

tions to this proposal? > > Thanks, > Kent > > >> On Jan 13, 2023, at 8:04 AM, Kent Watsen wrote: >> >> Dear NETMOD WG, >> >> This message begins a two-week WGLC for draft-ietf-netmod-syslog-model-28 >> ending on Friday, January 27th. Here

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

Dear NETMOD WG, This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11 and draft-ietf-netmod-yang-module-versioning-09 ending on Monday, May 22nd. Neither draft has IPR declared. Here are the direct links to the HTML version for these drafts: - https://datatracker.

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

NETMOD WG, The chairs are extending this WGLC by two weeks (now ending June 5) in order to ensure adequate review, since this is important work, and a solid consensus is needed. Kent and Lou > On May 8, 2023, at 6:49 PM, Kent Watsen wrote: > > Dear NETMOD WG, > > This m

Re: [netmod] Query RFC-8348 hardware model

Forwarding to the authors of the RFC. K. > On May 30, 2023, at 3:47 AM, Vanapatla Ramana (Nokia) > wrote: > > Hello Team, > > Gentle remainder on the below query. > > Regards, > Ramana > > From: Vanapatla Ramana (Nokia) > Sent: Friday, May 5, 2023 8:05 PM > To: draft-ietf-netmod-ent...

Re: [netmod] Query RFC-8348 hardware model

Forwarding to the authors of the RFC. K. > On May 30, 2023, at 3:47 AM, Vanapatla Ramana (Nokia) > wrote: > > Hello Team, > > Gentle remainder on the below query. > > Regards, > Ramana > > From: Vanapatla Ramana (Nokia) > Sent: Friday, May 5, 2023 8:05 PM > To: draft-ietf-netmod-ent...

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

Hi Quifang, The latest update looks very good to me - IMO, ready for adoption. Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed? Thanks, Kent > On May 25, 2023, at 8:16 AM, maqiufang (A) > wrote: > > Hi, all > This version reflects the input we've received fr

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

at said, I believe that an even better versioning-solution can be had if integrated into the YANG-language directly. Kent > On May 22, 2023, at 6:20 PM, Kent Watsen wrote: > > NETMOD WG, > > The chairs are extending this WGLC by two weeks (now ending June 5) in order &

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

Hi Martin! > I think you meant https://github.com/netmod-wg/yang-next/issues/49. Yes but, in spirit of the idea, I suppose both would be in play, if at all. >> IMO the parsing of YANG files to produce a conceptual data model >> is a critical component of the language itself. Any statements th

[netmod] IPR Poll on draft-haas-netmod-unknown-bits-02

[NOTE: A response is needed from all listed in this message's "To" line, the authors and contributors listed in the draft] Authors, Contributors, WG, In preparation for an Adoption Call: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm

[netmod] Call for IETF 117 Slot Requests

NETMOD WG, The *draft* agenda for IETF117 has been posted - https://datatracker.ietf.org/meeting/117/agenda The NETMOD session information is scheduled to be held: Wednesday, July 26, 2023 09:30-11:30 Tuesday Session I Room: Continental 6 https://datatrack

Re: [netmod] Unknown bits - backwards compatibility

Hi Jeff, I’ve been hoping you would reply to some of the comments here before kicking off the WGLC. Specifically, I’m wondering if it makes sense to add a new section to provide guidance to implementors? I’m unsure myself, as the concerns raised seem to be addressed by YANG Library, in that

Re: [netmod] Unknown bits - backwards compatibility

H Jeff, > I hadn’t realized that your intent was to skip directly to WGLC, unless this > was a typo. Most WG process I deal with goes through at least a thin > adoption stage even if the intent is to move forward swiftly to last call. I meant “adoption”. No process skipping here! >> Specif

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

Cherry picking a few items below. > [Rob Wilton (rwilton)] > I think that the document is unclear about how it interplays with the system > datastore, e.g., I find very few references to the system datastore, so I > think that it would be helpful for that to be clarified. > [Qiufang] Sure. That

Re: [netmod] Call for IETF 117 Slot Requests

/meeting/117/sessions/netmod.ics ^— this is the same URL, but it’s a different ICS file. - if you accepted the earlier ICS, be sure to delete it first and then re-accept the new one. Kent > On Jun 28, 2023, at 9:56 AM, Kent Watsen wrote: > > NETMOD WG, >

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

spent many hours in the regular working meetings. Thank you, Lou and Kent > On May 8, 2023, at 6:49 PM, Kent Watsen wrote: > > Dear NETMOD WG, > > This message begins a joint two-week WGLC for > draft-ietf-netmod-yang-semver-11 and > draft-ietf-netmod-yang-module-versio

Re: [netmod] Lines too long in YANG tree diagrams

Hi Italo, > On Jul 5, 2023, at 5:58 PM, Italo Busi > wrote: > > RFC8340 suggests to use the "--tree-line-length 69" option to produce YANG > tree diagrams to be included into an Internet-Draft or RFC. > > Although this option works well in many cases, there are few cases where > pyang produ

Re: [netmod] Lines too long in YANG tree diagrams

> But what I do for readability and to avoid lint issues is use rfcfold on > trees or examples that have long lines. For the examples that are xml or > json based, the consumer of the RFC needs to reverse the fold so that the > example works in yanglint or other tools. It would be ideal for D

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

NETMOD WG, This email begins a 2-week adoption poll for: https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02 There is no known IPR on this draft (IPR call ). Please voice your support or technical objecti

[netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

Authors, Contributors, WG, As a prerequisite for the adoption on this document: Are you aware of any IPR that applies to draft 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

Re: [netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

Hi Balazs, Can you response to this IPR poll please? FWIW, your response to this poll is not indicative of your support for the draft, which is what the adoption poll is for. Kent > On Aug 22, 2023, at 9:46 AM, Kent Watsen wrote: > > Authors, Contributors, WG, > > As a p

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

Thank you everyone that participated in the poll. Based on the results, there isn’t sufficient support to adopt the draft at this time. Kent and Lou > On Aug 3, 2023, at 2:02 PM, Kent Watsen wrote: > > NETMOD WG, > > This email begins a 2-week adoption pol

[netmod] Adoption poll for draft-ma-netmod-immutable-flag-08

NETMOD WG, This email begins a 2-week adoption poll for: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08 There is no known IPR on this draft (IPR call ). Please voice your support or technical objecti

[netmod] Poll on YANG Versioning NBC Approach

WG, Please help the YANG-versioning effort move forward by participating in the following poll: - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login required) Kent and Lou ___ netmod mailing list netmod@ietf.org https://www.ietf.org/m

Re: [netmod] Poll on YANG Versioning NBC Approach

[All, don’t forget to vote, discussion here doesn’t count! https://notes.ietf.org/netmod-2023-sept-poll] > On Sep 12, 2023, at 12:06 PM, Andy Bierman wrote: > > So there is choice between: > > (A) YANG 1.1 and SHOULD NOT > (B) YANG 1.2 and SHOULD NOT Thanks Andy, this is a succinct way

  1   2   3   4   5   6   7   8   9   10   >