[netmod] Publication has been requested for draft-ietf-netmod-rfc6991-bis-15

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

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: > > [NOTE: A respo

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

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

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

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

[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

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

anaged 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: > > > Reshad, > >

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

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

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 impossible

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'

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

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

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

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

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-

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

to the IPR 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

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

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

[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

[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

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

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

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

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

ote: > > 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- >> From: netmod On Behalf Of Kent

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

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

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

2a0141d1d77d81f844c> 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-expression like th

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

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

[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

[netmod] Draft NETMOD agenda published

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

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

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

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 liby

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

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

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

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

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

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

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

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

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

gt; 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 that was. >

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

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 "implemented", in

[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

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

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

> For me, the only sensible option (other than accepting that types are > named the way they are) is to introduce ip-address-with-zone and to > deprecate ip-address and stop there. Yes, this means coexistance of > inet:ip-address and ip-address-with-zone until YANG is getting > replaced. As a

Re: [netmod] Tree diagram comment lines

> But a 40 page tree diagram isn't very useful anyway, imo. If I want > the full tree diagram I can run a tool to generate it. Tree diagrams > are best used in combination with explanatory text to explain certain > aspects of the module design. Perhaps section 3.4 in RFC 8407 should be >

[netmod] IPR Poll on draft-ietf-netmod-node-tags-06

[ Note: existing IPR declaration: https://datatracker.ietf.org/ipr/4216 ] Authors, Contributors, WG, As part of 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

[netmod] WGLC on draft-ietf-netmod-node-tags-06

This message begins a Working Group Last Call (WGLC) on draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session (minutes ). The WGLC will close in two-weeks (Apr 22). Here is a direct link to the HTML

Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

Randy! >>>date -> date-with-zone >>>date-no-zone -> date-no-zone >>>time -> time-with-zone >>>time-no-zone -> time-no-zone >> This looks like my option 'e' in the other thread. It's good because it >> makes it a conscious decision either way. > > Sorry to have duplicated

Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

Hi Randy, > That's a reasonable rationale, and might even make a good CLR if > adopted from the very beginning, but given the ability of model > designers to read too much (or too little) into names, > perhaps one might consider the possibility of eliminating this > particular source of confusion

Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

uot; from "Waiting for WG Chair Go-Ahead" by Kent >> Watsen: >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ >> > > Dear chairs, > > given recent discussions around ip addresses, I am not sure about the > consensus I just

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

Juergen et. al. , > What are our options? > > a) Do nothing and accept that types are called as they are. > b) Change the types as suggested and accept that doing so breaks > modules where zone indexes are meaningful. > c) Deprecate the types and create a new module defining new types > so

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

ipv6-address types? > > Thanks, > > Acee > > > > From: netmod on behalf of Kent Watsen > > Date: Wednesday, April 6, 2022 at 9:25 PM > To: "draft-ietf-netmod-rfc6991-...@ietf.org" > > Cc: "netmod@ietf.org" > Subject: Re: [n

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

Mar 15, 2022 at 6:01 AM Jürgen Schönwälder < >> j.schoenwael...@jacobs-university.de> wrote: >> >>> On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote: >>>> On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen >>> wrote: >>>> >>&g

Re: [netmod] RPC input parameter definition order (uses augment)

Hi Jernej, > RFC7950, 7.14.4. says: > >Input parameters are encoded as child XML elements to the rpc node's >XML element, in the same order as they are defined within the "input" >statement. > > For the following model: > > module b { > namespace "b:uri"; > prefix b; > >

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

Hi John, >> I would hope that web-based RFCs would either default to showing the >> "current" RFC or provide an easy way for clients to be aware that a >> "current" version is available and get a link to it. > > If you look at, say RFC 6376 at https://www.rfc-editor.org/info/rfc6376 > >

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

> The corrected RFC (any RFC where Errata Exists) should be available online. > Not erasing the published RFC, but with a link to rfc-current (where all > accepted Errata is applied). +1 I would hope that web-based RFCs would either default to showing the "current" RFC or provide an easy

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[CC-ing NETCONF, as this discussion (and draft) belongs there. To whomever replies to this message, please remove NETMOD from the CC-list. Thanks!] Hi Jan, >> The same rules apply: >> >> - ETag is a MUST, LastModified is a MAY >> - root-node is a MUST, inner-nodes is a MAY > > I'm

[netmod] Email Request

This is going to sound old-school, but please try to use standard email-indentations when replying to others on this list. Exception, of course, when top-posting, which is understandably preferred sometimes. Most SMTP-clients support indentation automatically, while others need to be

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

If this Errata is accepted, does it mean that an Errata will be filed for the thousands of RFCs that have been published since 2009 when the error was introduce in RFC 5691? Kent > On Mar 30, 2022, at 5:20 PM, RFC Errata System > wrote: > > The following errata report has been held for

Re: [netmod] RFC 7951 - JSON encoding of empty lists

> Also note that #1 isn't really of much use, as entire list and leaf-list > instances aren't even resources/endpoints in RESTCONF API - e.g. it's not > possible to GET the entire list. True, but the “list-pagination” drafts (adoption-call in NETCONF) seek to change this. K.

Re: [netmod] RFC 7951 - JSON encoding of empty lists

make sure I didn't miss something I verified this with yanglint 0.16.105 > (what ubuntu gave me), and that accepts #2 but not #1 (it rejects #1 with err > : Invalid JSON data (unexpected value). (/test:test/bar)). > To be really clear this is accepted: > { > "test:test": { >

Re: [netmod] RFC 7951 - JSON encoding of empty lists

#1 is an empty list (or leaf-list). This is what you want. #2 is a list containing one element, which is an empty container (or, in Python term's, an empty 'dict'). Yanglint 1.x used to accept #1, kinks are being worked out on the 2.x branch. Kent // contributor > On Mar 29, 2022, at 10:21

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

> I don’t see a specific need for timestamps, so I can accept your arguments > against it. Just add a sentence about it somewhere into the draft. It can be > an appendix. > > > OK with me. > A timestamp could be added in the future if it is really important enough. LastModified is

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

Hi Jan, > On Mar 24, 2022, at 4:37 PM, Jan Lindblad wrote: > > f this isn't obvious, here's an example: > 1. Client A sends an edit to the server If-Unmodified-Since t0. Successful. > Receives a Last-Modified timestamp t1. > 2. Client B sends a an edit to the server. Last-Modified timestamp on

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

> I assume that the etag defined in your I-D is the same as the one defined in > Restconf. Does or should your draft include a statement like: > “The etag values maintained by the server are protocol/interface independent. > If requested the same etag values will be visible on all interface

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi Andy, The draft allows individual data instance nodes (e.g., in a list) to be flagged as immutable: The following terms are defined in this document: immutable: A metadata annotation indicating the immutability of a data node. An immutable data node is read-only to clients.

Re: [netmod] Taking up the syslog mantle

[adding "netmod-chairs" to CC, moving "netmod" to BCC] Joe, Thank you! Here's the XML for v23 (note: v26 is current, hopefully the diffs aren't too bad): https://www.ietf.org/archive/id/draft-ietf-netmod-syslog-model-23.xml

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

ng I-Ds over the > weekend. This change probably requires a check with the WG. (If we > were to put it back, I would still suggest to call it revision-date as > this is also how this thing is called in RFC 7950). > > /js > > On Mon, Feb 28, 2022 at 11:34:19PM +, Kent Watsen

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

Thank you everyone that participated, the Last Call for this draft is closed successfully! Authors, please let the chairs know when the issues have been resolved and the draft is ready to be progressed for IESG review. Kent > On Feb 3, 2022, at 9:54 PM, Kent Watsen wrote: > > De

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

d/loaded it should be non-ambiguous if you >> > assumed every statement was applied at the same instant) ? >> > >> > Some examples: >> > - a YANG container shouldn't appear twice in a single edit-config (i.e. >> > shouldn't re-enter a container in the s

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

Move to close this Errata without accepting it. Kent // as co-chair > On Feb 17, 2022, at 5:53 PM, Randy Presuhn > wrote: > > Hi - > > On 2022-02-17 1:01 PM, SADOVNIKOV, ALEXEI wrote: >> Randy, >> I definitively see that point, and the line of sparing usage can be somewhat >> subjective.

[netmod] The "resolve-system" parameter in the new "with-system" I-D

[As a contributor] This message regards the value of the "resolve-system” parameter defined in the latest “with-system” draft. The "resolve-system” parameter is defined in its own optional-to-implement module. The question is if the WG believes the parameter is valuable or if the module

[netmod] The new "with-system" I-D

[As a contributor] This message merely provides some insight behind the latest update to the "with-system" draft. [PS: “with-system” is now a misnomer, it is a holdover from when the solution mimicked the “with-defaults” RFC.] The latest “with-system” draft is nearly the polar-opposite of the

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

; > I have reviewed this document, no concerns. I believe it is ready for > publication. > > Regards, > Reshad. > > On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen > wrote: > > > Dear NETMOD WG, > > This message begins a two-week WGLC f

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

Dear NETMOD WG, This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th. Here is a direct link to the HTML version of the draft: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html Positive comments, e.g.,

[netmod] Regarding IPR on draft-ietf-netmod-rfc6991-bis-11

Authors, Contributors, WG, As part of 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

Re: [netmod] Camel Case versus hyphenation

The fist couple paragraphs here apply: https://datatracker.ietf.org/doc/html/rfc8407#section-4.3.1 I think that it should be “open-wait” (not openwait). Mimicking RFC values is not as important as having consistency in YANG-driven UI. Happy 2022 y’all! :) K. > On Dec 31, 2021, at 7:50 AM,

Re: [netmod] Must offline-validation of alone be valid?

I cannot find any RFC text that says has only nodes created by a client. >>> >>> Really? Interesting. Still, I know it’s a mantra we’ve held closely >>> for many year, right? >>> >>> No. Quite the opposite. >> >> There was a brouhaha back when I proposed the "keystore” draft

Re: [netmod] too long lines from IANA module inclusion

Hi Carsten, >>> Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn’t have any >>> “===“ decoration, though. (Why the heck was this left open as a choice for >>> the author? I like “%%%” decoration instead, should I use that as a >>> personal fashion statement?) >> >> Because

Re: [netmod] too long lines from IANA module inclusion

> (15 equals signs left, 16 equals signs right) seems to be the favorite > lead-in; however, draft-wing-dnsop-structured-dns-error-page-01.txt had a > version indented by 2 characters that has 14+15 accordingly. About 5 % > 10+11, apparently before RFC 8792 was published so there was less

Re: [netmod] Must offline-validation of alone be valid?

Andy, et. al., >> I cannot find any RFC text that says has only nodes created by a >> client. > > Really? Interesting. Still, I know it’s a mantra we’ve held closely for > many year, right? > > No. Quite the opposite. There was a brouhaha back when I proposed the "keystore” draft

Re: [netmod] too long lines from IANA module inclusion

Hi Benoit, >>> `pyang` and I think `yanglint` also know how to extract folded >>> and elements. >> Just a correction; pyang doesn't extract anything, but rfcstrip does, >> and it supports folded artwork, and in the latest greatest 1.3 release >> it even reconizes the proper RFC8792-defined

Re: [netmod] Must offline-validation of alone be valid?

>> Right, and in both cases, the idea was that contains all >> data needed for the transformation into . So a client that >> wants to do "offline" validation would need the data + the >> transformation algorithms. But no additional data. >> > > Having to know proprietary transformation

Re: [netmod] Must offline-validation of alone be valid?

Hi Jan, >> It is also notable that RFC 8341 say nothing about the fact that clients >> effected by NACM may not be able to pass validation (it’s not even >> mentioned). > > That a client with insufficient privileges may have trouble understanding or > controlling a server is no surprise to

Re: [netmod] Must offline-validation of alone be valid?

Hi Jan, >> Of course, some will point to Section 5.1.3: >> >>However, MUST always be a valid configuration data tree, >>as defined in Section 8.1 of [RFC7950] >> . >> >> But it has to be obvious that this is a bug. For

Re: [netmod] Must offline-validation of alone be valid?

Hi Andy, >> Legacy clients are failing offline validation today. If running config has a >> leafref to system config, and doesn't return that system config >> (which it doesn't in some implementations), then the instance data returned >> to the client doesn't validate against the YANG model.

Re: [netmod] Must offline-validation of alone be valid?

Hi Andy, >> Andy - about use cases. Here is a problem we're trying to address: >> >> >> >> There are at least several major router implementations that have this >> concept of "hidden config" (i.e. list entries that can be referenced in a >> leafref by explicit user config, but those list

Re: [netmod] Must offline-validation of alone be valid?

Hi Andy, > I do not have any problem with containing active and inactive nodes. > That's what has been in place for over 10 years. That's what is written in > NMDA. For posterity, it’s been “in place” only in proprietary implementations. It would be nice to resurrect the

Re: [netmod] too long lines from IANA module inclusion

> On Dec 12, 2021, at 5:11 PM, Michael Richardson wrote: > > > Carsten Bormann wrote: >> On 2021-12-12, at 22:17, Michael Richardson wrote: > >>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it RFC8791. >> […] >>> What I don't know how to deal with: > >> RFC 8792? > >

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

Hi Jason, > The primary config use cases I see aren't so much interfaces, cards, > etc. It is more for things like built in qos profiles and other handy policy > objects that are more static (e.g. like Kent's JUNOS examples he has > described). I'm not necessarily saying we preclude some of

Re: [netmod] Must offline-validation of alone be valid?

> On Dec 8, 2021, at 5:50 PM, Andy Bierman wrote: > > Andy - about use cases. Here is a problem we're trying to address: > > > > There are at least several major router implementations that have this > concept of "hidden config" (i.e. list entries that can be referenced in a > leafref

Re: [netmod] "immutable" flag

Hi Jason, Quifang, > I think there are use-cases for "immutable" even outside of system config so > we may not want to restrict it to system config. > [Qiufang Ma] Agree that we can just define such an “immutable” flag without > restricting it to decorating system configuration. In that way,

Re: [netmod] Must offline-validation of alone be valid?

Hi Jason, > I'm not following your "In the meanwhile" thoughts. > > Legacy clients are failing offline validation today. If running config has a > leafref to system config, and doesn't return that system config > (which it doesn't in some implementations), then the instance data returned

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