Re: [netmod] YANG to TypeScript?

Kent Watsen writes: >> 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

Re: [netmod] YANG to TypeScript?

Kent Watsen writes: > 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 return

Re: [netmod] YANG to TypeScript?

> Happy and safe New Year’s Eve! > > Kent > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka PGP Key ID: 0xB8F92B08A9F76C67 __

Re: [netmod] IEEE Std 802.1Qcw invalidates trivial YANG data tree

t must not be greater"+ "than supported-list-max"; } The Xpath expression can never be true unless the "../supported-list-max" leaf exists. This is a common XPath trap, it should have been written like so: "not(count(./gate-control-entry) > ../supported-list-max)" This would be true also in the case when "../supported-list-max" doesn't exist. Lada > > Greetings, > Florian > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New guidelines for IANA in draft-ietf-netmod-rfc8407bis

of this YANG module is part of RFC 8294; see > the RFC itself for full legal notices."; > > But that is not correct. Other module use this instead: > > The initial version of this YANG module is part of RFC 7224; > see the RFC itself for full

Re: [netmod] Poll on YANG Versioning NBC Approach

list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

__ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC PGP

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

netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

-ietf-netmod-acl-extensions/. The source files can be seen at: https://github.com/boucadair/enhanced-acl-netmod/tree/main/yang. The use of the script is ACked in both the IANA module and also Section . Cheers, Med -Message d'origine- De : Ladislav Lhotka Envoyé : vendredi 25 mars 2022 15

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

conf/ra_KfLp2HPUZajLIYQ_MBLf-sfw/ Lada > > >> Was there, at the same time, any conclusion with respect to my question >> (strict or soup)? > > No, only that it was wrong and should be fixed. ;) > > > K. > >> Grüße, Carsten > > -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

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

Dne 27. 02. 23 v 14:31 Carsten Bormann napsal(a): On 2023-02-27, at 12:57, Ladislav Lhotka wrote: I this YANG-JSON valid for a `binary`? "base64encodedvalue==“ Strictly speaking it isn't because it's out of range of the base64 encoding function. Right. I think though it

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

a strict base64classic decoder is not going to accept > "base64encodedvalue==“ in the first place, because the sentence cited above > is violated. > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] question about name without prefix in XPath expression

__ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

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

"Why? What's wrong with it?" >> >> >> >> "Nothing. We decided after 13 years we like this name better." >> >> >> >> A number of issues were raised (misconfigurations, OpenConfig, etc.). >> >> >> >> >> >> What are these operational problems that are caused because of the name >> ip-address? >> >> IMO it would be far worse to take away the most important typedef in YANG. >> >> >> >> We have never heard any issues at all from customers about problems >> implementing ip-address. >> >> As Martin pointed out, the server MUST check for values such as 0.0.0.0 >> that are >> >> accepted by the typedef pattern but not the leaf semantics. Checking for a >> zone index >> >> is no different. The ip-address typedef has been clarified in the draft >> update. That is sufficient. >> >> >> >> >> >> >> >> >> >> >> >> Kent // contributor >> >> >> >> >> >> >> >> Andy >> >> >> > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [yang-doctors] Length on keys in YANG

https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Deviate replace leaf type, from typedef with default value

deviation "/repro:cont/repro:b" {     deviate replace {       type enumeration {         enum up {           value 1;         }         enum down {           value 2;         }       }     }   } } Best regards, Kristian Sällberg ___ netm

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

ublic-key-format", but it is needed to eval true only when *all* the elements have that value. Any pro-tips? I think I saw this posted before, but can't find it now... K. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/li

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

: L. Lhotka Category: PROPOSED STANDARD Source : Network Modeling Area: Operations and Management Stream : IETF Verifying Party : IESG -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _

Re: [netmod] JSON encoding of "leaf-list" nodes of type identityref

namespace-qualified forms are permitted. [1] - https://datatracker.ietf.org/doc/html/rfc7951#section-6.8 Jernej ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID

Re: [netmod] Unintended when-expression semantics in many IETF YANG modules

XPath expressions before publication? Tools cannot help much with "false positive" results of XPath evaluation, we just have to be careful and double-check especially absolute paths. Lada > > Best Regards, > /Jan Lindblad > > ___

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

the implemented/import-only status of modules. Yangson happens to use YANG library per RFC 7895 for this purpose, and features work the same for modules with conformance-type "implement" and "import". Lada > > K. > > > -- La

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

h type >> >> Features are like identities. >> They are completely decoupled from the schema tree and simply >> use the parent module to create a unique QName for reference in other >> statements. >> >> Perhaps we should work on some proposed edits for yang-next. >

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

ware Engineer > jack.rick...@microsoft.com<mailto:jack.rick...@microsoft.com> > > [Microsoft Logo] > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

writes: > Hi Lada, > > Thank you for the comments. > > Pleases see inline. > > Cheers, > Med > >> -----Message d'origine- >> De : Ladislav Lhotka >> Envoyé : vendredi 25 mars 2022 11:26 >> À : BOUCADAIR Mohamed INNOV/NET ; >>

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

ve received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ > netmod mailing lis

Re: [netmod] Use XML namespaces in YANG document examples

incompatible) solution seems to be to change the XML encoding of identityref values to be the same as in RFC 7951. Lada > > For now, there is no real problem to solve. Supporting YANG 1.1 requires the > implementation to be aware of XML prefixes in string node content. > Leaf value

Re: [netmod] Use XML namespaces in YANG document examples

ack along the lines that YANG Guidelines is only a 'SHOULD' and we >> think that we have a good reason to ignore the 'SHOULD' . To date, I have >> never agreed with the reason and go on commenting:-) If that is flack, >> then yes, I have - and will - generate flack:-) >> >

Re: [netmod] question about unprefixed path in leafref

address is listed > above. Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or dissemination) > by persons other than the intended recipient(s) is prohibited. If you receive > this e-mail in error, plea

Re: [netmod] Use XML namespaces in YANG document examples

should be included and that these > examples need to be validated (pyang and yanglint are mentioned for this). > > Does this guidance need to be updated to reflect expert review comments above? > > Thanks, > Ian > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Use XML namespaces in YANG document examples

l:ns:yang:iana-if-type"> >>>>>>>>> >>>>>>>>> eth0 >>>>>>>>> ianaift:ethernetCsmacd >>>>>>>>> DHCPv6 Relay Interface >>>>>>>>>

Re: [netmod] Use XML namespaces in YANG document examples

-type >>> 3, Alternately, the draft could specify that for the namespace >>> urn:ietf:params:xml:ns:yang:iana-if-type, the XML namespace prefix ianaift >>> MUST be used. Another XML bad practice because software that generates XML >>> programmatically should feel free to generate synthetic prefixes without >>> breaking the content, but at least this would solve the problem. >>> - >>> >>> BCP216 (RFC8407 - Guidelines for Authors and Reviewers of Documents >>> Containing YANG modules) doesn’t make any mention of how XML namespaces >>> should be used, only that example XML/ JSON should be included and that >>> these examples need to be validated (pyang and yanglint are mentioned for >>> this). >>> >>> Does this guidance need to be updated to reflect expert review comments >>> above? >>> >>> Thanks, >>> Ian >>> >>> >>> >>> ___ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

fforts. My conclusion is that usage of axes is typically causing trouble and decreasing readability+understanding in the real world In my experience, the complexity is not so much in XPath itself but rather in brittle semantics of 'when'. Lada Best Regards, /jan -- Ladislav Lhotka Head, CZ.NIC La

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

gestion from Netmod WG and YANG doctors on how to >> deal with such a case? >> >> Thanks, Italo (on behalf of co-authors) >> >>> -Original Message- >>> From: Michal Vaško [mailto:mva...@cesnet.cz <mailto:mva...@cesnet.cz>] >>> Sent: martedì

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

this will create a bit of an incentive to fix the tool. +1 Lada Regards, Robert ___ yang-doctors mailing list yang-doct...@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID

Re: [netmod] XML and prefix

/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] XML and prefix

nfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 'when' with absolute path

On 02. 01. 22 10:43, Martin Björklund wrote: Hi, Ladislav Lhotka wrote: Carsten Bormann writes: On 2021-12-30, at 13:29, tom petch wrote: when "../../../../../../nw:network-types/tet:te-topology/“ I’m probably showing my ignorance about YANG again, but what is the r

Re: [netmod] YANG 'when' with absolute path

On 31. 12. 21 16:38, Andy Bierman wrote: On Fri, Dec 31, 2021 at 2:01 AM Ladislav Lhotka <mailto:ladislav.lho...@nic.cz>> wrote: Carsten Bormann mailto:c...@tzi.org>> writes: > On 2021-12-30, at 13:29, tom petch mailto:ie...@btconnect.com>> wrote:

Re: [netmod] YANG 'when' with absolute path

when "ancestor::node()/nw:network-types/tet:te-topology" Lada > > ? > > Grüße, Carsten > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailma

Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

Carsten Bormann writes: > On 18. Dec 2021, at 19:04, Ladislav Lhotka wrote: >> >>'foo: null'? Doesn't that make testing for empty values a major >>pain? 'if (foo)' would not work. > > Same with »false«, which 7951 is not escaping into an array. This >

Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

1 (and before it RFC 8040) extended YANG to be able to describe >> data in flight, there is no intention that YANG can be used to describe the >> entire expressibility of the representation format. We have Relax-NG, CDDL, >> and a few other modeling approaches if we need that. > >> Grüße, Carsten >> > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Resolving schema node identifier

o the "unique" in the deviation would be wrong. >> >> Right; I was thinking that since "c" didn't have a prefix, it would >> belong to "mod_a", and thus work as expected. >> >> I think it is ok to solve this by requiring a prefix in this case. > > What you are saying is that you would be fine with the deviation not working > with no prefix in the example and stick to the rule of using the current > (context) node to get modules for non-prefixed identifiers? > > @Lada You seem to suggest some special handling of paths in deviations (or > what exactly)? Not really. If we wanted to extend the rule from sec. 6.4.1 that Martin cited to deviations, the only candidate for the "current node" is the root node. On the other hand, sec. 6.4.1 is about XPath context, and the argument of "unique" contains schema node identifiers, i.e. NOT XPath. > > Neither really seem like a proper solution and, more importantly, > interpreting "unique" paths (non-prefixed identifiers) according to XPath > contradicts what I was told those few years back (I will try to find the > mailing list communication if necessary), which is that for "schema node > identifiers" the current module is the module where the statements are > "physically" written, not that of the current node. > > We keep hitting these problems because the use-cases vary greatly and the > most complex ones were probably not anticipated when writing the specs. > Still, the code must handle all the use-cases somehow and we have huge > problems with that. > > I would appreciate any exact rules that we can agree on. The existing rules in RFC 7950 seem unclear/contradictory. This is in sec. 7.12 on "grouping": Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used. Prefix mappings, type names, grouping names, and extension usage are evaluated in the hierarchy where the "grouping" statement appears. And this is then in sec. 7.13 on "uses": The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module. Lada > > Michal > >> > > > > /martin >> > > > > > > > > > /martin >> > > > > > > > > Finally, I am asking because I am trying to implement this >> > > > > > > > > correctly >> > > > > > > in yanglint. I have also tried to test these examples with >> > > > > > > pyang,> > >> > > > > > > > which, however, seems to not have any consistent rules applied >> > > > > > > because >> > > > > > > it loads these examples without warnings. No warnings are printed >> > > > > > > even >> > > > > > > if the "unique" in the deviation is changed to "b c", which is >> > > > > > > definitely wrong since node "b" belongs to "mod_b" and node "c" >> > > > > > > belongs to "mod_a". >> > > > > > > > Thanks, >> > > > > > > Michal >> > > > > > > > [1] >> > > > > > > > https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3> > >> > > > > > > > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 >> > > > > > > > ___ >> > > > > > > netmod mailing list >> > > > > > > netmod@ietf.org >> > > > > > > https://www.ietf.org/mailman/listinfo/netmod >> > > > > ___ >> > > netmod mailing list >> > > netmod@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Resolving schema node identifier

t;mod_a". Thanks, Michal [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3> > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

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

ple break the offending line like this: namespace "urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type"; The conventions of RFC 8792 should be used only where it is absolutely necessary. Lada > > Unsure about module-extractor. My guess is that it will barf ;) >

Re: [netmod] RFC7950 s.11 and 9127-bis

me later. The I-D is in WG Last Call ending > 20Dec2021 > > Tom Petch > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

On 29. 11. 21 14:32, Robert Varga wrote: On 26/11/2021 09:30, Ladislav Lhotka wrote: And what do yo do with Early Allocation, which can last more than a year? Sorry, I am not familiar with early allocations, what could be the problem here? The problem is that early allocations are temporary

Re: [netmod] IANA registries

Carsten Bormann writes: > On 2021-11-24, at 09:13, Ladislav Lhotka wrote: >> >> Please let me know what you think about this. > > I think it is amazing. > > So for each registry, you have > > — manually extracted an information model and kept that in your head,

Re: [netmod] IANA registries

tom petch writes: > From: netmod on behalf of Ladislav Lhotka > > Sent: 24 November 2021 08:13 > > Hi, > > I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets > for generating YANG modules directly from IANA registries. The results are i

[netmod] IANA registries

stry-based YANG module needn't be published in an RFC that is not intended to be updated. There are concerns that people may extract such a module from the RFC long after it becomes obsolete. Please let me know what you think about this. Thanks, Lada -- Ladislav Lhotka Head, CZ.NIC Labs

Re: [netmod] Printable or visible string in YANG

ada /jan On 18 Oct 2021, at 13:24, Ladislav Lhotka wrote: Hi Balazs, Unicode (if you mean it) is so convoluted that the notion of printable/visible characters doesn't make much sense. It is IMO much safer to specify character classes that you want to permit. Lada On 18. 10. 21 12:11

Re: [netmod] Printable or visible string in YANG

___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman

Re: [netmod] NULL value for uint16

use otherwise some programming languages (JavaScript) don't make distinction between null values and missing properties. Lada > > > Randy >> >> > Andy > > >> ___ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailm

Re: [netmod] NULL value for uint16

t; leaf. > > I see no NULL at least in this context in RFC7950. > > Tom petch > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav L

Re: [netmod] IANA managed YANG modules

> > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/m

Re: [netmod] looking for practical advice on managing YANG source in XML format RFCs

Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] inet:ipv4-address

quot;obvious" names > (i.e., you want zoned addresses you use "-zoned" types e.g., > "ipv6-address-zoned"). > > Thanks, > Chris. > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf

Re: [netmod] [netconf] YANG Push module errors

Michal Vaško writes: > On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka > wrote: > >> Andy Bierman writes: >> >> > On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote: >> > >> >> Hi Eric, >> >> >> >> tha

Re: [netmod] [netconf] YANG Push module errors

"configured" >> feature >> > but >> > > these 2 augments are not conditional. Having this feature disabled, we >> > were not >> > > able to load this module into our tools. Does anyone disagree with >> this or >> > with >> > > submitting an errata? >

Re: [netmod] YANG questions

t might be useful to split the value into multiple items in YANG. Lada > > Thanks, > Tony > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladisla

Re: [netmod] Use of prefixes in YANG models

w.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions about how to assign default values with YANG

used to hold syslog messages." Hmm, this seems to state semantics (meaning) of a parameter. What I am talking about are semantic constraints (business rules) that a valid data tree is required to satisfy. Lada > > > William > > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka > wrot

Re: [netmod] Questions about how to assign default values with YANG

t; > love >> > > to have auto-negotiation/enabled available on all Ethernet interfaces >> > > and then >> > > you end in a debate where the application developers tell you that no >> > > information in may have many reasons (instrumentation not >

Re: [netmod] Questions about how to assign default values with YANG

On 09. 03. 21 18:55, Andy Bierman wrote: > > > On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka <mailto:ladislav.lho...@nic.cz>> wrote: > > On 09. 03. 21 17:58, Andy Bierman wrote: > > > > > > On Tue, Mar 9, 2021 at 8:46 AM Ladislav

Re: [netmod] Questions about how to assign default values with YANG

On 09. 03. 21 17:58, Andy Bierman wrote: > > > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka <mailto:ladislav.lho...@nic.cz>> wrote: > > Italo Busi mailto:italo.b...@huawei.com>> > writes: > > > Hi Juergen, > > > >

Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts

tly appears in IANA registries. Lada > > The IANA version of "deprecated" would map to (3) "really-deprecated" in > YANG, whilst the IANA definition of "obsolete" matches the YANG definition of > "obsolete". > > But this can't really be sol

Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts

incremented instead when only editorial >changes are made, and the MAJOR version would be incremented if non- >backwards-compatible major changes are made. > >Given that IANA maintained YANG modules are versioned with a linear >history, it is anticipated that it should not be necessary to use the >"_compatible" or "_non_compatible" modifiers to the "Z_COMPAT" >version element. > > Comments welcome. > > Thanks, > Rob > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

On 22. 02. 21 11:11, Juergen Schoenwaelder wrote: > On Mon, Feb 22, 2021 at 11:00:36AM +0100, Ladislav Lhotka wrote: > >> But I thought that Jürgen's question was directed to the definition of >> backward compatibility in the semver context. > > No, the background is not

Re: [netmod] type equivalence

type string { pattern "1|2|3|4"; } >> >> yields the same _XML encoded_ value space as >> >>type int32 { range "1..4"; } >> >> but as far as I recall the JSON/CBOR encodings will treat these two >> differently. So yes, ideally the YANG language would have clear rules >

Re: [netmod] Structuring a DHCP module

option definitions for "status-code-option-group” >>> (client, server, relay) and “rapid-commit-option-group, >>> vendor-specific-information-option-group; reconfigure-accept-option-group” >>> (client, server) into the common module to resolve the duplication.

Re: [netmod] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances

___ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.

Re: [netmod] reflow of YANG descriptions, and general YANG format annoyances

be authoring in it. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mai

Re: [netmod] identityref with multiple base statements (follow-up question)

would be 'a' and 'b' > - valid values for the reference-2 would be 'b' and 'c' > > Is my understanding correct? Yes, this should be pretty clear from sec. 9.10.2 of RFC 7950. Lada > > Thanks, Italo > >> -Original Message- >> From: Ladislav Lhotka [mailto

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

On 13. 08. 20 10:52, Joe Clarke (jclarke) wrote: > > >> On Aug 12, 2020, at 04:04, Ladislav Lhotka wrote: >> >> "Joe Clarke \(jclarke\)" writes: >> >>>> On Aug 11, 2020, at 10:45, Martin Björklund wrote: >>>> >>>>

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

On 12. 08. 20 11:02, Martin Björklund wrote: > "Rob Wilton (rwilton)" wrote: >> >> >>> -Original Message----- >>> From: netmod On Behalf Of Ladislav Lhotka >>> Sent: 12 August 2020 08:43 >>> To: Martin Björklund >>> C

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

ckage. But if the publisher (IETF > in this case) were to republish a module with these stripped whitespace line > endings, then that would be a different revision. I think it would be better to define "canonical YANG". One relatively straightforward way might be to convert to YI

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

Martin Björklund writes: > Hi, > > > Ladislav Lhotka wrote: >> >> >> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote: >> > At the IETF 108 virtual meeting, Lada asked about what would happen if he >> > converted a YANG module to YIN synt

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

in other arguments has to be significant and lead to a revision bump. And one more corner case for both 2 a 3: what if "\t" is replaced with the tab character in a double-quoted string? For YANG, these two strings are absolutely equivalent. Lada > > Thoughts? > > Joe > __

Re: [netmod] identityref with multiple base statements

point to Option #1 but I would like clarification on the intent. Yes, #1 is correct. Lada > > Best regards, > Joey > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: inet:host

On 30. 07. 20 15:44, Juergen Schoenwaelder wrote: > On Wed, Jul 29, 2020 at 01:55:38PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >> >>>> If we want to allow non-ASCII names, then it would IMO be safer to use a >>>> type th

Re: [netmod] rfc6991bis: inet:host

Juergen Schoenwaelder writes: > On Mon, Jul 27, 2020 at 03:18:25PM +0200, Ladislav Lhotka wrote: >> >> >> On 27. 07. 20 12:44, Juergen Schoenwaelder wrote: >> > On Mon, Jul 27, 2020 at 10:51:31AM +0200, Ladislav Lhotka wrote: >> >> Juergen Sc

Re: [netmod] rfc6991bis: inet:host

On 27. 07. 20 12:44, Juergen Schoenwaelder wrote: > On Mon, Jul 27, 2020 at 10:51:31AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >> >>> So would the following do the right thing? >> >> The invert-match pattern also needs to be added i

Re: [netmod] rfc6991bis: inet:host

ing host-name from domain-name is a good thing to do. Apart from being somewhat complicated, this coupling can also cause problems, e.g. if domain-name was to be obsoleted in the future. Lada > > /js > > On Sun, Jul 26, 2020 at 03:11:15PM +0200, Ladislav Lhotka wrote: >> Juerg

Re: [netmod] rfc6991bis: inet:host

Juergen Schoenwaelder writes: > On Wed, Jul 22, 2020 at 01:46:38PM +0200, Ladislav Lhotka wrote: >> >> >> On 22. 07. 20 13:00, Juergen Schoenwaelder wrote: >> > Tom, >> > >> > my understanding is that Lada is now proposing something slight

Re: [netmod] rfc6991bis: inet:host

;." or "_". Lada > > /js > > On Wed, Jul 22, 2020 at 09:54:00AM +, tom petch wrote: >> From: netmod on behalf of Juergen Schoenwaelder >> >> Sent: 21 July 2020 20:44 >> >> On Mon, Jul 20, 2020 at 11:04:55AM +0200, Ladislav Lho

Re: [netmod] rfc6991bis: inet:host

Juergen Schoenwaelder writes: > On Mon, Jul 20, 2020 at 11:04:55AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >> >> > - Lada suggested to replace the inet:domain-name usage in >> > the union with a new host-name definition that follo

Re: [netmod] rfc6991bis: yang:xpath1.0

> netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:percentage

> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > ___ > netmod mailing list > netmod@ietf

Re: [netmod] rfc6991bis: inet:host

g 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key

Re: [netmod] JSON to XML lossy conversion

On 17. 07. 20 14:42, Juergen Schoenwaelder wrote: > On Fri, Jul 17, 2020 at 02:12:06PM +0200, Ladislav Lhotka wrote: >> >> >> On 17. 07. 20 12:03, Vladimir Vassilev wrote: >>> On 17/07/2020 09.11, Ladislav Lhotka wrote: >>> >>>> >>&g

Re: [netmod] JSON to XML lossy conversion

On 17. 07. 20 12:03, Vladimir Vassilev wrote: > On 17/07/2020 09.11, Ladislav Lhotka wrote: > >> >> On 17. 07. 20 8:57, Michal Vaško wrote: >>> Hi Carsten, >>> you had an interesting idea to have tools that could warn about these >>> proble

Re: [netmod] JSON to XML lossy conversion

n’t know if that is a problem with the current >> set of YANG types, but any new type could of course worsen the situation. >> >> The onus is now on the author of the YANG module to make sure that the >> varying levels of ambiguity do not cause a problem. I would be interested

Re: [netmod] JSON to XML lossy conversion

/mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/ Lada > > Regards, > Michal > > [1] https://tools.ietf.org/html/rfc7951#section-6.10 > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mai

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

5358979324 or >     truncated to 3.14159265358979323 to preserve as much of the >     precision information as possible.  Note that an application >     could choose to round (down) the value of pi to 3.14 or truncate >     the value of pi to 3.14.  This specificatio

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

If you mean "counter64" in the ietf-yang-types module, then it doesn't fall apart in JSON, provided that the rules of RFC 7951 are followed. Lada > > I can't tell how many of the "backward incompatible" changes are due > to picking too restrictive types. > > /js &g

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

ace could be up to 9 billion kilometers large (or away from >> for height) and the precision is to the micrometer. For ellipsoidal >> coordinates there are 12 fractional digits for the degrees. >> >> Thanks, >> Chris. > > > >> ___ >> netmod

[netmod] error on netmod page

Hi, I just noticed that ancient draft draft-ietf-netmod-dsdl-00 suddenly re-appeared among Active Internet-Drafts on the netmod page https://datatracker.ietf.org/wg/netmod/documents/ Has the datatracker gone mad? :-) Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67

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

nt and not a > > > > > restriction, > > > > > then the motivation for this errata is at least > > > > > confusing: > > > > > > > > > > Since no one argued against this understanding, this errata changes > > > > > the text to the same form as in other restrictions applicable to > > > > > derived types. > > > > > > > > > > Simply put: Do you think it is OK to overwrite a require-instance true > > > > > with a require-instance false in a derived type? > > > > [RW] > > > > I'm not sure, but going in the other direction seems plausible. > > > > > > > > E.g. you start with a typedef that is explicitly require-instance > > > > false that is then > > > > refined by a typedef to be require-instance true. > > > > > > > > Regards, > > > > Rob > > > > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > > > > > > > > > ___ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > ___ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] CODE BEGINS ENDS for examples ?

azs LengyelSenior Specialist > > Ericsson Hungary Ltd. > > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com > > > > _______ > > netmo

Re: [netmod] Adoption of versioning design team docs

sions, but require that all clients use the same schema >> version, that is now possible >>- The draft explicitly disallows schema-selection happening mid-session >>- The solution allows the server to require clients to configure >> schema-sets before they are used

Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented

nt for such modules is IMO more effective than having it in the module description. I don't get how it could become a problem. Lada > > > Regards, Benoit > > > > Andy > > > > > > > On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka wrote: > > >

  1   2   3   4   5   6   7   8   9   10   >