[netmod] Grammar for new extensions (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/54 o Both YANG modules All extensions should specify the grammar; i.e., in which statements they can be present and which substatements they can have. Ack. 1st part (statements) is clear. For

[netmod] Typos and smaller issues (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/53 We'll make changes/fixes as per the comments below. All good. o 3.5 The example modules should be legal YANG modules. Use e.g. "urn:example:module" as namespace. Also, the modules

[netmod] bool v/s empty for new leafs deprecated-nodes and obsolete-nodes (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/52 o 5.2.2 Wouldn't it be better if the leaf "deprecated-nodes-implemented" and "obsolete-nodes-absent" were of type "boolean" rather than type "empty"? The bool v/s empty philosophical battle.

[netmod] Revision label in filename (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/50 o 3.3 In the filename of a YANG module, where it takes the form: module- or-submodule-name ['@' revision-label] ( '.yang' / '.yin' ) Should this section update 5.2 of RFC 7950?

[netmod] rev:status-description (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/51 o 3.4 leaf imperial-temperature { type int64; units "degrees Fahrenheit"; status deprecated { rev:status-description "Imperial

[netmod] Interpreting revision labels as YANG semantic version numbers (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/48 o 3.3 All revision labels that match the pattern for the "version" typedef in the ietf-yang-semver YANG module MUST be interpreted as YANG semantic version numbers. I

[netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/47 o 3.1.1 o In statements that have any data definition statements as substatements, those data definition substatements MAY be reordered, as long as they do not change the ordering

[netmod] Revision labels for submodules (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/49 o 3.3 Submodules MUST NOT use revision label schemes that could be confused with the including module's revision label scheme. Hmm, how do I ensure that this MUST NOT is handled

[netmod] All IETF YANG modules MUST include revision-label statements (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

Hi, https://github.com/netmod-wg/yang-ver-dt/issues/45 o 7.1 The text says: All IETF YANG modules MUST include revision-label statements for all newly published YANG modules, and all newly published revisions of existing

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

Chris, >> Security Considerations does not use template (which other grouping modules >> such as Kent's do) > > I've pinged Kent for a pointer. The template Tom is referring to is from https://tools.ietf.org/html/rfc8407#section-3.7.1. That said, I have always felt that this template is a

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Hi Balazs, > On Mar 27, 2020, at 1:36 PM, Balázs Lengyel > wrote: > > Hello, > https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12 > contains a > section with . Looking at -12, I see "” (not ), is this just a

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

> On Mar 27, 2020, at 1:09 PM, tom petch wrote: > > Kent > > Not Ready > > I thought that so obvious that it was not worth saying:-) > > e.g. > IANA considerations does not register the namespace so there is no module Will add. > Security Considerations does not use template (which other

[netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Hello, https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12 contains a section with . However rfcstrip cannot extract this part. Is that a problem? Regards Balazs -- Balazs LengyelSenior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

Kent Not Ready I thought that so obvious that it was not worth saying:-) e.g. IANA considerations does not register the namespace so there is no module Security Considerations does not use template (which other grouping modules such as Kent's do) No YANG version Wrong prefix for

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

On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund wrote: > [re-sent w/ correct address] > > Juergen Schoenwaelder wrote: > > Hi, > > > > two comments: > > > > - It is unclear to me whether this really qualifies as an errata. > > > > - If we add this, then there should probably text

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

[re-sent w/ correct address] Juergen Schoenwaelder wrote: > Hi, > > two comments: > > - It is unclear to me whether this really qualifies as an errata. > > - If we add this, then there should probably text about which > combinations are allowed. For example, for pattern and ranges, there >

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

Hi, two comments: - It is unclear to me whether this really qualifies as an errata. - If we add this, then there should probably text about which combinations are allowed. For example, for pattern and ranges, there is explicit text that says further restrictions of the value space are

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

+1 Balazs -Original Message- From: netmod On Behalf Of RFC Errata System Sent: 2020. március 27., péntek 11:18 To: m...@tail-f.com; ibagd...@gmail.com; war...@kumari.net; joe...@bogus.com; kent+i...@watsen.net; lber...@labn.net Cc: netmod@ietf.org; rfc-edi...@rfc-editor.org Subject:

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

All, The current -10 draft appears to have addressed all issues raised during the last call. Thank you to everyone that participated. I will start the shepherd review now. Hopefully it will go smoothly, as a number of issues that I raised during the WGLC were related to things that are

Re: [netmod] Where can I use ?

Hi Balazs, > OK, as you are strongly opposed to it, I will remove ENDS> in the next version. Is there a need for a “next" version? Looking at -10 (current), I only see the markers around the YANG module, which seems good, right? Kent // shepherd

[netmod] Agenda Items - Re: Network Modeling (netmod) WG Virtual Meeting: 2020-04-02

Netmod folks, now that this is scheduled if you have an item you'd like on the agenda for this meeting which you had not previously gotten in to us please send it along to netmod chairs netmod-cha...@ietf.org. Agenda items proposed so far: Netmod Ver DT presentation

[netmod] [Technical Errata Reported] RFC7950 (6031)

The following errata report has been submitted for RFC7950, "The YANG 1.1 Data Modeling Language". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6031 -- Type: Technical Reported by: Radek

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

As someone who has reviewed the draft, I want to say I support the work. The draft is short and easy to read. Thanks. > On Mar 26, 2020, at 11:46 AM, Kent Watsen wrote: > > Dear All, > > This WGLC has received zero responses, which is insufficient to progress the > document at this time.