[netmod] Re: YANG Versioning question - namespace version?

on is just the module name, so adding versions to namespaces would cause troubles. Lada > > Thoughts? > > Kent > > > > ___ > netmod mailing list -- netmod@ietf.org > To unsubs

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

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 r

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

error-message "Number of elements in admin-control-list 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

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

Re: [netmod] Poll on YANG Versioning NBC Approach

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

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

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] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

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

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

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

Of course, 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

gt;> >> >> "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

___ yang-doctors mailing list yang-doct...@ietf.org 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?

t;ct:ssh-public-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

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

lid, but unintended 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?

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

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

one variant for values of the crypt-hash 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

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

anks, > Jack Rickard > he/him > Software Engineer > jack.rick...@microsoft.com<mailto:jack.rick...@microsoft.com> > > [Microsoft Logo] > > > _______ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/

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

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

tion. > If you have 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. > > ___ >

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

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

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

but sometimes I get >> pushback 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 y

Re: [netmod] question about unprefixed path in leafref

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

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

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

t;>>>> >>>>>>>>> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> >>>>>>>>> >>>>>>>>> eth0 >>>>>>>>> ianaift:ethernetCsmacd >&g

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

> urn:ietf:params:xml:ns:yang:iana-if-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

olvement and additional coding and testing efforts. 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 B

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

gt; Is there any guideline/suggestion 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>

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

od@ietf.org https://www.ietf.org/mailman/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

f.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 '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 reason

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

x27;t actually needed, hence when "ancestor::node()/nw:network-types/tet:te-topology" Lada > > ? > > Grüße, Carsten > > ___ > netmod mailing list > netmod@ietf.org &g

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

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

> Chris. > > > >> >> While RFC 8791 (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

t;, so 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

"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

this case, one can simple 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 th

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

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

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

Re: [netmod] Printable or visible string in YANG

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

Re: [netmod] Printable or visible string in YANG

n.com ___ 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/ma

Re: [netmod] NULL value for uint16

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

Re: [netmod] NULL value for uint16

protocol accessing the > 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/listinf

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

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

ning for the "obvious" names > (i.e., you want zoned addresses you use "-zoned" types e.g., > "ipv6-address-zoned"). > > Thanks, > Chris. > > ___ > netmod mailing list > netmod@ie

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

tional on "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 e

Re: [netmod] YANG questions

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

Re: [netmod] Use of prefixes in YANG models

___ >> netmod mailing list >> netmod@ietf.org >> https://www.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

t of local storage that can be 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 a

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

applications that >> > > 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 rea

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] Questions about how to assign default values with YANG

s, whatever and by reporting enabled=false >> you do them a favor) but the true answer in such a debate is often that >> modeling things as a boolean is simplistic since there are often more than >> exactly two states (in this case, en

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

, this is something that also frequently 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"

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

ay be 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 i

Re: [netmod] type equivalence

d encodings. The type >> >>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

Re: [netmod] Structuring a DHCP module

could move the 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 th

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

e, Carsten > > ___ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org &g

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

t to > 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.ie

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

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

ed by a package. 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 con

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

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

Re: [netmod] identityref with multiple base statements

tyref's base identities." tends > to 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 Schoen

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

convinced that deriving 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 w

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 Lhotka

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

21 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 -- Ladislav Lhot

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 >>> problems (alth

Re: [netmod] JSON to XML lossy conversion

ersion to text that is >> not fully nailed down; I don’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

Re: [netmod] JSON to XML lossy conversion

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

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

ed (up) to 3.14159265358979324 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

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

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

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

surface 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. > > > >> ___ >> ne

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

gt; > > OK. If we consider require-instance a constraint 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

  1   2   3   4   5   6   7   8   9   10   >