[netmod] WGLC on draft-ietf-netmod-rfc8407bis

This email begins a two-week WGLC on: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ Please take time to review this draft and post comments by May 20. Favorable comments are

Re: [netmod] IPR on call on draft-ietf-netmod-rfc8407bis-11

None of the authors are aware of any IPR. Please note that Qin’s response isn’t threaded correctly, but can be found here: https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/ Kent > On Apr 29, 2024, at 6:05 PM, Kent Watsen wrote: > > Authors, Contrib

[netmod] IPR on call on draft-ietf-netmod-rfc8407bis-11

Authors, Contributors, WG, As a prerequisite for the WGLC on this document: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11 Are you aware of any IPR that applies to draft

Re: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

following repo has been created for you: https://github.com/netmod-wg/schedule-yang. Kent and Lou > On Mar 26, 2024, at 11:49 AM, Kent Watsen wrote: > > NETMOD WG, > > This email begins a 2-week adoption poll for: > > A Common YANG Data Model for Scheduling >

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

> This can never happen since the '#' char is not allowed in a YANG module name. > YANG 1.1 tools look for MODNAME[@DATE].EXT. > If the YANG module name is not in this format the tool will not find the > module. https://datatracker.ietf.org/doc/html/rfc7950#section-5.2 says: The name

[netmod] WGLC on system-config-05

This email begins a two-week WGLC on: System-defined Configuration https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/ Please take time to review this draft and post comments by April 12. Favorable comments are especially welcomed. There is no known IPR for

Re: [netmod] IPR Call on draft-ietf-netmod-system-config-05

Chongfeng > > 发件人: Kent Watsen [mailto:kent+i...@watsen.net] > 发送时间: 2024年3月26日 9:31 > 收件人: maqiufang (A) ; Qin Wu ; > Chongfeng Xie > 抄送: netmod@ietf.org > 主题: IPR Call on draft-ietf-netmod-system-config-05 > > Authors, Contributors, WG, > > As a prerequis

[netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

NETMOD WG, This email begins a 2-week adoption poll for: A Common YANG Data Model for Scheduling https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang PS: This draft moved from OPSAWG to NETMOD There is no known IPR on this draft:

Re: [netmod] IPR Call on draft-ma-opsawg-schedule-yang-04

All authors and contributors have responded indicating no awareness of IPR applying to this draft. The adoption call may proceed now. Kent // chair > On Mar 25, 2024, at 7:44 PM, Kent Watsen wrote: > > [This draft moved from OPSAWG to NETMOD] > > > Authors

Re: [netmod] IPR Call on draft-ietf-netmod-system-config-05

No, I'm not aware of any IPR that applies to this draft. Kent // contributor > On Mar 26, 2024, at 11:40 AM, Kent Watsen wrote: > > My last message didn’t tag all authors and contributors. > > This message adds to the “To” line the following additional authors and

Re: [netmod] IPR Call on draft-ietf-netmod-system-config-05

My last message didn’t tag all authors and contributors. This message adds to the “To” line the following additional authors and contributors: - Chong Feng - Kent Watsen - Jan Linblad - Jason Stern Kent // chair > On Mar 25, 2024, at 9:30 PM, Kent Watsen wr

[netmod] IPR Call on draft-ietf-netmod-system-config-05

s filed for this draft: https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-netmod-system-config. Thanks. Kent Watsen (as co-chair) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

[netmod] IPR Call on draft-ma-opsawg-schedule-yang-04

he list above, and not unicast it. PS: Currently no IPR is filed for this draft: https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ma-opsawg-schedule-yang Thanks. Kent Watsen (as co-chair) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

>> Thanks, >> Jason (+ chairs Kent and Lou) >> >> Draft Agenda for the NETMOD 119 WG Session >> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod >> https://datatracker.ietf.org/meeting/119/session/netmod >> >> Session: >&g

Re: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

) to "draft-ietf-netmod-immutable-flag-00" and upload to data tracker. Any adoption-comments should be addressed in a -01 version. No IPR was reported: https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/ Thanks, Kent and Lou > On Feb 22, 2024, at 12:41 PM

Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

and tree-diagram views. K. > On Mar 5, 2024, at 11:21 AM, Italo Busi > wrote: > > I like the idea of relying on tooling with hyperlinks > > For txt and pdf, I agree that a link is the best option since these formats > are not optimized for including YANG trees >

Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

It seems that there are two camps: 1) those that want the tree-diagrams to be as DRY as possible 2) those that want the tree-diagrams to be as WET as possible DRY = Don't Repeat Yourself WET = Write Every Time Tooling can help both cases. For

Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

Hi Italo, > On Mar 4, 2024, at 1:38 PM, Italo Busi > wrote: > > I am wondering whether the issue of YANG tree too-long could be resolved by > updating the IETF tooling. For example, I have noted that the html-ized > version of the I-Ds is now working well with artwork exceeding the 72 >

[netmod] WGLC on node-tags-11

This email begins a two-week WGLC on: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11 Please take time to review this draft and post comments by March 14. Favorable comments are especially welcomed. Aside: this draft went through a WGLC six months ago, to which

Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

Hi Jan, > On Feb 28, 2024, at 9:21 AM, Jan Lindblad wrote: > > Med, author team, > > Thank you for taking the time to get this work done, and well done! This is > one of those fundamental bricks that saves time and improves quality for the > entire YANG community. > > I read the -09 version

Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

Hi Med, I’ve been slow to provide follow-up responses to you regarding the "Adherence to the NMDA" and "Security Considerations" sections, which I have refined even more since our last interactions here. 1) In the Adherence to the NMDA section, I know that I pushed before to invert the

[netmod] Adoption call for draft-ma-netmod-immutable-flag-09

NETMOD WG, This email begins a 2-week adoption poll for: YANG Metadata Annotation for Immutable Flag https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09 There is no known IPR on this draft:

Re: [netmod] IPR poll for draft-ma-netmod-immutable-flag-09

Thank you authors and contributors for your responses. No IPR is being declared at this time. Kent (and Lou) > On Feb 12, 2024, at 5:50 PM, Kent Watsen wrote: > > Authors, Contributors, WG, > > As a prerequisite for the adoption on this document: > > YAN

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

Juergen, Tom, Andy, Gentle reminder. Kent // shepherd > On Nov 14, 2023, at 4:49 PM, Kent Watsen wrote: > > Juergen, Tom, Andy, > > The previous WGLC for this draft didn’t succeed due to your comments. > Qin’s update (1) below removes all the (metric) specific

Re: [netmod] Rfc8407 - what does this text mean?

netmod mailto:netmod-boun...@ietf.org>> De la > part de Kent Watsen > Envoyé : vendredi 16 février 2024 21:55 > À : Andy Bierman mailto:a...@yumaworks.com>> > Cc : netmod@ietf.org <mailto:netmod@ietf.org> > Objet : Re: [netmod] Rfc8407 - what does this text mea

Re: [netmod] Rfc8407 - what does this text mean?

efine a “temporary non-NMDA module”. PS: top-posting for simplicity K. > On Feb 16, 2024, at 3:25 PM, Andy Bierman wrote: > > > > On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen <mailto:kent%2bi...@watsen.net>> wrote: >> NETMOD, >> >> An IESG member rev

[netmod] Rfc8407 - what does this text mean?

NETMOD, An IESG member reviewing one of my drafts flagged a section I had written to satisfy this text from https://datatracker.ietf.org/doc/html/rfc8407#section-3.5: If the document contains a YANG module(s) that is compliant with NMDA [RFC8342], then the Introduction section

[netmod] IPR poll for draft-ma-netmod-immutable-flag-09

Authors, Contributors, WG, As a prerequisite for the adoption on this document: YANG Metadata Annotation for Immutable Flag https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09 Are you aware of any IPR that applies to draft identified above? Please

Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

Hi Mohamad, Thanks for the response. Some thoughts below. K > On Feb 8, 2024, at 3:36 AM, mohamed.boucad...@orange.com wrote: > > Hi Kent, all, > > Let’s me also provide some background and explain why we are not using any > normative language for enum vs identities. We used to have this

Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

Hi Mohamad, Thanks for the response. Some thoughts below. K > On Feb 8, 2024, at 3:36 AM, mohamed.boucad...@orange.com wrote: > > Hi Kent, all, > > Let’s me also provide some background and explain why we are not using any > normative language for enum vs identities. We used to have this

[netmod] rfc8407bis IANA guidance (enums vs identities)

Authors, WG, Following is a comment on Section 4.30.2. https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.2 The text says: START An IANA-maintained module may use identities (e.g., [RFC8675]) or enumerations (e.g., [RFC9108]). The decision about which

[netmod] rfc8407bis IANA module identifier name

Authors, WG, Following is a comment on Section 4.30.3.1. https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.3.1 The text says: "The name of the "identity" is the lower-case of the name provided in the registry.” Yet Section 4.3.1. (Identifier Naming Conventions)

Re: [netmod] Draft Minutes for Virtual Interim

The draft interim minutes have been updated. Thank you Jason, Jurgen, and Carsten for your valuable comments. Link to minutes: https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/ The minutes are reproduced below for convenience. Please report any updates needed here.

Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2024-02-06

Reminder that NETMID is having another Virtual Interim a week from today. Kent > On Jan 22, 2024, at 10:22 AM, IESG Secretary wrote: > > The Network Modeling (netmod) WG will hold a virtual interim meeting on > 2024-02-06 from 09:00 to 11:00 America/New_York (14:00 to 16:00 UTC). > > Agenda:

[netmod] Fwd: Draft Minutes for Virtual Interim

Hi Juergen, > Well, statements like "the WG agrees" are problematic for things that > have not been discussed on the mailing list. Perhaps it is the people > attending the interim agreed? Well, I can't tell, I have not been > there... Maybe but… - it was an official Interim meeting (not just

Re: [netmod] Draft Minutes for Virtual Interim

it may work in circumstances where the operator doesn’t use > templates or inactive config *or* the client reproduces the server logic for > the running->intended transforms > > Jason > > From: netmod mailto:netmod-boun...@ietf.org>> On > Behalf Of Kent Watsen > Sent:

[netmod] Draft Minutes for Virtual Interim

Link to minutes: https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/ Reproduced below for convenience. Please report any updates needed here. Kent (and Lou) This virtual interim was soley focused on the "system-config" draft. Qiufang Ma presented. Draft:

Re: [netmod] Proposed date for Interim on immutable-flag-09

I’m going to schedule this Interim now but, please be advised that, per Jan’s comment on for the "system-config” interim, the “CET” label should’ve been “UTC” instead. Kent > On Jan 11, 2024, at 6:18 PM, Kent Watsen wrote: > > Dear NETMOD WG, > > The chairs wo

[netmod] Proposed date for Interim on immutable-flag-09

Dear NETMOD WG, The chairs would like to schedule an Interim meeting to discuss draft-ietf-netmod-immutable-flag. - note that this is in addition to the Interim on Jan 23 for the system-config draft. Considering various time-options with Qiufang, as author, with Chinese Lunar New Year

Re: [netmod] YANG to TypeScript?

> On Jan 3, 2024, at 4:58 AM, Ladislav Lhotka wrote: > > Kent Watsen mailto:kent+i...@watsen.net>> writes: > >> Thanks Lada! >> >> >>> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka wrote: >>> >>> Hi Kent, >>> &g

Re: [netmod] YANG to TypeScript?

Thanks Lada! > On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka wrote: > > Hi Kent, > > it's not exactly what you are asking for but FWIW Yangson has a method > DataModel.schema_digest [1] > that returns a “schema digest” - a JS object that contains all information > that is necessary for such a

[netmod] YANG to TypeScript?

In the “here’s something different” category… I’m interested in creating an SPA (single page application) on top of a RESTCONF server. Popular SPA frameworks include AngularJS, Ember.js, ExtJS, Knockout.js, Meteor.js, React, Vue.js, and Svelte. TypeScript is a used by these frameworks to

Re: [netmod] Operational State usage of YANG choices and constraints

With limited experience wrt the impact on servers, as a client, it’s always best for the opstate data to be modeled as accurately as possible, for better processing and user experience. K. > On Dec 22, 2023, at 1:37 PM, Acee Lindem wrote: > > We’ve had some discussions as to whether YANG

Re: [netmod] Proposed date for Interim on system-config-04

son >> (perander) >> Sent: Monday, December 4, 2023 7:05 PM >> To: Kent Watsen ; netmod@ietf.org >> Subject: Re: [netmod] Proposed date for Interim on system-config-04 >> >> >> CAUTION: This is an external email. Please be very careful when clicking

[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

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

Juergen, Tom, Andy, The previous WGLC for this draft didn’t succeed due to your comments. Qin’s update (1) below removes all the (metric) specific node-tags. All that is left now is the generic mechanism for tagging nodes. Can you confirm that this update (-11) addresses your concerns? Thanks,

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

My confusion, sorry, I was thinking “mandatory”. Must statements on opstate are useful, but less important. Kent > On Nov 6, 2023, at 5:26 PM, Kent Watsen wrote: > > “Must” statements on opstate usefully helps clients know when certain values > will always appear, ena

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

“Must” statements on opstate usefully helps clients know when certain values will always appear, enabling better optimization and usability. E.g., for Syslog messages, there must always be a timestamp, severity, and a message. It would be unhelpful for the server to not declare its intention

Re: [netmod] MUST offline-validation of alone be required? possible solution and further discussion

Hi Jan, RFC 8342 defines the ability for "configuration transformations” to map to , which is "subject to validation”.Section 5.1.4 describes cross-cutting features, such as deactivating nodes and templating, that can result in an invalid , when is considered alone. However, clients

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

This was my thought as well, that it would be best to have the smallest-possible draft update 6020/7950. That way, when someone follows the “Updated” links, they’re not overloaded with material that could’ve been left out. Jason was saying that just doing MUST/SHOULD by alone isn’t great,

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

[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

[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

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

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

[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

[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

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

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

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

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

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

[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

[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

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

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

ot;. That 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

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

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:

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:

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

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

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

oposal? > > 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 is a direct link to

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

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

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

; 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 > > > > -----邮件原件- > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ke

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

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 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] IPR Poll on draft-ietf-netmod-yang-semver-09

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

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

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

t;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 my reply inline

[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

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

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

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

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 Kent Watsen > Sent: 03 April 2023 22:23 &

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

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

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

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 ,

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)

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

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

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 a

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

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

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

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

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

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

  1   2   3   4   5   6   7   8   9   10   >