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: >>>> >>>> Hi Kent, >>>> >>>> it's not exactly what you are asking for but FWIW Yangson has a method >>>> DataModel.schema_digest [1] >>>> that returns a “schema digest” - a JS object that contains all information >>>> that is necessary for such a client-side web app - data tree structure, >>>> types, restrictions and more. I used it successfully for writing a >>>> RESTCONF client app in AngularJS. >>>> >>> >>>> [1] >>>> https://yangson.labs.nic.cz/datamodel.html#yangson.datamodel.DataModel.schema_digest >>> >>> I can’t believe I didn’t know the importance of this method before. >>> - an opportunity to improve the docs? >> >> Do you have any suggestions? > > Sure. Something along these lines? > > OLD: Generate digest of the data model schema. This information is primarily > intended to aid client applications. > > NEW: Generate a digest of the data model schema. The digest is a flattened > and compressed view intended to enable processing the data model without a > full YANG processing stack, e.g., a single-page application written in > Javascript running in a web browser. OK, will use, thanks. > > > >>> You’re right that it isn’t what was asked for, but it may very well be >>> sufficient… >>> - especially given that you said your AngularJS project was successful. >> >> YANG schema info is also needed in other parts of such an app, e.g. in HTML >> templates. > > Can you say a bit more here? By “YANG schema”, do you mean the schema digest > in particular? Why would there be HTML templates if dynamically-generating > the layout? Yes, I meant the schema digest. Of course it's not necessary if you can generate the entire app from a YANG data model. My aim was to write a multi-purpose app that uses a data model (digest) as input and adjusts accordingly. Lada > > > >>>> I discussed this once with Martin Björklund and I think he mentioned that >>>> tail-f used something similar. Perhaps this could be an idea for >>>> standardizing - apart from web apps there are other restricted >>>> environments not well suited for dealing with all the complexity and >>>> modularity of YANG data models. >>> >>> I welcome opening a discussion into supporting SPAs on top of RESTCONF. >>> >>> One issue I foresee is folks thinking server-rendered UI is good enough. >>> I’d like to counter with three comments: >>> 1. Server-rendered takes more server-processing >>>- it is better to offload to client, right? >>> 2. RESTCONF is moving into the realm of applications (not network devices) >>>- several NMS/Controller systems have RESTCONF-based NBIs >>>- such apps want/need SPA UI to meet market-demand >>> 3. JS tooling to process YANG is nearly non-existent (but see [A] and [B] >>>- this sets a high-bar for every application >>>- also suggests a market-opportunity... >> >> 4. A server-side app is kinda "man in the middle", so you typically have to >> store credentials for accessing the devices on that web server. In contrast, >> a client-side app authenticates directly with the RESTCONF server. > > Indeed, that too. > > >> Lada > > K. > > -- Ladislav Lhotka PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
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 returns a “schema digest” - a JS object that contains all information >> that is necessary for such a client-side web app - data tree structure, >> types, restrictions and more. I used it successfully for writing a RESTCONF >> client app in AngularJS. >> > >> [1] >> https://yangson.labs.nic.cz/datamodel.html#yangson.datamodel.DataModel.schema_digest > > I can’t believe I didn’t know the importance of this method before. > - an opportunity to improve the docs? Do you have any suggestions? > > You’re right that it isn’t what was asked for, but it may very well be > sufficient… > - especially given that you said your AngularJS project was successful. YANG schema info is also needed in other parts of such an app, e.g. in HTML templates. > > >> I discussed this once with Martin Björklund and I think he mentioned that >> tail-f used something similar. Perhaps this could be an idea for >> standardizing - apart from web apps there are other restricted environments >> not well suited for dealing with all the complexity and modularity of YANG >> data models. > > I welcome opening a discussion into supporting SPAs on top of RESTCONF. > > One issue I foresee is folks thinking server-rendered UI is good enough. > I’d like to counter with three comments: > 1. Server-rendered takes more server-processing > - it is better to offload to client, right? > 2. RESTCONF is moving into the realm of applications (not network devices) > - several NMS/Controller systems have RESTCONF-based NBIs > - such apps want/need SPA UI to meet market-demand > 3. JS tooling to process YANG is nearly non-existent (but see [A] and [B] > - this sets a high-bar for every application > - also suggests a market-opportunity... 4. A server-side app is kinda "man in the middle", so you typically have to store credentials for accessing the devices on that web server. In contrast, a client-side app authenticates directly with the RESTCONF server. Lada > > [A] https://github.com/corenova/yang-js > [B] https://github.com/corenova/yang-swagger > > >> Happy New Year to everyone, >> >> Lada > > Cheers, > Kent > > -- Ladislav Lhotka PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG to TypeScript?
Hi Kent, it's not exactly what you are asking for but FWIW Yangson has a method DataModel.schema_digest [1] that returns a “schema digest” - a JS object that contains all information that is necessary for such a client-side web app - data tree structure, types, restrictions and more. I used it successfully for writing a RESTCONF client app in AngularJS. I discussed this once with Martin Björklund and I think he mentioned that tail-f used something similar. Perhaps this could be an idea for standardizing - apart from web apps there are other restricted environments not well suited for dealing with all the complexity and modularity of YANG data models. Happy New Year to everyone, Lada [1] https://yangson.labs.nic.cz/datamodel.html#yangson.datamodel.DataModel.schema_digest Kent Watsen writes: > In the “here’s something different” category… > > I’m interested in creating an SPA (single page application) on top of a > RESTCONF server. > > Popular SPA frameworks include AngularJS, Ember.js, ExtJS, Knockout.js, > Meteor.js, React, Vue.js, and Svelte. TypeScript is a used by these > frameworks to “type” the data (since JavaScript is natively untyped). In > this case, the data is defined in YANG, so it seems that tooling could create > a hierarchy of TypeScript types. But searching didn’t find any such thing... > > I’m sure folks are creating SPAs on top of RESTCONF. Can anyone share a > toolchain that works? > > 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IEEE Std 802.1Qcw invalidates trivial YANG data tree
Hi Florian,
Florian Kauer writes:
> Hi,
> I know this is bad timing since Qcw was just published, but - at least with
> libyang - the following YANG data tree that specifies nothing Qcw related is
> no longer valid when just loading the Qcw YANG models:
>
> interface.json:
> {
> "ietf-interfaces:interfaces": {
> "interface": [
> {
> "if-index": 1,
> "name": "eth0",
> "type": "iana-if-type:ethernetCsmacd",
> "oper-status": "down",
> "admin-status": "down",
> "statistics": {
> "discontinuity-time": "2023-12-15T10:04:12.345+00:00"
> }
> }
> ]
> }
> }
>
> yanglint interface.json ieee802-dot1q-sched.yang
> ieee802-dot1q-sched-bridge.yang ieee802-types.yang ieee802-dot1q-types.yang
> ieee802-dot1q-bridge.yang iana-if-t...@2023-01-26.yang
> ietf-interfa...@2018-02-20.yang
>
> results into
>
> libyang err : Number of elements in admin-control-list must not be
> greaterthan supported-list-max (Data location
> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin-control-list".)
> libyang err : Number of elements in oper-control-list must not be greaterthan
> supported-list-max (Data location
> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-control-list".)
> libyang err : admin-cycle-time must not be greater than supported-cycle-max
> (Data location
> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin-cycle-time".)
> libyang err : oper-cycle-time must not be greater than supported-cycle-max
> (Data location
> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-cycle-time".)
> YANGLINT[E]: Failed to parse input data file "interface.json".
>
> My first expectation was a bug in libyang, but Michal is convinced that
> libyang's behavior is correct in this regard:
> https://github.com/CESNET/libyang/issues/2140
>
> I have not enough experience in YANG to properly argue if either the YANG
> model or libyang needs to be changed, but I don't think we want to force
> every interface to specify a
> /ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/supported-list-max
> etc. just because the Qcw YANG models are loaded.
>
> I hope I have just a misunderstanding and I am looking forward to your
> responses!
I am afraid I don't have good news. Apparently, the problem is in this "must"
statement:
must
"(count(./gate-control-entry) <= ../supported-list-max)" {
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
Martin Björklund writes: > Hi, > > There has been some discussion with IANA on the YANG doctors list > regarding this text in section 4.8 in RFC 8407: > >A "revision" statement MUST be present for each published version of >the module. The "revision" statement MUST have a "reference" >substatement. It MUST identify the published document that contains >the module. > > (the same text is present in rfc8407bis) I think it would be sufficient to have SHOULD instead of MUST here. Other cases apart from IANA modules may arise where it makes no sense to attach reference to every single revision. And adding dummy references just to satisfy tools is actually harmful. On the other hand, I assume YANG doctors would object if a reference isn't provided where it is appropriate and no sound reason is given. Lada > > It continues with the motivation behind the rule: > >Modules are often extracted from their original >documents, and it is useful for developers and operators to know how >to find the original source document in a consistent manner. > > As can be seen in e.g., > https://www.iana.org/assignments/yang-parameters/iana-dns-class-rr-t...@2023-11-08.yang, > this rule has not been followed. > > The discussion ended with the recommendation to IANA to always add a > "reference" statement that refers to the published module (e.g., > https://www.iana.org/assignments/yang-parameters/iana-dns-class-rr-t...@2023-11-08.yang). > > If people agree that this is the correct solution, I think we should > update 8407bis with this. > > Specifically, I suggest to change 4.30.3.1 and 4.30.3.2: > > OLD: > > When the "iana-foo" YANG module is updated, a new "revision" > statement with a unique revision date must be added in front of the > existing revision statements. > > NEW: > > When the "iana-foo" YANG module is updated, a new "revision" > statement with a unique revision date must be added in front of the > existing revision statements. The "revision" statement must have a > "reference" substatement that to the published module (e.g., > https://www.iana.org/assignments/yang-parameters/iana-...@2023-11-08.yang) > > > > > Further, some IANA modules use the IETF template for the module's > "description", see e.g., > https://www.iana.org/assignments/yang-parameters/iana-routing-ty...@2022-08-19.yang. > That module has in its "description": > > This 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 for full legal notices."; > > I think 8407bis should recommend that IANA-maintained modules use this > wording instead. > > > > /martin > > ___ > 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
at were previously not allowed, valid. This is no different to prescribing a mandatory-to-implement YANG extension. File versioning is baked into YANG, a peculiarity of the language. There are many more such peculiarities. I'd like to know what other backward incompatible changes to the spec I can expect to occur in the future because there's now a precedent for it. Jernej Best Regards, /jan On 12 Sep 2023, at 07:55, Jürgen Schönwälder wrote: I disagree with the poll. There are important teachnigal differences behind the two options that this polls tries to hide. Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG 1.1'. There is no way that a new versioning approach will be understood by existing YANG tooling. That's an illusion. /js On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote: WG, Please help the YANG-versioning effort move forward by participating in the following poll: - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login required) Kent and Lou ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ 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, 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
Dne 12. 09. 23 v 14:43 Jan Lindblad (jlindbla) napsal(a): Jürgen, all, I see the irony in changing the YANG RFC(s) without updating the YANG language version number, but digging a bit deeper, I think the question is not as clear-cut as it might seem at first. Altering the contents of the backwards-compatibility section of RFC 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' behavior. Speaking as a YANG compiler implementor, however, I don't see any changes that have to made to the compiler because of this RFC change. There are no new keywords, none are removed. There is no change in the meaning of existing keywords. There is no difference in the output the compiler needs to generate. So while there are changes to the YANG *standard* (meaning RFCs) there is no actual change to the YANG *language*. If we require user's to mark their modules with version 1.2 (or 2.0), from the compiler's pov, that would just be an alias for YANG 1.1. It means a fair amount of trouble to update all the tools out there to accept "yang-version 1.2" but do nothing new. It also adds a burden to YANG module implementors, since they would have to go through all YANG 1.1 modules and mark them 1.2, for no change in meaning. For organizations with some modules still on YANG 1.0, the bar is even higher. I think the most pragmatic approach in this case would be to change the RFC text in the backwards-compatibility sections and not update the yang-version number as long as no change is required in the compilers. If anyone can point to actual things the compiler needs to do differently, I'd be interested to hear. I agree with this. I have actually always thought that the section "Updating a Module" should never have become part of the YANG language definition. A sensible approach could IMO be to move this section to 8407bis, and relax the requirements to SHOULD there. Lada Best Regards, /jan On 12 Sep 2023, at 07:55, Jürgen Schönwälder wrote: I disagree with the poll. There are important teachnigal differences behind the two options that this polls tries to hide. Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG 1.1'. There is no way that a new versioning approach will be understood by existing YANG tooling. That's an illusion. /js On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote: WG, Please help the YANG-versioning effort move forward by participating in the following poll: - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login required) Kent and Lou ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ 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] Joint WGLC on "semver" and "module-versioning" drafts
Dne 13. 06. 23 v 17:07 Robert Varga napsal(a): On 05/06/2023 11.46, Martin Björklund wrote: - introduce new instance-identifier data type based on RFC 7951 definition - introduce new identityref data type based on RFC 7951 definition ... but I do agree with these! I am not sure I follow... is this about providing instance-identifier/identityref encoding which does not rely on XML namespaces, or something else? Yes, it's about using module name as the namespace identifier (prefix). Lada Thanks, Robert ___ 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] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt
Hi Med, thanks for letting me know, it's nice to see that my somewhat crazy method still finds some uses. Cheers, Lada Dne 15. 03. 23 v 10:52 mohamed.boucad...@orange.com napsal(a): Hi Lada, FWIW, we exercised the use of the script when preparing https://datatracker.ietf.org/doc/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 mars 2022 15:04 À : BOUCADAIR Mohamed INNOV/NET ; netmod@ietf.org Objet : RE: [netmod] TR: New Version Notification for draft- boucadair-netmod-iana-registries-00.txt writes: ... As a proof of concept, I prepared XSLT stylesheets for a dozen or so registries [1]. Although it works quite well, I do admit that it would be a drudgery to cover the full scope of existing IANA registries. Lada [1] https://github.com/llhotka/iana-yang [Med] Will add a pointer to this repo. Thanks. Thanks, Lada _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. 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. -- 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
Kent Watsen writes: >>> This was discussed in late 2021. I switched from: >>> >>> base64encodedvalue== >>> >>> to: >>> >>> BASE64VALUE= >>> >>> in all my drafts then. Which document are you looking at? >> >> RFC 8366 (from 2018). > > That document was published before the issue was discovered. File an Errata > for it? > > >> Do you have a pointer to the discussion? > > Not at hand. Was it this thread? https://mailarchive.ietf.org/arch/msg/netconf/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 is OK to be liberal in what we accept here because
"base64encodedvaluQ==" is clearly the canonical value in this case, so there is
no ambiguity e.g. regarding string equality.
Well, this is the essence of my question (not sure about the part about string
equality, though).
draft-iab-protocol-maintenance [0] takes the position that the Postel
principle, while historically a good way to implement protocols and get
interoperability going, is not to be misunderstood as a mandate for the
evolution of protocol ecosystems — protocols are free to be strict, lest they
turn into soup (“Protocol Decay” [1]: “...a chain reaction that can create
interoperability problems over time”).
Section 9.1 in RFC 7950: "values in the data tree are conceptually
stored in the canonical representation", and also "XPath expression
evaluations are done using the canonical form". If implementations obey
these rules, and since the canonical form for the binary type is
unambiguous, I don't see much potential for interoperability problems.
In essence, it's like representing number 17 as +17.
I’d like to know whether, on issues like this, YANG is more on the strict side
or on the soup side — what do YANG implementations actually do, and what do we
want YANG implementations to do? Is there an implicit “MAY send invalid last
character”, which is no different from a “MUST accept invalid last character”?
Unlike non-alphabet characters, RFC 4648 doesn't say that such a
character in encoded data is invalid.
FWIW, my implementation (Yangson) uses Python standard library base64
that accepts it without complaints even with validation turned on:
>>> import base64
>>> base64.b64decode("ue==", validate=True)
b'\xb9'
So I assume the authors consider this input valid, and I saw no reason
to be concerned about it.
Lada
Background: I’m proposing to add a few control operators to CDDL, including for
handling base64classic [2], and in my PoC implementation was of course
implementing a strict interpretation, only to be struck by the first example in
an RFC I was pointed to.
Grüße, Carsten
[0]:
https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
[1]:
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-12.html#name-harmful-consequences-of-tol
--
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
Carsten Bormann writes:
> Quick question (can’t find in the archives whether that was discussed):
>
> 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. I think though it is OK to be liberal in what we accept here because
"base64encodedvaluQ==" is clearly the canonical value in this case, so there is
no ambiguity e.g. regarding string equality.
Lada
>
> Section 6.6 of RFC 7951 points to Section 9.8 of RFC 7950, which points to
> Section 4 of RFC 4648. That says:
>
>When fewer than 24 input
>bits are available in an input group, bits with value zero are added
>(on the right) to form an integral number of 6-bit groups.
>
> I read that as saying the `binary` should be encoded as:
>
> "base64encodedvaluQ==“
>
> (Q = 01, e = 00, only the first two bits are used after “u” has
> supplied six of eight for the last byte, so the rest must be zero.)
>
> Grüße, Carsten
>
> ...
>
> For those who don’t breathe base64, here’s the problem:
>
> a = Base64.decode64("base64encodedvalue==").hexs
> => "6d ab 1e eb 87 a7 72 87 5e 76 f6 a5 b9”
>
> But some bits were *not* zero in the discarded part, so we get:
>
> Base64.encode64(a.xeh) => "base64encodedvaluQ==\n”
>
> 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
Dne 11. 01. 23 v 4:16 Fengchong (frank) napsal(a): Hi all, In RFC 7950 section 6.4.1: o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping, that namespace is affected by where the grouping is used (see Section 7.13 <https://www.rfc-editor.org/rfc/rfc7950#section-7.13>). Inside a typedef, that namespace is affected by where the typedef is referenced. If a typedef is defined and referenced within a grouping, the namespace is affected by where the grouping is used (see Section 7.13 <https://www.rfc-editor.org/rfc/rfc7950#section-7.13>). and section 5.4: Grouping, type, and identity names are resolved in the context in which they are defined, rather than the context in which they are used. Users of groupings, typedefs, and identities are not required to import modules or include submodules to satisfy all references made by the original definition. This behaves like static scoping in a conventional programming language. I think these two section have some conflicts. If groupings and typedefs are resolved in the context where they are defined, why names without prefix belongs to the namespace where they are used? I don't think there is any conflict. The quoted text from 5.4 can actually be expanded as "Grouping names, type names and identity names are resolved ..." I may be missing something because I also don't see the XPath expression part that you have in the subject. Lada The authors who defined the groupings and typedefs don’t know where these definitions are used, they only know the place where these definitions are defined. ___ 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;> >> >> >> >> >> >> YANG Catalog search shows 1486 modules import the ip-address typedef. >> >> I suspect the number is about twice that. >> >> >> >> So we want to tell the world: >> >> >> >> "You have to stop using ip-address and use this new type instead". >> >> >> >> "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
Dne 05. 10. 22 v 12:01 tom petch napsal(a): From: netmod on behalf of Jeffrey Haas Sent: 03 October 2022 20:41 [I had promised Mahesh that I'd take my comments here, but I realize that this is a topic that likely will result in no short term solutions. It may also result in no action whatsoever.] YANG strings are bounded in length, theoretically, but that length limit isn't small. When strings are used solely as leaf values, the length limit largely isn't a matter of concern, in my opinion. However, when they're used as keys, it introduces some code practicalities that may be worth discussing. One item of practicality is simply the length and its impact on underlying data structures. If you were storing such things in something like a PATRICIA tree, many implementations behave better when the key is of a bounded length.* A secondary consideration is that since unicode is used, character lengths in terms of storage may vary. Implementations that internally store strings as UTF-8 have to be wary of truncation considerations. A tertiary consideration is that in mechanisms like gNMI, long keys end up bloating PDUs. Loosely framing this as a very old English joke: YANG Doctor, it hurts when I do this! YANG Doctor: Well... don't do that! For many things that have naturally short string names (e.g. interface names), this mostly isn't an issue. However, for things that may take user-supplied strings as their key in configuration, this is somewhat more problematic.* Most implementations likely don't take unbounded inputs to the maximum length of a YANG string for such things. Technically in such situations, they're non-conformant if that's the case, or if they don't provide a deviation specifying the length of the string. Why raise this? While I only coincidentally participate in YANG module implementation at the moment, I remember similar headaches in MIBs making the lives of implementors problematic. What should be done, if anything? It seems like those with deeper expertise may want to recommend a reasonable length limit for strings that will be used as keys. Perhaps define a specific typedef for such things. And, once defined, the YANG doctors might consider recommending them in their reviews. Such things may already be good practice, but perhaps I'm not aware of it. I am forever pointing out to authors of modules just how big a string can be and the usual reaction is that they do not care. Occasionally the response is to ask what it should be. Dunno, that is your decision. I seem to recall carrying across the SMI type with a restricted length into YANG but was unable to convince others. I would still be against setting a hard limit in YANG itself, primarily because it is not clear what this general limit should be. Module authors might of course consider restricting key length to something that is appropriate for a particular key leaf. Lada Tom Petch -- Jeff * As a matter of fact, it was performing a code review against exactly this point that raised this consideration. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ 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
Hi,
in this case the default value is a property of the type that is being
replaced, so the default is no more effective.
Lada
Dne 04. 10. 22 v 10:34 Kristian Sallberg (krisallb) napsal(a):
Hello,
I have a question regarding the default value of "/repro:cont/repro:a",
after deviations have been applied. Since the default value is defined
in "typedef type_a", and we then replace the type of
"/repro:cont/repro:a", should the default value of this leaf be removed?
I have not been able to find the answer in the YANG RFCs.
module repro {
yang-version 1.1;
namespace "rep:ro";
prefix repro;
typedef type_a {
type enumeration {
enum up {
value 1;
}
enum down {
value 2;
}
enum testing {
value 3;
}
}
default "down";
}
typedef type_b {
type enumeration {
enum up {
value 1;
}
enum down {
value 2;
}
enum testing {
value 3;
}
}
}
container cont {
presence "blablablbala";
leaf a {
type type_a;
}
leaf b {
type type_b;
default "down";
}
}
deviation "/repro:cont/repro:a" {
deviate replace {
type enumeration {
enum up {
value 1;
}
enum down {
value 2;
}
}
}
}
deviation "/repro:cont/repro:b" {
deviate replace {
type enumeration {
enum up {
value 1;
}
enum down {
value 2;
}
}
}
}
}
Best regards, Kristian Sällberg
___
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] Must expression: how to test all instances?
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 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 "ts:public-key" is a list, currently the expression evals true if there is just one
element in the list having public-key-format="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.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] [Technical Errata Reported] RFC7951 (7020)
Hi, this erratum should be verified. Lada (author of the RFC) Dne 11. 07. 22 v 11:13 RFC Errata System napsal(a): The following errata report has been submitted for RFC7951, "JSON Encoding of Data Modeled with YANG". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7020 -- Type: Technical Reported by: Jernej Tuljak Section: 6.8 Original Text - An "identityref" value is represented as a string -- the name of an identity. If the identity is defined in a module other than the leaf node containing the identityref value, the namespace-qualified form (Section 4) MUST be used. Otherwise, both the simple and namespace- qualified forms are permitted. Corrected Text -- An "identityref" value is represented as a string -- the name of an identity. If the identity is defined in a module other than the leaf or leaf-list node containing the identityref value, the namespace-qualified form (Section 4) MUST be used. Otherwise, both the simple and namespace- qualified forms are permitted. Notes - The original text omitted leaf-list nodes, which may also be of "identityref" type. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7951 (draft-ietf-netmod-yang-json-10) -- Title : JSON Encoding of Data Modeled with YANG Publication Date: August 2016 Author(s) : 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] JSON encoding of "leaf-list" nodes of type identityref
Hi Jernej, this is a clear omission, can you please file an erratum? Thanks, Lada Dne 11. 07. 22 v 10:57 Jernej Tuljak napsal(a): Hi, RFC7951, Section 6.8, says this [1]: An "identityref" value is represented as a string -- the name of an identity. If the identity is defined in a module other than the leaf node containing the identityref value, the namespace-qualified form (Section 4) MUST be used. Otherwise, both the simple and namespace- qualified forms are permitted. This text fails to mention leaf-list nodes. It should probably say: An "identityref" value is represented as a string -- the name of an identity. If the identity is defined in a module other than the leaf or leaf-list node containing the identityref value, the namespace-qualified form (Section 4) MUST be used. Otherwise, both the simple and 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: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Unintended when-expression semantics in many IETF YANG modules
"Jan Lindblad \(jlindbla\)" writes:
> Hi NETMOD,
>
> A few days ago, as I was looking for examples of when-expressions in standard
> modules, I stumbled over this in RFC 8944:
>
> augment "/nw:networks/nw:network" {
>when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
> description
>"Augmentation parameters apply only for networks
> with L2 topology.";
>}
>description
> "Configuration parameters for the L2 network
> as a whole.";
>uses l2-topology-attributes;
> }
>
> ... and a few other similar constructs in there.
>
> As you can see the when expression is unconstrained when it comes to which
> network it refers to, which changes the semantics from "Augmentation
> parameters apply only for networks with L2 topology" as the authors are
> wishing for to "Augmentation parameters apply to all networks as soon as
> there is at least one with L2 topology".
>
> Aside from RFC 8944, I also noticed very similar problems in RFC 9094, RFC
> 8542, RFC 8294, RFC 8513 and RFC 8782. The list may be incomplete.
Yes, I remember flagging this issue in at least one of my YD reviews. I think
this also led to the myth that YANG Doctors prefer relative paths to absolute.
:-)
>
> What do we do with the broken YANGs modules in these RFCs?
A bis is needed in each case, errata unfortunately won't work.
>
> Since this seems to be a rather frequently occurring issue, are there any
> mitigation steps we should take in NETMOD, apart from strengthening the YANG
> Doctor review process?
Hardly anything. It is IMO too late to part with XPath 1.0. On the one hand, it
is a complicated beast, unnecessarily for YANG purposes. On the other hand,
many YANG module authors don't bother to learn even the basics.
>
> What can we reasonably do to ensure all YANG Doctor reviews catch these
> valid, 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
>
> ___
> 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] Does defining a feature require the module be implemented?
Kent Watsen writes: > 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? No, I am talking about RFC 7950, which defines the concept of implemented module. If imported features are ever to be restricted only to implemented modules, then it requires a new YANG version and cannot be done via an erratum. Tools may - and indeed do - use different methods for specifying the overall data model, including 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. > > > -- 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] Does defining a feature require the module be implemented?
Kent Watsen writes: > 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 "document only" errata on RFC 7950. >> 3) put a "document only" errata on RFC 8407. >> 4) file a YANG Next issue. >> 5) some combination of the above. >> 6) anything else? >> >> >> I do not think an Errata can fix this issue because the split >> between 'module' and 'import-only-module' was intentional. > > My intention for using the "hold for document update" Errata (I > wrote "document only" before) is only to better document the > behavior that exists currently, so it doesn't have to be But the alternative behaviour exists as well. I don't think this can be fixed by an erratum. Lada > rediscovered again later. Martin pointed to an RFC section that > didn't list features explicitly, leaving it open for interpretation. > Patching such sections would be good. As for RFC 8407, maybe > Section 4.17 (Feature Definitions) could say something? > > Following are a couple excerpts from > https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata: > > Hold for Document Update - The erratum is not a necessary update to the RFC. > However, any future update of the document might consider this erratum, and > determine whether it is correct and merits including in the update. > > And (I added the underline): > > Changes which are simply stylistic issues or simply make things read better > should be Hold for Document Update. > > Would you be willing to offer some text for an RFC 8407 "hold for document > update" errata? If Martin does the same for the section he found, I think > we would be covered. It seems is worthy effort, yes? > > Kent // contributor > > >> >> Going back to iana-crypt-hash (again). >> >> - the features are not intended for use in any if-feature-stmts >> - each feature is related to 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 some proposed edits for yang-next. >> >> >> >> Kent >> >> Andy >> > > ___ > 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] RFC 7951 - JSON encoding of empty lists
Hi,
Jack Rickard writes:
> Hi,
>
> I think I've found an ambiguity in RFC 7951, and I'd like your input on what
> was intended and what the best behaviour to exhibit is.
>
> Section 5.3 and 5.4 of RFC 7951 - JSON Encoding of Data Modeled with YANG
> (ietf.org)<https://datatracker.ietf.org/doc/html/rfc7951#section-5.3>
> describe the encoding of leaf-lists and lists, however it's unclear how an
> empty list should be encoded. Should it be encoded as:
>
> 1. An empty array: {"list": []}
> 2. A missing field: {}
Both variants are equivalent and should be supported by tools and libraries.
I can understand though that tools supporting both XML and JSON representations
tend to prefer #2 because #1 doesn't exist in XML.
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.
Lada
>
> I've seen libraries go either way, libyang only accepts 2 but the python
> yangson library accepts both (I'm not sure which is the default).
>
> Thanks,
> 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/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] 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 ; >> netmod@ietf.org >> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair- >> netmod-iana-registries-00.txt >> >> Hi Med, >> >> here are my comments: >> >> YANG modules should be as tightly coupled as possible to the >> corresponding IANA registries. In an ideal world, YANG would simply have >> a statement for using a registry directly. This is, however, not >> possible in the current state of affairs. >> >> In particular, a separate module mirroring an IANA registry is almost >> always needed. >> >> Identities versus typedefs/enumerations: I think the text in sec. 4.11.1 >> of RFC 8407 applies to IANA registries as well. I would only add that >> identities are preferable if *distributed* extensibility is needed, i.e. >> if different parties are expected to define public and long-living >> entries on their own. > > [Med] The current text in 8407 seems to just reason about fixed > values AND single maintainers. What I'm hearing from both you and > Jurgen is that this is not an update. I won't make a fixation on > that and will proceed with updating the text to reflect the > interpretation you shared. Thank you. > >> >> Identities could also be extremely useful if the registry entries are >> organized hierarchically, possibly including multiple inheritance. > > [Med] Do you think we should include some text in the draft to call > out this aspect? Possibly, this is something that enumerations cannot model. > >> >> One caveat regarding identities: for reasons that are unclear to me, >> YANG requires identity names (unlike enums) to be identifiers. That's >> why it is not possible to use identities without workarounds e.g. for >> Media Types, where it would IMO make a lot of sense. >> >> Last paragraph in sec. 3: >> >>"Designers of IANA-maintained modules MAY supply the full Initial >>version of the module in a specification document that registers the >>module or only a script to be used by IANA for generating the module >>(e.g., an XSLT 1.0 stylesheet in Appendix A of [RFC9108])." >> >> The first option turned out to be no-go in the DNSOP WG during the >> preparation of RFC 9108. The main objection was that, despite all >> warnings, implementors would blindly use the initial revision published >> in an RFC even after some entries become deprecated and might be >> potentially dangerous. It was thus proposed to e.g. keep the initial >> module revision only in the I-D stage and ask RFC Editor to delete it >> before publishing it as an RFC. Eventually, the XSLT stylesheet as a >> template for the initial module revision was acceptable to everyone and >> worked very well with IANA, too. >> > > [Med] Thanks for the feedback. The proposed guideline is to let the designers > be aware of both approaches, decide based on their specific context, and then > include a justification for their choice. Yes, I suspect that different WGs may have different opinions on this. > >> Another advantage of the XSLT-based solution is that it allows for >> generating an always up-to-date revision of the YANG module from the >> online XML representation of the IANA registry. > > [Med] Agree. I will add a note about this. > > As a proof of concept, I >> prepared XSLT stylesheets for a dozen or so registries [1]. Although it >> works quite well, I do admit that it would be a drudgery to cover the >> full scope of existing IANA registries. >> >> Lada >> >> [1] https://github.com/llhotka/iana-yang >> > > [Med] Will add a pointer to this repo. Thanks. Thanks, Lada > >> writes: >> >> > Hi all, >> > >> > We had in alto wg a discussion about consistent use of IANA-maintained >> modules. This document provides some guidelines that I hope will ensure >> some consistency about how we are interacting with IANA registries. The >> goal is avoid transforming YANG modules (if not maintained by IANA) as >> another source of information, which are likely to be out of sync. >> > >> > Some more details/context are provided in the I-D. >> > >> > Comments and suggestions are appreciated. >> > >> > Cheers, >> > Med >> > >> > -Message d'origine-
Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt
messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > 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. > > ___ > 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
Andy Bierman writes:
> On Mon, Feb 14, 2022 at 1:19 AM Jan Lindblad (jlindbla)
> wrote:
>
>> Just to add to the complexity here, it's not only about identityrefs.
>>
>> People (including IETF) have also defined types that use qname:s inside
>> YANG strings, which the servers and clients would have to recognize and
>> treat properly in order to interoperate well.
>>
>> module ietf-yang-types {
>> ...
>> typedef xpath1.0 {
>> type string;
>> description
>> "This type represents an XPATH 1.0 expression.
>>
>> When a schema node is defined that uses this type, the
>> description of the schema node MUST specify the XPath
>> context in which the XPath expression is evaluated.";
>> reference
>> "XPATH: XML Path Language (XPath) Version 1.0";
>> }
>>
>>
>
> Good point. Not just a server implementation detail I guess.
> We had a YANG extension for this before this xpath type came out.
> https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-xpath
>
> The server implementation definitely needs to know (early in the
> processing) which strings are plain strings
> and which are XPath expressions. Usually it is too late to get the
> namespace bindings
> after the XML parser is finished.
>
> Maybe a solution for YANG 2.0...
> Create a standard algorithm to convert QName and xpath:1.0 strings to a
> canonical format,
> using the module-name approach defined in RFC 7951.
This is not so easy, as long as a canonical value must also stay lexically
valid in a given representation. The only reasonable (but backwards
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 comparisons involving strings with XML prefixes are not reliable.
> (Maybe a whole new can of worms there...)
>
>
>
>> /jan
>>
>>
> Andy
>
>
>> On 14 Feb 2022, at 10:05, Ladislav Lhotka wrote:
>>
>> Andy Bierman writes:
>>
>> On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>> I agree that this should not go forward as is.
>>
>> The XML representation of YANG instance data does indeed use QNames in
>> element values and hence applications must be able to resolve XML
>> namespace prefixes. If this is not clear enough in RFC 7950, then we
>> need to address the lack of clarity where it belongs to be addressed.
>>
>> If we were to add a warning to all (past and) future YANG modules to
>> help implementors who did not read RFC 7950, then the warning should
>> be concise ("Applications using the XML representation of YANG
>> instance data must be able to resolve XML namespace prefixes."). My
>> preference, though, is to assume that implementors read RFC 7950 when
>> they are not sure how to implement the prefixes correctly.
>>
>>
>> It seems clear that this is not an issue specific to a particular YANG
>> module,
>> so the fix needs to be an errata against RFC 7950.
>> The text in question is probably limited to the first paragraph (first
>> sentence).
>>
>> 9.10.3 <https://datatracker.ietf.org/doc/html/rfc7950#section-9.10.3>.
>> Lexical Representation
>>
>> An identityref is lexically represented as the referred identity's
>> qualified name as defined in [XML-NAMES
>> <https://datatracker.ietf.org/doc/html/rfc7950#ref-XML-NAMES>]. If
>> the prefix is not
>> present, the namespace of the identityref is the default namespace
>> in effect on the element that contains the identityref value.
>>
>>
>>
>> The problem is that XML-NAMES only applies to elements and attributes (not
>> string node content).
>>
>>
>> I looked into XSLT 2.0, sec. 5.1 [1], hoping that we could use it as a
>> model, but it became clear to me that we have a bigger problem: equality of
>> identityref values isn't properly defined in YANG. We resolved this in YANG
>> 1.1 for identityrefs appearing in XPath expressions by adding the functions
>> "derived-from" and "derived-from-or-self", but the problem still persists
>> e.g. when comparing identityref values serving as list keys (sec. 9.1 in
>> RFC 7950 doesn't help here).
>>
>> Lada
>>
>> [1] https://www.w3.org/TR/xslt20/#qname
>>
>>
>> I d
Re: [netmod] Use XML namespaces in YANG document examples
ant of 2022, these late stage non-WG interventions should not
>> be over-riding the WG discussions but that is not going to change any time
>> soon).
>> >
>> > Tom Petch
>> >
>> > From: netmod on behalf of tom petch <
>> ie...@btconnect.com>
>> > Sent: 11 February 2022 17:03
>> >
>> > From: Carsten Bormann
>> > Sent: 11 February 2022 08:21
>> > >> (I’m also still not sure I’ve got an answer to my question about
>> using inconsistent prefixes between YANG and the XML example. What is
>> being demonstrated here?)
>> > >>
>> > >
>> > > If you are referring to
>> > > " Is there a reason to violate the SHOULD?"
>> >
>> > I’m referring to the question I was trying to ask when I said this :-)
>> >
>> > > I did not see that as related to the thread but thought it was
>> answered anyway by Juergen. As he said, the SHOULD gets violated when
>> prefix clash which, in the absence of a registry, a namespace, for prefix
>> is possible.
>> >
>> > Yes, and thanks to him for answering my question as a general question.
>> >
>> > I was answering to a throwaway note that the authors got flak when their
>> XML did not use the defined prefix. My question was: why do that, then?
>> Maybe that was not understood because “ianaift” actually *is* the prefix
>> preferred in the YANG module, so my question doesn’t make sense. (I’m not
>> sure what the throwaway referred to.)
>> >
>> >
>> >
>> > Try again.
>> >
>> > I have commented a number of times on a YANG import which defines a
>> prefix other than that in the RFC. Last month, it was
>> > import ietf-hardware {
>> >prefix ietfhw;
>> > Usually, when I comment on this, the authors accept my comment and
>> change the prefix - they did on this occasion - 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 yes, I have - and will - generate flack:-)
>> >
>> > Tom Petch
>> >
>> >
>> > Grüße, Carsten
>> >
>> >
>> > ___
>> > 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
>>
>> --
>> Jürgen Schönwälder 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
--
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] question about unprefixed path in leafref
"Sterne, Jason (Nokia - CA/Ottawa)" writes:
> Hi all,
>
> This immediately made me worried about all such xxx-ref constructs in YANG
> that I've seen in a few modules.
>
> But looking at IETF interfaces https://datatracker.ietf.org/doc/html/rfc8343
> I see that this error is avoided because interface-ref is fully qualified
> right ?
>
RFC 8407, sec 4.2:
o The local module prefix SHOULD be used instead of no prefix in all
path expressions.
This is particularly important for typedefs that are intended to be used in
other modules.
Lada
> typedef interface-ref {
>type leafref {
> path "/if:interfaces/if:interface/if:name";
>}
>description
> "This type is used by data models that need to reference
> interfaces.";
> }
>
> Jason
>
> From: netmod On Behalf Of Jernej Tuljak
> Sent: Wednesday, February 9, 2022 3:47 AM
> To: Fengchong (frank) ;
> netmod@ietf.org
> Subject: Re: [netmod] question about unprefixed path in leafref
>
>
> On 08/02/2022 03:40, Fengchong (frank) wrote:
> Hi all,
>
> In RFC7950 sec6.4.1 says:
>
>
> o Names without a namespace prefix belong to the same namespace as
>
> the identifier of the current node. Inside a grouping, that
>
> namespace is affected by where the grouping is used (see
>
> Section
> 7.13<https://datatracker.ietf.org/doc/html/rfc7950#section-7.13>). Inside a
> typedef, that namespace is affected by
>
> where the typedef is referenced. If a typedef is defined and
>
> referenced within a grouping, the namespace is affected by where
>
> the grouping is used (see Section
> 7.13<https://datatracker.ietf.org/doc/html/rfc7950#section-7.13>).
>
> But in module openconfig-aft-network-instance:
>
> augment "/oc-ni:network-instances/oc-ni:network-instance/" +
> "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state" {
>
> description
> "Add leaves that require referencing of a network instance to the
> operational state parameters of a next-hop within the AFT for IPv4
> unicast.";
>
> uses aft-nexthop-ni-state;
> }
>
> grouping aft-nexthop-ni-state {
> description
> "Operational state parameters relating to a next-hop which reference a
> network instance.";
>
> leaf network-instance {
> type oc-ni:network-instance-ref;
> description
> "The network-instance within which the next-hop should be resolved.
> When this leaf is unspecified, the next-hop is resolved within
> the local instance.";
> }
> }
>
> The typedef network-instance-ref is defined in module
> openconfig-network-instance:
>
> typedef network-instance-ref {
> type leafref {
> path "/network-instances/network-instance/config/name";
> }
> description
> "A re-usable type that can be referenced within other
>modules that references a network instance.";
> }
>
> The leafref’s path is a unprefixed path.
>
> So, according RFC7950, the typedef network-instance-ref is referenced in leaf
> network-instance, and the leaf is inside grouping aft-nexthop-ni-state, and
> this grouping is used in augment
> "/oc-ni:network-instances/oc-ni:network-instance/" +
> "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state"
> So the path "/network-instances/network-instance/config/name" ‘s namespace is
> module openconfig-aft-network-instance’s namespace. But in fact, there is no
> node called network-instances with namespace:
> http://openconfig.net/yang/aft/ni.
>
> Is it incorrect?
>
> I try to use pyang to compile it, and no error is reported.
>
> These modules are written in YANG 1.0, therefore RFC6020 applies, not
> RFC7950. This was one of the cases where RFC6020 was unclear, hence new text
> you quote from RFC7950. If you change openconfig-network-instance to YANG
> 1.1, pyang should report an error for that "path" when the "typedef" gets
> used in openconfig-aft-network-instance.
>
> Jernej
>
>
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose 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 oth
Re: [netmod] Use XML namespaces in YANG document examples
Hi Ian,
ianfar...@gmx.com writes:
> Hi,
>
> A draft I have been working on
> (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/) contains a
> number of XML configuration examples. During the XML expert review, a
> question has been raised about the use of XML namespaces in these examples.
> I’m raising it here as I don’t have the XML knowledge to answer.
>
> In my example:
>
> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
>
>eth0
>ianaift:ethernetCsmacd
>DHCPv6 Relay Interface
>true
>
>
> The question is related to the use of the ‘ianaift:’ prefix. This is quite
> commonly use in XML examples in YANG documents (e.g. RFC8344) so I think the
> question is generally applicable.
>
> The specific comments from the expert review are:
>
> -
> For the correct processing of these documents requires that whatever XML
> software is being used makes available to application code the namespace
> prefixes.
>
> Whilst the recommended tools (e.g. yanglint) provides this function, it is
> not an XML best practice. Quoting from the Namespaces in XML, section 4:
> "Note that the prefix functions only as a placeholder for a namespace name.
> Applications SHOULD use the namespace name, not the prefix, in constructing
> names whose scope extends beyond the containing document.”
The present situation is IMO different: the prefix doesn't leak out of the
containing document, it is only used for something else than XML element and
attribute names. The "ianaift" prefix can be replaced by something else, and it
should be transparent to the outside world. So I don't think this SHOULD is
relevant in this case.
Lada
>
> I think that violating a SHOULD assertion in a W3C standard is a problem.
>
> There is no requirement for XML processors to provide this prefix
> information, and software that (quite legally) doesn't, will not work
> correctly with YANG documents constructed as specified in this I-D.
>
> 1, YANG specifications should note this fact and specify that software which
> is used to process YANG documents MUST provide an interface such that
> applications can retrieve the prefix-namespace mappings.
> 2, For constructs such as ianaift:ethernetCsmacd the
> Internet-Draft should specify that the prefix ("ianaift" in this case) MUST
> be identical to the xmlns namespace prefix representing the namespace name
> 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
--
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;>>>>> $ yanglint --strict --verbose -t config -p $IETFYANG
>>>>>>> $IETFYANG/iana-if-type.yang $IETFYANG/ietf-interfaces.yang test1.xml
>>>>>>> err : Invalid value "ianaift:ethernetCsmacd" in "type" element.
>>>>>>> (/ietf-interfaces:interfaces/interface[name='eth0']/type)
>>>>>>> ]
>>>>>>>
>>>>>>>
>>>>>>> Follow-up, would the following work, foo for both namespace and
>>>> content
>>>>>>> prefix?
>>>>>>>
>>>>>>> >>>>>> xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
>>>>>>>
>>>>>>> eth0
>>>>>>> foo:ethernetCsmacd
>>>>>>> DHCPv6 Relay Interface
>>>>>>> true
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>>
>>>>>>>
>>>>>>> [if - This does validate with yanglint, however the convention in the
>>>>>>> IETF examples I’ve seen seems to be to use the prefix that is defined
>>>> in
>>>>>>> the original YANG module for imports for consistency, e.g. (from
>>>>>>> iana-if-type.yang):
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman
>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think the text from sec 4 refers to the usage within an
>>>> application.
>>>>>>>> The XML instance document is the on-the-wire representation and
>>>>>>>> the I-D example looks correct.
>>>>>>>>
>>>>>>>> https://www.w3.org/TR/xml-names/#ns-qualnames
>>>>>>>>
>>>>>>>>
>>>>>>>> Andy
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 3, 2022 at 3:53 AM tom petch
>>>> wrote:
>>>>>>>>> From: netmod on behalf of
>>>> ianfar...@gmx.com <
>>>>>>>>> ianfar...@gmx.com>
>>>>>>>>> Sent: 03 February 2022 09:37
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> A draft I have been working on (
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/)
>>>> contains
>>>>>>>>> a number of XML configuration examples. During the XML expert
>>>> review, a
>>>>>>>>> question has been raised about the use of XML namespaces in these
>>>> examples.
>>>>>>>>> I’m raising it here as I don’t have the XML knowledge to answer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ian
>>>>>>>>>
>>>>>>>>> This looks like the issue I raised on this list 14jan2022 with a
>>>>>>>>> subject line of
>>>>>>>>> XML and prefix
>>>>>>>>> although I have not checked that the usage is exactly the same; the
>>>>>>>>> 'XML Expert' comment would appear to be.
>>>>>>>>>
>>>>>>>>> Tom Petch
>>>>>>>>>
>>>>>>>>> In my example:
>>>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>>>> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
>>>>>>>>>
>>>>>>>>> eth0
>>>>>>>>> ianaift:ethernetCsmacd
>>>>>>>>> DHCPv6 Relay Interface
>>>>>>>>> true
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The question is related to the use of the ‘ianaift:’ prefix. This is
>>>>>>>>> quite commonly use in XML examples in YANG documents (e.g. RFC8344)
>>>> so I
>>>>>>>>> think the question is generally applicable.
>>>>>>>>>
>>>>>>>>> The specific comments from the expert review are:
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> For the correct processing of these documents requires that whatever
>>>>>>>>> XML software is being used makes available to application code the
>>>>>>>>> namespace prefixes.
>>>>>>>>>
>>>>>>>>> Whilst the recommended tools (e.g. yanglint) provides this
>>>> function, it
>>>>>>>>> is not an XML best practice. Quoting from the Namespaces in XML,
>>>> section 4:
>>>>>>>>> "Note that the prefix functions only as a placeholder for a
>>>> namespace name.
>>>>>>>>> Applications SHOULD use the namespace name, not the prefix, in
>>>> constructing
>>>>>>>>> names whose scope extends beyond the containing document.”
>>>>>>>>>
>>>>>>>>> I think that violating a SHOULD assertion in a W3C standard is a
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> There is no requirement for XML processors to provide this prefix
>>>>>>>>> information, and software that (quite legally) doesn't, will not
>>>> work
>>>>>>>>> correctly with YANG documents constructed as specified in this I-D.
>>>>>>>>>
>>>>>>>>> 1, YANG specifications should note this fact and specify that
>>>> software
>>>>>>>>> which is used to process YANG documents MUST provide an interface
>>>> such that
>>>>>>>>> applications can retrieve the prefix-namespace mappings.
>>>>>>>>> 2, For constructs such as ianaift:ethernetCsmacd the
>>>>>>>>> Internet-Draft should specify that the prefix ("ianaift" in this
>>>> case) MUST
>>>>>>>>> be identical to the xmlns namespace prefix representing the
>>>> namespace name
>>>>>>>>> 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
>
> ___
> 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
beyond the containing document.”
>>>
>>> I think that violating a SHOULD assertion in a W3C standard is a problem.
>>>
>>> There is no requirement for XML processors to provide this prefix
>>> information, and software that (quite legally) doesn't, will not work
>>> correctly with YANG documents constructed as specified in this I-D.
>>>
>>> 1, YANG specifications should note this fact and specify that software
>>> which is used to process YANG documents MUST provide an interface such that
>>> applications can retrieve the prefix-namespace mappings.
>>> 2, For constructs such as ianaift:ethernetCsmacd the
>>> Internet-Draft should specify that the prefix ("ianaift" in this case) MUST
>>> be identical to the xmlns namespace prefix representing the namespace name
>>> 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
On 02. 02. 22 11:15, Jan Lindblad wrote: Lada, While I agree that tools are easier to update than WG documents, and that a broken yanglint isn't a strong reason to avoid the proposed axis construct, I do think it will have a cost. In current YANG practice, XML axis constructs are esoteric, and many implementations will either not support it, or have not been tested properly in this area before. Many engineers will never have seen this before, and might stumble. Bottom line, this is valid YANG, and it is supposed to work. For many people it will definitely be less readable than a relative path. I expect choosing the axis solution will slow the uptake of this module. I disagree. Tools should faithfully implement the standard, and especially those that are used as "authoritative" in RFC validation process. I don't see how axes could be considered esoteric - in fact, they are very fundamental in XPath and things like '..' or '//' are just syntactic sugar for axes contructs. I'm not going to argue with you when it comes to XPath in general. Axes are (a fundamental) part of it. I'm just speaking of current YANG practice. Out of the 45k YANG modules in the IETF YANG repo on Github (which includes standard, experimental and many vendor modules), I did not find any using axes today. I think that observation makes it reasonable to call them esoteric in YANG context. This is a slippery slope. It's quite likely that none of existing modules has ever used other XPath features, such as some built-in functions. Does it mean that implementations may ignore them and fail upon encountering such features. Who is going to decide what is esoteric and what not? RFC 8470 lists some XPath features that should not be used for good reasons (including some axes), but the rest should IMO be OK to use. I have seen axes used in the real world YANG modules a handful of times. Each time it led to real world problems. They could be worked around and resolved, but it required YANG expert involvement 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 Best Regards, /jan -- 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
Jan Lindblad writes:
> Italo,
>
> While I agree that tools are easier to update than WG documents, and that a
> broken yanglint isn't a strong reason to avoid the proposed axis construct, I
> do think it will have a cost. In current YANG practice, XML axis constructs
> are esoteric, and many implementations will either not support it, or have
> not been tested properly in this area before. Many engineers will never have
> seen this before, and might stumble.
>
> Bottom line, this is valid YANG, and it is supposed to work. For many people
> it will definitely be less readable than a relative path. I expect choosing
> the axis solution will slow the uptake of this module.
I disagree. Tools should faithfully implement the standard, and especially
those that are used as "authoritative" in RFC validation process. I don't see
how axes could be considered esoteric - in fact, they are very fundamental in
XPath and things like '..' or '//' are just syntactic sugar for axes contructs.
Lada
>
> Best Regards,
> /Jan
>
>
>> On 28 Jan 2022, at 12:12, Italo Busi
>> wrote:
>>
>> Thanks Michal for the clarification
>>
>> We have discussed this issue among the co-authors of
>> draft-ietf-ccamp-flexigrid-yang and we are not sure about how to address a
>> WG LC comment we have received on this topic
>>
>> While the YANG code using the ancestor instead of relative paths looks
>> easier to read and understand to an human code writer/reader, we are
>> concerned about whether it is worthwhile standardizing in IETF a YANG data
>> model which fails compilation with yanglint
>>
>> The YANG code is correct (at least it passes pyang validation) but it fails
>> yanglint validation just because yanglint does not support axes, so we
>> expect that as soon as we upload the updated draft, the IETF datatracker
>> will signal yang validation errors
>>
>> 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>]
>>> Sent: martedì 18 gennaio 2022 08:07
>>> To: Italo Busi mailto:italo.b...@huawei.com>>
>>> Cc: Ladislav Lhotka >> <mailto:ladislav.lho...@nic.cz>>; Martin Björklund
>>> mailto:mbj+i...@4668.se>>; netmod@ietf.org
>>> <mailto:netmod@ietf.org>
>>> Subject: Re: [netmod] YANG 'when' with absolute path
>>>
>>> Hi,
>>>
>>> yanglint uses its own XPath implementation, which unfortunately does not
>>> support axes, hence the error.
>>>
>>> Regards,
>>> Michal
>>>
>>> On Monday, January 17, 2022 16:59 CET, Italo Busi
>>> wrote:
>>>
>>>> Lada, Martin,
>>>>
>>>> Thanks for your suggestion and thanks Tom for having raised this issue
>>>> to Netmod WG
>>>>
>>>> We have tried to follow your suggestion and replaced the relative paths
>>>> with:
>>>> when "ancestor::nw:network/nw:network-types/tet:te-topology"
>>>>
>>>> You can find the updated YANG module on github:
>>>>
>>>> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-flexigrid-yang/tree/
>>>> wg-lc-resolution
>>>>
>>>> However, we have found some issues when compiling the new code with
>>> yanglint. This is the error that we have got from the on-line YANG
>>> validator:
>>>>
>>>> libyang err : Invalid character 'a'[1] of expression
>>> 'ancestor::nw:network/nw:network-types/tet:te-topology/flexgt:flexi-grid-
>>> topology'. (/ietf-flexi-grid-
>>> topology:{augment='/nw:networks/nw:network/nt:link/tet:te/tet:te-link-
>>> attributes/tet:underlay/tet:primary-path/tet:path-
>>> element/tet:type/tet:label/tet:label-hop/tet:te-label/tet:technology'})
>>>> YANGLINT[E]: Processing schema module from
>>> /var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-tNQJZOjI/ietf-flexi-
>>> grid-topology.yang failed.
>>>>
>>>> Is this an issue with yanglint or with the updated code?
>>>>
>>>> Pyang compilation does not return any error/warning
>>>>
>>>> Thanks in advance
>>>>
>>>> Aihua, Sergio and Italo
>>>>
>>>>> -Original Message-
>>>>> From: Ladislav Lhotka [mailto:ladislav.lho...@n
Re: [netmod] [yang-doctors] YANG 'when' with absolute path
On 02. 02. 22 1:00, Robert Varga wrote: On 28/01/2022 12:12, Italo Busi wrote: The YANG code is correct (at least it passes pyang validation) but it fails yanglint validation just because yanglint does not support axes, so we expect that as soon as we upload the updated draft, the IETF datatracker will signal yang validation errors Is there any guideline/suggestion from Netmod WG and YANG doctors on how to deal with such a case? I do not believe a deficiency in one tool should hold back publication. Tools are updated more easily than SDO documents after all and one would hope 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: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] XML and prefix
On 14. 01. 22 12:23, Martin Björklund wrote: Hi, Ok, I think I understand what he means. With this XML: nsfmi:memory-alarm the prefix "nsfmi" is present in the element data, which means that in order to implement this properly, the XML parser must pass the namespace mappings to the user code. So he proposes to add to the draft: (from https://mailarchive.ietf.org/arch/msg/i2nsf/06kJ7vS6X-0hUmGHrCWN-jVzU7M) 11. XML Examples for I2NSF NSF Monitoring This section shows the XML examples of I2NSF NSF Monitoring data delivered via Monitoring Interface from an NSF. In order for the XML to work, the prefix in the element that uses "identityref" type (e.g., /i2nsf-event/i2nsf-system-detection-alarm/alarm-category/) in the YANG module described in this document MUST be the same as the namespace prefix for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf- monitoring. The XML software MUST be chosen that makes the namespace prefix information available. I think this is a bit odd. Who is supposed to act on the first MUST? This text is about an example, which is what it is, and it happens to be correct. Also, the text about XML software seems unnecessary to me. It follows from the definition of an identityref in RFC 7950 that the namespace mapping is needed to parse this correctly. This is not unique to YANG. For example, XSLT and RELAX NG use XML prefixes in the values of XML attributes. Lada /martin Ladislav Lhotka wrote: On 14. 01. 22 11:39, Martin Björklund wrote: Hi, I don't understand the problem either. He writes: Sorry, but this has the same problem in figure 11.1 that we've just been discussing with Ian. Can you send a pointer to that discussion? Perhaps there's more context there. Right. I also suspect that the last sentence should have been "I don't think it's OK for the draft to say those things." Lada /martin tom petch wrote: I see that IANA have taken to asking XML Registry experts about the registration of YANG namespaces at Last Call, or perhaps they have always done this but have only recently put the e-mail on a public list. Anyhow, the experts have taken it upon themselves to comment on the XML examples and I do not understand this comment. This comes from [IANA #1217705] Expert Review for draft-ietf-i2nsf-nsf-monitoring-data-model-12 (xml-registry) by Tim Bray 17 dec 2021 03:03 === Sorry, but this has the same problem in figure 11.1 that we've just been discussing with Ian. For it to work, (a) the prefix in the alarm-category element MUST be the same as the namespace prefix for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring, which means that XML software MUST be chosen that makes the namespace prefix information available. I don't think it's OK for the draft not to say those thigns. nsfmi:memory-alarm = a) I am unclear what the problem is - I thought that XML allowed great freedom with prefix even if the IETF would rather not b) this suggestion seems to be that all I-D with XML examples, which is pretty much every I-D with a YANG module in it, needs to carry a warning about what XML software to choose, which seems rather a burden. Thoughts? Tom Petch ___ 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 -- 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
On 14. 01. 22 11:39, Martin Björklund wrote: Hi, I don't understand the problem either. He writes: Sorry, but this has the same problem in figure 11.1 that we've just been discussing with Ian. Can you send a pointer to that discussion? Perhaps there's more context there. Right. I also suspect that the last sentence should have been "I don't think it's OK for the draft to say those things." Lada /martin tom petch wrote: I see that IANA have taken to asking XML Registry experts about the registration of YANG namespaces at Last Call, or perhaps they have always done this but have only recently put the e-mail on a public list. Anyhow, the experts have taken it upon themselves to comment on the XML examples and I do not understand this comment. This comes from [IANA #1217705] Expert Review for draft-ietf-i2nsf-nsf-monitoring-data-model-12 (xml-registry) by Tim Bray 17 dec 2021 03:03 === Sorry, but this has the same problem in figure 11.1 that we've just been discussing with Ian. For it to work, (a) the prefix in the alarm-category element MUST be the same as the namespace prefix for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring, which means that XML software MUST be chosen that makes the namespace prefix information available. I don't think it's OK for the draft not to say those thigns. nsfmi:memory-alarm = a) I am unclear what the problem is - I thought that XML allowed great freedom with prefix even if the IETF would rather not b) this suggestion seems to be that all I-D with XML examples, which is pretty much every I-D with a YANG module in it, needs to carry a warning about what XML software to choose, which seems rather a burden. Thoughts? Tom Petch ___ 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 '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 this is not phrased as when "./ancestor::nw:network-types/tet:te-topology/“ Yes, this would work, with a minor correction: when "./ancestor::node()/nw:network-types/tet:te-topology" because 'nw:network-types' isn't an ancestor of the context node. Also, the initial './' isn't actually needed, hence when "ancestor::node()/nw:network-types/tet:te-topology" Or the more direct: when "ancestor::nw:network/nw:network-types/tet:te-topology" Right, this is the best option. This style works if we can guarantee that there will be exactly one node "nw:network" among our ancestors. It is perhaps easier to get this style right w/o a YANG compiler (which would detect if the number of ".." in the relative path is wrong), but the relative path might be easier to understand for a casual reader. +1 Lada /martin Lada ? Grüße, Carsten ___ 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 -- 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 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:
>>
>> when "../../../../../../nw:network-types/tet:te-topology/“
>
> I’m probably showing my ignorance about YANG again, but what is
the reason this is not phrased as
>
> when "./ancestor::nw:network-types/tet:te-topology/“
Yes, this would work, with a minor correction:
when "./ancestor::node()/nw:network-types/tet:te-topology"
This is not equivalent to the original expression.
It is not equivalent but will work fine in this case because there is
only one ancestor having a 'nw:network-types' child. Unlike the absolute
path, one is confined to the same 'nw:network' entry here.
It means slightly more work for an XPath processor but is IMO
considerably more readable and less error-prone.
Lada
The ".." location step stands for parent::node().
The node match has to occur at a specific ancestor level.
But "ancestor::node()" will match any ancestor node.
Andy
because 'nw:network-types' isn't an ancestor of the context node.
Also, the initial './' isn't actually needed, hence
when "ancestor::node()/nw:network-types/tet:te-topology"
Lada
>
> ?
>
> Grüße, Carsten
>
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<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 'when' with absolute path
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 > this is not phrased as > > when "./ancestor::nw:network-types/tet:te-topology/“ Yes, this would work, with a minor correction: when "./ancestor::node()/nw:network-types/tet:te-topology" because 'nw:network-types' isn't an ancestor of the context node. Also, the initial './' isn't actually needed, hence when "ancestor::node()/nw:network-types/tet:te-topology" Lada > > ? > > Grüße, Carsten > > ___ > 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] 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 > argument simply doesn’t hold water. As was mentioned, you would > check »”foo” in o«, which works for null, false, and all other > values that may happen to be falsy(*) in the platform. The whole story is that Phil wanted to have both empty and boolean values as JSON strings. The result was a compromise, and I thought that [null] was a much better choice because, unlike "null" string, it cannot otherwise appear as a valid value of a YANG leaf. > >>JSON evolved from Javascript, so it must keep the javascript >>meanings for these keywords. > > That is a common misconception that must be stamped out, but we have > j...@ietf.org for that discussion. It's not that I am defending these views. I did argue with RFC 4627, but not too hard, as this seemed like a marginal issue at that time - much more fundamental objections against the JSON representation were raised back then. > >> It is indeed true that tests in JavaScript cannot really distinguish between >> a non-existent member and member with the value of 'null'. I remember I >> wasn't happy about this change but I thought it wasn't a big deal. > > As mentioned, they can. > And, yes, this little unnecessary complexity is not a big deal even if it is > based on mistaken beliefs; every non-trivial protocol has some unburied > zombies in the basement. Right, in hindsight it was a mistake. It is also worth noting that [null] is only an on-the-wire value, so e.g. None can be used internally in Python. I have written a lot of related running code and don't find it a serious problem. Lada > > Grüße, Carsten > > (*) falsy: converted to false when implicitly coerced to a Boolean (Ant.: > truthy) > -- 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] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]
Christian Hopps writes: >> On Dec 18, 2021, at 7:59 AM, Carsten Bormann wrote: >> >> On 2021-12-18, at 09:20, Eliot Lear wrote: >>> >>> Still it seems like the right thing to do, in order to fall into line with >>> the target language spec. >> >> But that’s not what YANG was designed for. >> YANG is a data modeling language, which incidentally has a couple of >> representation formats (YANG-XML, YANG-JSON, YANG-CBOR). >> There is no intention for the YANG generic data model (the set of all data >> models YANG can express) to cover the generic data model of the >> representation format. > > To be clear, the question I raised is about an encoding of YANG modeled data. > In particular the JSON encoding of the YANG empty leaf element. > > https://datatracker.ietf.org/doc/html/rfc7951#section-6.9 > > the justification for having the very odd encoding was that there was some > belief that some programming languages might have trouble with the obvious > JSON "null" encoding (which stands for "no value" in JSON -- exactly what we > want here). An old email gave a python example to try and illustrate this, > except the python example was an incorrect use of python for this case > (presence check) and not a problem with the natural JSON encoding for no > value items. In fact correctly written python code has no problem at all with > the more natural "null" encoding, and results in the correct internal > representation in python to boot. > > This isn't about the YANG specification in general, or making YANG > conform to any particular language. It's just about the a choice in > the specification for the encoding of YANG in a particular format > (JSON). The original proposal (even before my individual draft appeared in the NETMOD WG) was actually just "null". We'd been discussing it back in March 2012 in a smaller group (Andy, Jürgen, Martin, Phil Shafer and myself), and Phil objected to this encoding of empty values. His arguments were, for example: 'foo: null'? Doesn't that make testing for empty values a major pain? 'if (foo)' would not work. JSON evolved from Javascript, so it must keep the javascript meanings for these keywords. It is indeed true that tests in JavaScript cannot really distinguish between a non-existent member and member with the value of 'null'. I remember I wasn't happy about this change but I thought it wasn't a big deal. Lada > > Thanks, > 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
>> > > > > > > node
>> > > > > > > "c", which belongs to the module "mod_a" (added by an augment)
>> > > > > > > but
>> > > > > > > the
>> > > > > > > current module would then be "mod_b".
>> > > > > > > > To summarize, if strictly following the specs, the "unique" in
>> > > > > > > > the
>> > > > > > > "mylist" should probably reference "value" with a prefix, but
>> > > > > > > that
>> > > > > > > is>
>> > > > > > > not possible because "mod_a" is not even imported and it
>> > > > > > > generally
>> > > > > > > does not make sense. But then I cannot think of any consistent
>> > > > > > > rule
>> > > > > > > to
>> > > > > > > successfully resolve both "unique" statements in this example.
>> > > > > > > Can
>> > > > > > > anyone help me with this, please?
>> > > > > > > > Compare with this:
>> > > > > > > > grouping mylist_wrapper {
>> > > > > > list mylist {
>> > > > > > key "name";
>> > > > > > unique "value";
>> > > > > > must "value > 42";
>> > > > > > leaf name {
>> > > > > > type string;
>> > > > > > }
>> > > > > > leaf value {
>> > > > > > type uint32;
>> > > > > > }
>> > > > > > }
>> > > > > > }
>> > > > > > > > I think the rules for the prefixes in "unique" should be the
>> > > > > > > > same
>> > > > > > > > as
>> > > > > > for "must". So I think that the correct syntax is to not use any
>> > > > > > prefix in "unique".
>> > > > > > > > And the deviation that adds a unique statement look correct.
>> > > > > > Thanks for the reply but I do not think you have answered my
>> > > > > question. Please formulate a formal rule how to assign modules to
>> > > > > non-prefixed identifiers, whether they be in "unique", "must", or
>> > > > > any>
>> > > > > other statement with identifiers. That is what I need to implement
>> > > > > it>
>> > > > > properly and I am simply not able to come up with any that would be
>> > > > > consistent and compliant with the specification.
>> > > > > > > Interpret the unique argument the same way as an XPath
>> > > > > > > expression, and
>> > > > apply (from 6.4.1):
>> > > > > > >o Names without a namespace prefix belong to the same
>> > > > > > > namespace as
>> > > > the identifier of the current node. Inside a grouping, that
>> > > > namespace is affected by where the grouping is used
>> > > > > > > So "value" in the unique statement will refer to "value" in
>> > > > > > > "mod_a"
>> > > > when the grouping is used in "mod_a".
>> > > > > I see. Okay, this should be possible to implement, thanks.
>> > > I was too hasty with the reply, this is not working because of the
>> > "unique" in the deviation I have in the example. What is the "current>
>> > node" in that case? I suppose that can only be "mylist2", so the
>> > namespace will be that of "mod_b". But this is wrong, the "c" node
>> > belongs to "mod_a", 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
o 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] too long lines from IANA module inclusion
Kent Watsen writes: >> 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? >> >> If I put \ into the original .yang file, then it won't process. >> So if RFC8792 is the solution, then I think that I probably prefer to have >> ::include do it. Otherwise, I have to add another step to the workflow. >> >> I'd also want assurance that the YANG module extractor knows about 8792. >> Maybe given that Kent is a leader author on that... it's already taken care >> of. > > `pyang` and I think `yanglint` also know how to extract folded and > elements. > > That said, I have never needed to fold a YANG module in an I-D. As Juergen > mentioned, YANG’s built-in mechanisms have always enabled me to fit within > 69-columns. Indeed. In 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 that it will barf ;) > > K. > > > ___ > 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] RFC7950 s.11 and 9127-bis
tom petch writes:
> The BFD WG are revising RFC9127 to add a new feature if-feature
> "client-base-cfg-parms"; and make uses base-cfg-parms { conditional
> thereon in module ietf-bfd-types. Reading and re-reading RFC7950,
> especially about mandatory and top-level, I am not convinced that
> this is legal.
Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping is
mandatory. Why do you think this might be illegal?
Lada
> The module bfd-types is imported by a number of other modules such
> as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be
> made mandatory by its usage in another module. I raised this on the
> BFD list and the WG Chair tells me that this is a violation of the
> intent of the RFC, 7950, but that it has been reviewed by YANG
> doctors and is probably the best fix.
>
> If YANG Doctors collectively say that this violation is ok, then I think that
> such a statement needs to appear on the Netmod WG list.
>
> I think that there are a lot of other editorial changes needed to 9127-bis to
> make it legal but they can 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 and automatically expire in 12 months (relinquishing the code point) unless refreshed by the requester -- see https://www.rfc-editor.org/rfc/rfc7120#section-3.3 for details. I see. So if the temporarily allocated code point disappears from the registry, it won't be present in the YANG module either, if it is generated later. If YANG was able to read the registry directly, it would be the same. Cheers, Lada Regards, Robert ___ 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
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, Well, my old head doesn't serve me that well anymore, I was just looking into the registry web page and XML. > — written code that translates the information you could extract from the XML > form of the registry into a YANG data model (note that this data model is not > defining the registry, but it is the translated content of the registry) Right, and IANA needn't be involved at all. > > This is certainly highly useful. > It also requires to essentially start from scratch for each new registry. Registry schemas are quite diverse, so a universal translation procedure isn't possible. Also, some decisions may be necessary on the YANG side - for example, whether the registry records are to be represented as enums or identities. In most cases, writing a registry-specific translation isn't difficult and amounts to copying Makefile and XSLT stylesheet templates, editing parameters in the Makefile and writing a few XSLT lines. > Shouldn’t registries come with a machine readable information model? Actually, RELAX NG schemas are available, for example https://www.iana.org/assignments/dns-parameters/dns-parameters.rng They are useful for clarifying what to expect in the registry but don't help much with automating the translation. > Shouldn’t it then be “easy” to build a generic tool that creates a YANG model > out of the data in the registry? Ideally, YANG might be able to directly "import" registries, but this is quite difficult to achieve because registries are not very uniform. Thanks, Lada > > 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] 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 in > this GitHub project: > > https://github.com/llhotka/iana-yang > > So far I have processed 22 registries - most of them are related to DNS, but > I also tried to include a few from other areas. After cloning the project, > all YANG modules can be generated by running "make" in the top-level > directory. > > Adding a new registry is usually quite simple, although some hide nasty > surprises such as duplicate entries. Also, in most cases it is quite clear > how to do the translation, but sometimes input from domain experts might be > needed. > > I can see two immediate advantages of this approach: > > * There is a single source of truth - the registry itself; IANA needn't > maintain the YANG module separately. > > * The initial revision of a 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. > > > An IANA registry can contain any number of columns meaning an infinite > variety of things - TLS comes to mind. A YANG module is more limited. > Having both in an RFC shows how to map the registry into YANG. Such a module isn't meant as a replacement of the registry, developers will most likely need to consult both. Contents of extra columns may either appear in the description (as in iana-dnssec-algorithms), or may be omitted (as in iana-structured-syntax-suffix). And yes, as I wrote domain experts' input may be needed, perhaps in the form of an RFC. However, it is not ideal to include a complete YANG module (initial revision) based on a random snapshot of the registry in such an RFC. In DNSOP WG this turned out to be a no-go, and after discussing a few alternatives we came up with an XSLT stylesheet as kind of a recipe from which IANA made the initial revision. I understand that XSLT isn't everyone's favourite language, but I don't know about a better choice for this purpose. Perhaps the RFC could just explain the rules for the translation in the text (with examples). > > 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? Lada > > Tom Petch > > Thanks, Lada > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > 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
[netmod] IANA registries
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 in this GitHub project: https://github.com/llhotka/iana-yang So far I have processed 22 registries - most of them are related to DNS, but I also tried to include a few from other areas. After cloning the project, all YANG modules can be generated by running "make" in the top-level directory. Adding a new registry is usually quite simple, although some hide nasty surprises such as duplicate entries. Also, in most cases it is quite clear how to do the translation, but sometimes input from domain experts might be needed. I can see two immediate advantages of this approach: * There is a single source of truth - the registry itself; IANA needn't maintain the YANG module separately. * The initial revision of a 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.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Printable or visible string in YANG
On 19. 10. 21 9:06, Jan Lindblad wrote:
Hi Balazs,
And don't forget that in YANG 1.1 you can exclude characters.
type string {
pattern ".*\n.*" { modifier invert-match; } // Disallow newline characters
pattern ".*\r.*" { modifier invert-match; } // Disallow carriage return
characters
}
It is also worth noting that in fact (sec. 9.4 in RFC 7950) "The string
built-in type represents human-readable strings in YANG." This may
possibly be what Balazs wants, although I doubt that there is an
implementation that can really *print* all such strings.
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 12:11, Balázs Lengyel wrote:
Hello,
Is there a way in YANG to restrict a string to printable or visible characters?
(Something like SNMP DisplayString)
Regards Balazs
--
Balazs LengyelSenior Specialist
Ericsson Hungary Ltd.
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.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/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] Printable or visible string in YANG
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, Balázs Lengyel wrote: Hello, Is there a way in YANG to restrict a string to printable or visible characters? (Something like SNMP DisplayString) Regards Balazs -- Balazs Lengyel Senior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.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/mailman/listinfo/netmod
Re: [netmod] NULL value for uint16
Andy Bierman writes: > On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn < > randy_pres...@alumni.stanford.edu> wrote: > >> Hi - >> >> On 2021-09-10 9:42 AM, Andy Bierman wrote: >> > Hi, >> > >> > Maybe the use of [null] in RFC 7951 is confusing people >> > https://datatracker.ietf.org/doc/html/rfc7951#section-6.9 >> > <https://datatracker.ietf.org/doc/html/rfc7951#section-6.9> >> >> Are you suggesting that the type of this leaf should be a >> choice of unit16 and empty? At least that wouldn't >> have the ambiguity under access control Jürgen described. >> >> > > No, but the access control issue applies everywhere so it is usually ignored > and assumed that the client can view all the server data. The client could > be > blocked from viewing the empty, so this choice does not help. > > I was just guessing at the source of the confusion that YANG has a null > value. This shouldn't be too confusing, as that "null" in JSON encoding is also wrapped in an array. This was done exactly 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.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] NULL value for uint16
On 10. 09. 21 13:56, tom petch wrote: > Does NULL have any meaning for a leaf of type uint16? > > Looking at a leaf of type uint16 the description says that > 'This metric will be NULL (no value) ..' Without the context, I'd guess it means that the value isn't set and has no default. As you wrote, YANG has no NULL. Lada > > Some languages differentiate a 'never been set' state from e.g set to zero > or some other value but for me, YANG does not have that concept. Rather the > leaf does not exist which will be reflected by the 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/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 managed YANG modules
Michael Richardson writes: > In revising RFC8366, I am using RFC7224 as a model. > In order to explain this model to others, I find myself coming up short in > documentation for process. > I found nothing in RFC6020. Exactly what information are you missing? Lada > > I found: > https://www.rfc-editor.org/rfc/rfc6087.html#section-3.5 > > suggestive, but not specific about creating an IANA managed YANG module. > > Can someone point me at some specific text/explanation? > Maybe there is a PHB version? Maybe just an email from the dawn of YANG-time. > > -- > 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] looking for practical advice on managing YANG source in XML format RFCs
Hi Michael, you can check my project YANG-I-D [1] for some ideas. The most elegant way of including YANG modules in RFCs would be to treat the RFC source as a compound XML document combining xml2rfc with YANG modules in the YIN syntax - if only xml2rfc could process it. Lada [1] https://github.com/llhotka/YANG-I-D Michael Richardson writes: > Hi, I'm not a regular netmod reader. > I subscribe via IMAP to look into what's going on. If I'm asking a FAQ, I > appologize as I didn't find anything in the 25K messages archived. > I saw Christian's message in 2019 about org-rfc-export. > I'm not sure if I should Reply-To: tools or netmod. > > I'm looking for advice on how to manage things. > A summary of my questions: > > 1) how to process yang files with -DD-MM into XML. > 2) how to generate yang tree files. > 3) how do I get my YANG includes downloaded, and do I put them into my repo? > 4) how to do this with MT Makefiles? > > When we were working on RFC8995 and RFC8366, in the days before Martin > Thompson's makefile was around, I just put pyang processing into my simple > Makefile. It's here: > https://github.com/anima-wg/anima-bootstrap/blob/master/Makefile > > The perl script at: > https://github.com/anima-wg/anima-bootstrap/blob/master/insert-figures > was then developed to insert stuff into the XML. It's rather hacky in some > ways. > It started it's life as just something to find the latest @-MM-DD yang > file which the Makefile created. (Kent wrote that sed line three quarters of > a decade ago, and the sed line now is old enough to trick-or-treat) > Over time, it grew the ability to insert other bits of code or diagrams. > I keep using it, even when I've moved to Markdown because it inserts the > right artwork stuff, and knows to deal with YANG stuff. I also keep using my > Makefile, because except for the simplest uses, the MT ones are too > complicated for me to hack. > > With kramdown source, I can mostly just add stuff to the MT Makefile to > generate the files I need, and then mostly (without insert-figures), I can > use the ::include mechanism in kramdown to get the right things. But, no > magic -MM-DD stuff. > > So now I am collaborating with some co-authors which want to stick to XMLv3 > rather than kramdown, and whose understanding of Makefiles is poor. I want > to stick with the normal stuff so that all the github/etc. tooling works for > everyone involved. > > I'm looking for advice on how do this this? > > -- > 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
On 09. 05. 21 1:26, Christian Hopps wrote: > > How did we end up with "ipv4-address" being a zoned IPv4 address and > having to use the non-obvious "ipv4-address-no-zone" type to get the > IPv4 address type used by everyone, everywhere? It was discussed e.g. in these threads: * https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1=subject%3A%22draft-schoenw-netmod-rfc6021-bis-01%20(20130204)%22 * https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1=gcMx6c-NFt2UCbtBFi7BsUWf0EU Lada > > I see that OpenConfig chose the opposite meaning 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@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] [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,
>> >>
>> >> thanks for the answer.
>> >>
>> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
>> >>
>> >> wrote:
>> >>
>> >> > Hi Michal,
>> >> >
>> >> > This sounds like a tooling issue to me. I would expect that any
>> >> > augments
>> >> > would inherit the conditional nature of anything augmented.
>> >>
>> >> Perhaps, but there is nothing in the specification to hint this. On the
>> >> contrary, leafrefs, for example, explicitly require to be conditional on
>> >> the same set of if-features than their targets. But you are right, there
>> >> is
>> >> no such requirements for augments. Still, if the feature is disabled and
>> >> the augment should be applied, since its target does not technically exist
>> >> in the schema, it cannot be found. That is the error our tools currently
>> >> produce.
>> >>
>> >>
>> > Maybe this is not clear enough in RFC 7950.
>> >
>> > This seems valid:
>> >
>> > container foo {
>> >if-feature X;
>> > leaf bar { type string; }
>> > }
>> >
>> > augment /foo {
>> > container Y;
>> > }
>> >
>> > The YANG syntax validation should be done as if all features are enabled.
>> > It is a tooling issue if this is rejected. This is clear because the
>> > augment-stmt argument specifies a schema node.
>>
>> Agreed.
>
> I see. Okay, thanks for the clarification and yes, if this was explicitly
> mentioned in the RFC it would be great. Although, the validity of your
> example was not in question. Rather something like:
>
> container foo {
> if-feature X;
> container bar;
> }
>
> augment /foo/bar {
> container Y;
> }
>
> I am just going to assume this is what you meant and simply that the
> requirement is that any schema path must point to an existing schema node,
> ignoring any "if-feature" statements.
I think it also depends on whether features are set before or after processing
the modules. In the former case, an augment statement with an effectively
missing target node can IMO be silently ignored, without even parsing its
contents.
Lada
>
> Regards,
> Michal
>
>> >
>> > Another related issue:
>> >
>> >container zed {
>> > leaf baz {
>> >type leafref {
>> > path /foo/bar;
>> >}
>> >}
>> > }
>>
>> This is not permitted, see section 9.9 in RFC 7950:
>>
>>If the leaf that the leafref refers to is conditional based on one or
>>more features (see Section 7.20.2), then the leaf with the leafref
>>type MUST also be conditional based on at least the same set of
>>features.
>>
>> Lada
>>
>> >
>> >
>> > This example is not clear because the path-stmt argument specifies a data
>> > node.
>> >
>> > Is it also valid YANG to have a leafref in an unconditional leaf point at
>> > an if-feature conditional leaf?
>> > Does leaf baz need "if-feature X" added?
>> > Is this a syntax error? A run-time error? Neither?
>> > Is it invalid or does leaf /zed/baz simply have an empty value set?
>> > Is it OK for a leafref node to have an empty value set?
>> >
>> > This corner case keeps coming up in real YANG modules so it would be great
>> > if the standard clarified this behavior.
>> >
>> >
>> > Andy
>> >
>> >
>> >
>> >> > If you disagree, perhaps a thread to the netmod alias would get you an
>> >> > 'official' answer on the proper behavior.
>> >>
>> >> I have sent the email to "netconf" because that is WG that published it
>> >> but no harm in adding a copy for "netmod".
>> >>
>> >> > Eric
>> >> >
>> >> > > -Original Message-
>> >> > > From: netconf On Behalf Of Michal Vaško
>> >> > > Sent: Thursday, April 1, 2021 11:14 AM
>> &g
Re: [netmod] [netconf] YANG Push module errors
Andy Bierman writes:
> On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote:
>
>> Hi Eric,
>>
>> thanks for the answer.
>>
>> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
>> wrote:
>>
>> > Hi Michal,
>> >
>> > This sounds like a tooling issue to me. I would expect that any augments
>> > would inherit the conditional nature of anything augmented.
>>
>> Perhaps, but there is nothing in the specification to hint this. On the
>> contrary, leafrefs, for example, explicitly require to be conditional on
>> the same set of if-features than their targets. But you are right, there is
>> no such requirements for augments. Still, if the feature is disabled and
>> the augment should be applied, since its target does not technically exist
>> in the schema, it cannot be found. That is the error our tools currently
>> produce.
>>
>>
> Maybe this is not clear enough in RFC 7950.
>
> This seems valid:
>
> container foo {
>if-feature X;
> leaf bar { type string; }
> }
>
> augment /foo {
> container Y;
> }
>
> The YANG syntax validation should be done as if all features are enabled.
> It is a tooling issue if this is rejected. This is clear because the
> augment-stmt argument specifies a schema node.
Agreed.
>
> Another related issue:
>
>container zed {
> leaf baz {
>type leafref {
> path /foo/bar;
>}
>}
> }
This is not permitted, see section 9.9 in RFC 7950:
If the leaf that the leafref refers to is conditional based on one or
more features (see Section 7.20.2), then the leaf with the leafref
type MUST also be conditional based on at least the same set of
features.
Lada
>
>
> This example is not clear because the path-stmt argument specifies a data
> node.
>
> Is it also valid YANG to have a leafref in an unconditional leaf point at
> an if-feature conditional leaf?
> Does leaf baz need "if-feature X" added?
> Is this a syntax error? A run-time error? Neither?
> Is it invalid or does leaf /zed/baz simply have an empty value set?
> Is it OK for a leafref node to have an empty value set?
>
> This corner case keeps coming up in real YANG modules so it would be great
> if the standard clarified this behavior.
>
>
> Andy
>
>
>
>> > If you disagree, perhaps a thread to the netmod alias would get you an
>> > 'official' answer on the proper behavior.
>>
>> I have sent the email to "netconf" because that is WG that published it
>> but no harm in adding a copy for "netmod".
>>
>> > Eric
>> >
>> > > -Original Message-
>> > > From: netconf On Behalf Of Michal Vaško
>> > > Sent: Thursday, April 1, 2021 11:14 AM
>> > > To: netconf
>> > > Subject: [netconf] YANG Push module errors
>> > >
>> > > Hi,
>> > >
>> > > we are led to believe there is an error in the ietf-yang-push module
>> > published in
>> > > RFC 8641 but I wanted to discuss it here before submitting an errata.
>> > There are 2
>> > > augments [1] on a notification that is conditional 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 errata?
>> > >
>> > > Regards,
>> > > Michal
>> > >
>> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page
>> > >
>> > > ___
>> > > netconf mailing list
>> > > netc...@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netconf
>>
>> ___
>> netconf mailing list
>> netc...@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> ___
> 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 questions
Tony Li writes: > Hi, > > I have some basic questions about YANG. I’m pretty certain this is NOT the > right place to ask them, so please feel free to redirect me. > > > 1) Is there a way to define the width of an enumeration? Suppose I had an > enumeration that was in a 16 bit field, how do I describe that? In the description, if necessary. However, this should be an implementation detail, as long as the underlying numeric type can accommodate all enums. You could perhaps also define and enum for the highest possible value and make in reserved. > > 2) How do I model a non-octet sized multi-bit field? For example, if there > is a 5 bit numeric value as part of some ‘bits’? Position only takes a > single value, I can’t really say ‘position 3-7’. In this case, I would question whether the 'bits' type is really appropriate. 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 -- 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 of prefixes in YANG models
t;proper module prefix". In >> the absence of a proper definition, one should follow what RFC 7950 says. >> >> Comments? >> >> Mahesh Jethanandani >> mjethanand...@gmail.com >> >> >> >> >> > >> ___ >> 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
William Lupton writes: > Lada, all, > > Surely a description is the only way to add a normative requirement that > can't be expressed via YANG statements (including XPath expressions)? > > I've always assumed that it's good practice to express what you can using > the modeling language, and then use the description to express any > non-modelable requirements. Obviously there's a problem if the description > conflicts with a modeled requirement (and I think it's also good practice > for the description not to repeat anything that's modeled elsewhere). > > I think that RFC 7950 can be interpreted as indicating that the description > is more than just informative. I found this in Section 11, and I take this > to imply that the description defines the semantics of a definition. Even then, it is unclear what effects are permitted with this "more than informative". In a previous mail I refered to a standard module having a description that defines a (computed) default. This seems to be acceptable. But what about simulating a "when" statement for constraints that cannot be expressed via XPath? For example: description "This leaf is only valid if the value of foo is prime."; I argued in the past that everything that cannot be expressed formally with YANG statements should be left outside of scope for YANG, at least in terms of data tree validation. > > A "description" statement may be added or changed without changing the > > semantics of the definition. > > > For example, if a description says this (this is an example from RFC 7950), > then isn't this a _normative_ semantic requirement? > > "The amount 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 at 10:21, Ladislav Lhotka > wrote: > >> Juergen Schoenwaelder writes: >> >> > A client that has no clue of the annotated leaf can rightfully assume >> > that the default 0 applies. If another client creates this magic leaf >> > that changes the default to 10, then there is going to be confusion. >> > >> > A definition that says 'default 0' says the default is 0. It does not >> > say the default may be zero or something different depending on >> > whether the moon shines or other circumstances. I believe you can't >> > undo a default statement with a description somewhere else. >> >> The problem with descriptions is that there seems to be a general >> agreement that they can somehow supplement the formal YANG statements in >> specifying the data model. This has no support in RFC 7950 though: >> >> - section 7.21.3 only says that a description is "a human-readable textual >> description of this definition" >> >> - section 8.1 doesn't include constraints specified in descriptions in the >> concept of data tree validity >> >> As a result, data model constraints specified in descriptions is a grey >> area, and it is totally unclear how far-reaching they can possibly be. >> >> Lada >> >> > >> > /js >> > >> > On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi wrote: >> >> Andy, Juergen, >> >> >> >> I am not sure I understand the issue with a client that does not >> understand the augment. >> >> >> >> When this client writes in the running DS, it will not set the bar >> attribute (which is also defined in the augment module) and therefore the >> default value 0 will be applied by the system, as expected by the client. >> >> >> >> When this client reads from the operational DS the applied >> configuration, provided by another client which understands the augment, it >> will see that the applied configuration for the leaf foo is 10. >> >> >> >> This is a valid applied configuration if the other client had >> explicitly configured the value 10 in the running DS. >> >> >> >> The only difference would be that when the value 10 is explicitly >> configured by the other client the origin is set to intended while when >> “implicitly” configured using the attribute bar, the origin can be set to >> system (I think it would not be correct to set the origin to default in >> this case). >> >> >> >> BTW, I agree that this is not the most elegant/clean design and that >> the best approach would be not to define any default value in the base >>
Re: [netmod] Questions about how to assign default values with YANG
ple {
>> > prefix ex;
>> > }
>> >
>> > augment "ex:example" {
>> > leaf bar {
>> > type empty;
>> > description
>> > "When present, the default value for foo is 10.";
>> > }
>> > }
>> > }
>> >
>> >
>> > In this case, when the leaf foo is not configured but the leaf bar is
>> > present, the value of foo in the operational datastore should be 10
>> > (rather than 0).
>> >
>> > In this case, I think that it would be better/cleaner if the origin is
>> > marked as system.
>> >
>> > Maybe a better YANG description for bar could be: "When present, the
>> > system overrides the default value of foo to 10."
>> >
>> > What is your and/or WG opinion?
>> >
>> > Thanks again
>> >
>> > Italo
>> >
>> > > -Original Message-
>> > > From: Juergen Schoenwaelder
>> > > [mailto:j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>]
>> > > Sent: mercoledì 20 gennaio 2021 17:05
>> > > To: Italo Busi mailto:italo.b...@huawei.com>>
>> > > Cc: 'netmod@ietf.org<mailto:netmod@ietf.org>'
>> > > mailto:netmod@ietf.org>>
>> > > Subject: Re: [netmod] Questions about how to assign default values with
>> > > YANG
>> > >
>> > > On Wed, Jan 20, 2021 at 02:41:39PM +, Italo Busi wrote:
>> > > >
>> > > > What about the case the leaf is not conditional (but still mandatory
>> > > > false
>> > > since a YANG default statement is defined)?
>> > > >
>> > > > May the server still decide not to use/implement this leaf in the
>> > > > operational
>> > > datastore?
>> > > >
>> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by
>> > > default.
>> > > > What should be the behavior of a system which does not implement auto-
>> > > negotiation?
>> > > > Return the value false or no value (in the operational datastore)?
>> > > >
>> > >
>> > > Here are some of the rules I personally like:
>> > >
>> > > - is the ground truth about what a system has and does
>> > > - do not implement leafs that do not apply
>> > >
>> > > Hence, interfaces supporting auto-negotiation have either auto-
>> > > negotiation/enabled = true or auto-negotiation/enabled = false in
>> > > . And interfaces not supporting auto-negotiation have
>> > > nothing
>> > > to report about auto-negotiation. Yes, I do not want to see auto-
>> > > negotiation/enabled = false on a loopback interface.
>> > >
>> > > My historic Ethernet interface from the last century would also not
>> > > report
>> > > auto-negotiation/enabled in . You may hit 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 reasons (instrumentation not
>> > > implemented, access control rules, 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, enabled, disabled, failed,
>> > > not-available, ...).
>> > > So you settle on blaming the model writer. ;-)
>> > >
>> > > /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/>
>> >
>>
>> --
>> 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<mailto: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
--
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
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 Lhotka
> mailto:ladislav.lho...@nic.cz>
> > <mailto:ladislav.lho...@nic.cz <mailto:ladislav.lho...@nic.cz>>>
> wrote:
> >
> > Italo Busi <mailto:italo.b...@huawei.com> <mailto:italo.b...@huawei.com
> <mailto:italo.b...@huawei.com>>>
> > writes:
> >
> > > Hi Juergen,
> > >
> > > Thanks again for your clear explanation on this topic
> > >
> > > I have found a similar but slightly different issue. In this
> case,
> > a YANG default statement exists in the base module but the
> intention
> > with the augmentation is to "overwrite" the default value on the
> > basis of another attribute, defined in the module which
> augments the
> > base module.
> > >
> > > For example, I am wondering whether such a code is valid:
> >
> > Yes, this is valid, I'd just suggest:
> >
> >
> > I do not agree.
> > I do not see how the description-stmt for /foo can change the default
> > leaf processing for /bar
> >
>
> Are you saying that the (computed) default values specified in
> description strings (as in ietf-ipv6-router-advertisements) are illegal?
>
>
> Of course not.
> In this case there MUST NOT be a YANG default-stmt in use for the leaf
> or leaf-list.
>
> If the leaf or leaf-list does have a YANG default-stmt that MUST be
> used, then
> no description-stmt can undo the requirements in 7.6.1
Isn't it exactly what I was suggesting in my two items? Namely: remove
the "default" statement for "foo" and write this in the description of
"foo":
The default value is 10 if the "bar" sibling leaf exist,
and zero otherwise.
Lada
>
>
>
> Lada
>
>
>
> Andy
>
>
> >
> >
> >
> > - remove the default statement for "foo", as it may be
> confusing to
> > both humans and tools
> >
> >
> > sec 7.3.4:
> >
> > If the base type has a default value and the new derived type does
> > not specify a new default value, the base type's default value is
> > also the default value of the new derived type.
> >
> >
> >
> > sec 7.6.1
> >
> >
> > The default value of a leaf is the value that the server uses
> if the
> > leaf does not exist in the data tree. The usage of the default
> value
> > depends on the leaf's closest ancestor node in the schema tree that
> > is not a non-presence container (see Section 7.5.1
> <https://tools.ietf.org/html/rfc7950#section-7.5.1
> <https://tools.ietf.org/html/rfc7950#section-7.5.1>>):
> >
> > o If no such ancestor exists in the schema tree, the default value
> > MUST be used.
> >
> > o Otherwise, if this ancestor is a case node, the default
> value MUST
> > be used if any node from the case exists in the data tree or the
> > case node is the choice's default case, and if no nodes from any
> > other case exist in the data tree.
> >
> > o Otherwise, the default value MUST be used if the ancestor node
> > exists in the data tree.
> >
> >
> >
> >
> > - specify the default (both cases) in the description of "foo"
> >
> > A similar example is in the module
> ietf-ipv6-router-advertisements,
> > e.g. leaf "min-rtr-adv-interval":
> >
> > https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1
> <https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1>
> > <https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1
> <https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1>>
> >
> > Lada
> >
> >
> >
> > Andy
> >
> >
> >
> > >
> > > module example-base {
> > > container example {
> > >
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,
> >
> > Thanks again for your clear explanation on this topic
> >
> > I have found a similar but slightly different issue. In this case,
> a YANG default statement exists in the base module but the intention
> with the augmentation is to "overwrite" the default value on the
> basis of another attribute, defined in the module which augments the
> base module.
> >
> > For example, I am wondering whether such a code is valid:
>
> Yes, this is valid, I'd just suggest:
>
>
> I do not agree.
> I do not see how the description-stmt for /foo can change the default
> leaf processing for /bar
>
Are you saying that the (computed) default values specified in
description strings (as in ietf-ipv6-router-advertisements) are illegal?
Lada
>
>
>
> - remove the default statement for "foo", as it may be confusing to
> both humans and tools
>
>
> sec 7.3.4:
>
>If the base type has a default value and the new derived type does
>not specify a new default value, the base type's default value is
>also the default value of the new derived type.
>
>
>
> sec 7.6.1
>
>
>The default value of a leaf is the value that the server uses if the
>leaf does not exist in the data tree. The usage of the default value
>depends on the leaf's closest ancestor node in the schema tree that
>is not a non-presence container (see Section 7.5.1
> <https://tools.ietf.org/html/rfc7950#section-7.5.1>):
>
>o If no such ancestor exists in the schema tree, the default value
> MUST be used.
>
>o Otherwise, if this ancestor is a case node, the default value MUST
> be used if any node from the case exists in the data tree or the
> case node is the choice's default case, and if no nodes from any
> other case exist in the data tree.
>
>o Otherwise, the default value MUST be used if the ancestor node
> exists in the data tree.
>
>
>
>
> - specify the default (both cases) in the description of "foo"
>
> A similar example is in the module ietf-ipv6-router-advertisements,
> e.g. leaf "min-rtr-adv-interval":
>
> https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1
> <https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1>
>
> Lada
>
>
>
> Andy
>
>
>
> >
> > module example-base {
> > container example {
> > leaf foo {
> > type uint8;
> > default 0;
> > }
> > }
> > }
> >
> > module example-augment {
> > import example {
> > prefix ex;
> > }
> >
> > augment "ex:example" {
> > leaf bar {
> > type empty;
> > description
> > "When present, the default value for foo is 10.";
> > }
> > }
> > }
> >
> >
> > In this case, when the leaf foo is not configured but the leaf bar
> is present, the value of foo in the operational datastore should be
> 10 (rather than 0).
> >
> > In this case, I think that it would be better/cleaner if the
> origin is marked as system.
> >
> > Maybe a better YANG description for bar could be: "When present,
> the system overrides the default value of foo to 10."
> >
> > What is your and/or WG opinion?
> >
> > Thanks again
> >
> > Italo
> >
> >> -Original Message-
> >> From: Juergen Schoenwaelder
> [mailto:j.schoenwael...@jacobs-university.de
> <mailto:j.schoenwael...@jacobs-university.de>]
> >> Sent: mercoledì 20 gennaio 2021 17:05
> >> To: Italo Busi mailto:italo.b...@huawei.com>>
> >> Cc: 'netmod@ietf.org <mailto:netmod@ietf.org>' <mailto:netmod@ietf.org>>
> >> Subject: Re: [netmod] Questions about how to assign default
> values with
> >> YANG
> >>
> >> On Wed, Jan 20, 2021 at 02:41:39PM +, Italo Busi wrote:
> >> >
> >> > What about the case the leaf is not conditional (but still
> mandatory false
> >> si
Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts
"Rob Wilton (rwilton)" writes: > Hi Lada, > > Thanks for the feedback. I agree that we should think about this. > > Looking at those slides, it also asks the question as to whether a YANG file > derived from an IANA registry entry should ever differ. I agree with the > answer proposed in those slides: I.e., the two should always be kept in sync, > even if that ends causing a non-backwards-compatible change to the YANG > module. This was actually a reaction to some voices in the DNSOP WG that went like "IANA registries are broken, why don't we abandon them and keep doing the right thing just in the YANG modules?" > > But my question is whether we should add any text to the IANA section of this > document to make this explicit? Yes, I think so. The update rules of sec. 11 in RFC 7950 don't work well with these modules. In fact, an ideal outcome would be that no instructions to IANA need to be given, i.e. the correct YANG module could be generated automatically from the registry. The approach via XSLT adopted in https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-02 comes pretty close, at least for the DNS Parameters registry. I think that the rules for "rev:..." backward compatibility statements could also be implemented this way. > > > Regarding your second issue: > > I agree that unifying the definitions between IANA and YANG would be ideal, > but I'm not sure whether that will be feasible in the short term. > > draft-ietf-netmod-yang-module-versioning-02 tries to encourage stricter YANG > definitions of deprecated and obsolete (both in the rules defining what is > backwards compatible, and also new YANG library leaves to advertise that the > server conforms to the stricter behaviour): > > I.e., the behaviour that it is trying to encourage is: > - deprecated nodes must be implemented (just like status current nodes), or > otherwise explicitly deviated if they are not supported. > - obsolete nodes must not be implemented. > > The reason that stricter semantics are proposed is so that the client can > know the exact schema supported by the server rather than having to guess > whether or not deprecated or obsolete nodes are implemented. > > I read the IANA definition of deprecated as being "SHOULD NOT implement", and > YANG doesn't today have a status value that maps well to. In particular, > YANG doesn't currently have a way to express to a client that a deprecated > node that "should not be implemented" actually is still implemented by a > server. E.g., the reverse semantics of "deviate not-supported". > > Hence, I wonder YANG shouldn't end up with 4 levels of status (better name > required for 'really-deprecated'): > > (1) "current": Current. Must implement or deviate not-supported > (2) "deprecated":Going away. Should implement, but may deviate > not-supported > (3) "really-deprecated": Really going away. Should not implement, but may > deviate to indicate it is still supported. > (4) "obsolete": Dead. Must not implement. Cannot deviate. Perhaps the first three could be sufficient. It somebody feels the need to implement something in the category (4), they would do it anyway, and it is then better to indicate it via deviation. As I understand it, "obsolete" in the IANA sense is a mere statement of the fact that nobody uses that item any more. > > Note, that a separate status "experimental" has been proposed previously as > an addition for YANG Next, tracked by > https://github.com/netmod-wg/yang-next/issues/59 Yes, 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". > > But this can't really be solved until we have a new revision of YANG. > > Rob > > >> -Original Message- >> From: netmod On Behalf Of Ladislav Lhotka >> Sent: 03 March 2021 12:19 >> To: Rob Wilton (rwilton) ; >> netmod@ietf.org >> Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and >> Semver Drafts >> >> Hi Rob, >> >> I don't know whether this has been discussed, but one issue that might >> need to be addressed is the difference between IANA and YANG in the >> definitions of "obsolete" and "deprecated" - the details are here (slide >> 5): >> >> https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa- >> yang-types-for-dns-classes-and-res
Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts
G modules are referenced in the >appropriate way. > >IANA is responsible for maintaining and versioning some YANG modules, >e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang >[RoutingTypesYang] . > >In addition to following the rules specified in the IANA >Considerations section of [I-D.ietf-netmod-yang-module-versioning] , >IANA maintained YANG modules MUST also include a YANG Semver revision >label for all new revisions, as defined in Section 3 . > >The YANG Semver version associated with the new revision MUST follow >the rules defined in Section 3.3 . > >Note: For IANA maintained YANG modules that have already been >published, revision labels MUST be retrospectively applied to all >existing revisions when the next new revision is created, starting at >version "1.0.0" for the initial published revision, and then >incrementing according to the YANG Semver version rules specified in >Section 3.3 . > >Most changes to IANA maintained YANG modules are expected to be >backwards-compatible changes and classified as MINOR version changes. >The PATCH version may 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 is not semver here, it is "can we harmonize N > different existing definition of "0..100" to one. And it seems the > answer is "no", at least not in a backwards compatible way if people > picked different base types. +1 Lada > > /js > -- 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 10:49, Martin Björklund wrote:
> Hi,
>
> Section 11 of RFC 7950 says:
>
>o A "type" statement may be replaced with another "type" statement
> that does not change the syntax or semantics of the type. For
> example, an inline type definition may be replaced with a typedef,
> but an int8 type cannot be replaced by an int16, since the syntax
> would change.
>
> If we're just considering XML, then the syntax or encoding wouldn't
> change if we went from
>
> type int64 { range "2..4"; }
>
> to
>
> type string { pattern "2|3|4"; }
>
> or
>
> type enumeration {
> enum 2;
> enum 3;
> enum 4;
> }
>
> or
>
> type union {
> type uint8 { range "2"; }
> type string { pattern "3"; }
> type enumeration { enum 4; }
> }
>
>
> But I don't think this is reasonable, and not the intention. I think
> that changing the base built-in type always should be considered
> non-backwards compatible (which the quoted text above seems to imply).
Agreed. Another problem related to sec. 11 is that it permits to update
a module so that the range specification is extended, which may then
expose the incompatibility of e.g. uint8 and int8.
But I thought that Jürgen's question was directed to the definition of
backward compatibility in the semver context.
Lada
>
>
> /martin
>
>
>
>
> Juergen Schoenwaelder wrote:
>> On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
>>>
>>>
>>>> On 2021-02-19, at 19:18, Juergen Schoenwaelder
>>>> wrote:
>>>>
>>>> I think the CBOR encoding picks different tags depending on the
>>>> signedness of the base type and this is why things are not that simple
>>>> anymore.
>>>
>>> (This is not the CBOR encoding, but the COMI encoding of keys in URIs.)
>>
>> OK. The CBOR document indeed says:
>>
>> 6.1. The unsigned integer Types
>>
>>Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
>>a CBOR unsigned integer data item (major type 0).
>>
>> 6.2. The integer Types
>>
>>Leafs of type int8, int16, int32 and int64 MUST be encoded using
>>either CBOR unsigned integer (major type 0) or CBOR negative integer
>>(major type 1), depending on the actual value.
>>
>> This means the type 'int8 { range 0..10; }' leads to the same
>> encodings as the type 'uint8 { range 0..10; }'.
>>
>>>> For the XML and JSON encodings, all definitions lead to the
>>>> same on-the-wire representation, hence the difference is more an
>>>> implementation detail. I have no clue what the gnmi people do. The
>>>> more diverse encodings we add, the more complex things get.
>>>
>>> Well, if the equivalence expectation that I was trying to describe actually
>>> is ingrained, then whoever designs an encoding (COMI for its URI encoding
>>> included) needs to respect it. That would be important to know.
>>>
>>
>> Exactly. I think we never defined this. And of course, this can get
>> even more fun if you consider string based 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 YANG language would have clear rules
>> what YANG's type equivalences are.
>>
>> /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
>
--
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] Structuring a DHCP module
e examples as I've only seen features been used as relatively small >>> optional extensions used when the bulk of the nodes are common?] >> >> [tp] >> Ian >> >> Almost all the YANG models I know of are single module. For example, >> draft-ietf-ospf-yang supports two versions modelled as identity and 28 >> options modelled as features. >> >> draft-ietf-tcpm-yang supports client and server as containers with >> if-feature and has other features as well >> >> draft-ietf-pim-igmp-mld-yang supports five versions of two protocol >> using identity >> >> draft-pce-pcep-yang offers the roles of pcc or pce or both using typedef. >> >> And so on and so on. if-feature, when and suchlike provide the >> necessary customisation. >> >> I think that your problems with options are because the identity are >> defined in the wrong place. The base, the common module (or part of the >> one and only module) should define what is common, what everyone needs; >> if there are three roles and a dozen options, than that is where they >> need to be defined. >> >> Then there can be an object which is configured with the roles of a >> particular box, client or server or relay, or if required, a combination >> of the there - simpler if that is out of scope as you suggest. >> >> My starting point would be a dhc container with a leaf for a role and then >> containers for client, relay, server, added by augment and controlled by >> when pointing at the role. >> >> I will post something to the netmod WG list - there are lots of people >> there with greater exposure than mine who can give better guidance than I. >> >> Tom Petch >> >>> Here you have modelled the options as YANG grouping. The intent of a >>> grouping is to provide a block of statements that can be reused so avoiding >>> duplication with the attendant problems. Here you have the same grouping >>> in triplicate in three different YANG modules which seems to me to be the >>> antithesis of a grouping. >>> >>> [If - We 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 the duplication. I >>> didn’t do this previously as the intention was to keep options definitions >>> in the options modules for consistency, but it would be simple to change. ] >>> >>> [tp] Likewise I find the specification of server v client v relay unusual. >>> >>> [If - A similar approach for separated client/server modules is also used >>> in RFC8676, where the client and server have discrete function, as with >>> DHCP.] >>> >>> [tp]I wonder if it is worth consulting a YANG doctor, NOT to show them the >>> YANG and invite comments, rather outline in an abstract way what it is you >>> want to model and see what they suggest; that might well be a single YANG >>> module. >>> >>> [if - Yes, I’d be happy to. Is there someone that you have in mind (I’ve >>> not had much luck with getting YANG doctor input outside of the formal >>> review process in the past)?. I’m not opposed to changing the way that the >>> modules are structured on principal, I do however, think that the >>> separation by functional element is logical and simpler for implementers, >>> and I would like to know what the benefits of a single module (or other >>> structure) might be.] >>> >>> [tp]I do have quite a number of detailed comments but do not think them >>> worth making until the I-D seems to me more stable. >>> >>> [if - It’d be great if you could supply them as well so I can start going >>> though them and fixing what’s currently fixable in parallel to the >>> discussion above.] >>> >>> Tom Petch >>> >>> On 07/01/2021 16:10, >>> ianfar...@gmx.com<mailto:ianfar...@gmx.com><mailto:ianfar...@gmx.com<mailto:ianfar...@gmx.com>> >>> wrote: >>> Hi Tom, >>> -- 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] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances
tom petch writes: > > > In the category of general annoyance, rather than the points above, the IETF > has abolished the page number. Look at recent RFC and pagination has > vanished. The justification is that RFC are now available in different > format and that page numbers are not consistent across the format so they > must be eliminated. > > This came up on RFC Interest and I asked how to reference a piece of text and > was told that you include lots of section numbers. I asked about 50-page > YANG modules with no sections but this is a requirement that has escaped the > tool-makers. One suggestion was to include lots of numbered sub-headings, > another to include separate sourcecode elements with an anchor for each. I share your concerns, but these developments are hard to avoid - people want to read the documents on the small screens of their phones, and a fixed format isn't well suited for that. > One passing comment was that with v3 xml the extraction code should not be > needed any more. I do not understand but expect that there will be > interesting times. I don't know what the plan is, but in the recent survey on IETF authoring tools, I suggested the option of including YANG modules in xml2rfc sources as foreign-namespace blocks in the YIN format. This could solve most of these issues and, in particular, allow for safely reflowing text in descriptions etc. along with the rest of the RFC. Regarding markup inside description/contact/reference/error-message, I think XML is in fact still the best option. Light-weight choices such as markdown are too brittle for these purposes. Lada > > Tom Petch > > William > > On Sat, 7 Nov 2020 at 05:07, Carsten Bormann > mailto:c...@tzi.org>> wrote: > On 2020-11-07, at 01:06, Michael Richardson > mailto:mcr%2bi...@sandelman.ca>> wrote: >> >> M-q reflowed a paragraph, but made it too long with 76 columns wide. > > Is your .emacs setting fill-column to a non-standard value? > > C-x f 69 RET > > or put > > // -*- fill-column: 69 -*- > > into the first line of your YANG file (in a comment) > or better > > (add-hook 'yang-mode-hook > '(lambda () (set-fill-column 69))) > > in your .emacs. > > Grüß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 > 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] reflow of YANG descriptions, and general YANG format annoyances
Hi, my solution that I've been using for years is to write YANG modules in the YIN syntax. With the nXML mode of emacs this is actually rather effective (statement completion, on-the-fly validation). I also extended the YIN syntax with a few XML elements from the XHTML namespace. This helps me to handle paragraphs and lists in a safe way. Descriptions etc. are then reflowed automatically as a part of XSLT transform to the compact YANG syntax. Here are the details: https://gitlab.nic.cz/labs/yang-tools/-/wikis/editing_yang See also https://github.com/llhotka/YANG-I-D Lada Michael Richardson writes: > As people do more YANG modules, more and more logic and description moves > from regular text into the YANG module. Where it is awkward and annoying to > edit. > > And references from YANG modules don't get counted/resolved/updated, and > all sorts things that the XML format was designed to solve have basically > reverted to 1996 era (without even nroff) when it comes text in the YANG > module. > > In one of my drafts, I guess some minor wording tweaks in one draft leads to > some lines exceeding 72 characters (by one). Argh. Change from C-mode to > text-mode. reflow. > > It seems like we should be thinking about what to do here. > I was introduced to the SED method of fixing yang MMDD version > references. > > While I like YANG as executable "code", it sure feels like it is not smart 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.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] identityref with multiple base statements (follow-up question)
Italo Busi writes:
> I have a follow-up question about this topic
>
> Considering the same identities defined below, what would be the valid values
> the following references?
>
> leaf reference-1 {
> type identityref {
> base base-1;
> }
> description
> "Reference to an identity #1.";
> }
>
> leaf reference-2 {
> type identityref {
> base base-2;
> }
> description
> "Reference to an identity #2.";
> }
>
> My understanding, is that:
> - valid values for the reference-1 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:ladislav.lho...@nic.cz]
>> Sent: lunedì 3 agosto 2020 10:45
>> To: Joey Boyd ; netmod@ietf.org
>> Subject: Re: [netmod] identityref with multiple base statements
>>
>> Joey Boyd writes:
>>
>> > Hi,
>> >
>> > I am looking for some clarification regarding RFC 7950 section 9.10.2,
>> specifically this statement.
>> >
>> > Valid values for an identityref are any identities derived from all the
>> identityref's base identities.
>> >
>> > Example:
>> >
>> > identity base-1 {
>> > description
>> > "Base identity #1.";
>> > }
>> >
>> > identity base-2 {
>> > description
>> > "Base identity #2.";
>> > }
>> >
>> > identity a {
>> > base base-1;
>> > description
>> > "Identity A.";
>> > }
>> >
>> > identity b {
>> > base base-1;
>> > base base-2;
>> > description
>> > "Identity B.";
>> > }
>> >
>> > identity c {
>> > base base-2;
>> > description
>> > "Identity C.";
>> > }
>> >
>> > leaf reference {
>> > type identityref {
>> > base base-1;
>> > base base-2;
>> > }
>> > description
>> > "Reference to an identity.";
>> > }
>> >
>> > The question is how to determine the value space for this identityref.
>> >
>> > Option #1:
>> > The value space is any identity which is derived from both base identities.
>> This means the only valid value in the example would be 'b'.
>> >
>> > Option #2:
>> > The value space is any identity which is derived from either base identity.
>> This means the valid values are 'a', 'b' and 'c'.
>> >
>> > The phrasing "...derived from all the identityref'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
>>
>
--
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] 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: >>>> >>>> Hi, >>>> >>>> "Joe Clarke \(jclarke\)" wrote: >>>>> At the IETF 108 virtual meeting, Lada asked about what would happen if >>>>> he converted a YANG module to YIN syntax (or vice versa, or to some >>>>> other format). This was during the discussion of the issue of what >>>>> should happen if a module changes and the only changes are >>>>> insignificant whitespaces (e.g., strip trailing spaces, change line >>>>> length of descriptions, etc.). >>>>> >>>>> The authors/contributors discussed on this on our weekly calls, and we >>>>> propose: >>>>> >>>>> If a module changes and those changes are only insignificant >>>>> whitespace changes and the syntax of the module remains the same >>>>> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module >>>>> MUST be created. If you are using YANG semver as your revision >>>>> scheme, you MUST apply a PATCH version bump to that new module >>>>> revision to indicate an editorial change. >>>>> >>>>> The reasoning behind this decision is that it makes it very clear and >>>>> unambiguous to consumers that this module has been consciously >>>>> changed, and those changes are only editorial. This way one won’t be >>>>> concerned if they note that a module of a given syntax with the same >>>>> version but different checksums and diffs wasn’t otherwise >>>>> manipulated. >>>> >>>> I think this is the wrong way to go. I clean up formatting issues all >>>> the time, including IETF modules. I am pretty sure that if you >>>> retrieve modules like "ietf-interfaces" or "ietf-yang-types" from >>>> different vendors' products, you will get modules with differences in >>>> whitespace - and this is not a problem AFAIK. >>>> >>>> I think it is ok that a simple "diff" show whitespace changes in this >>>> case. I don't think it leads to any real problems. >>> >>> We discussed this on the call. The thinking was that a long diff output >>> would essentially be unwieldy for some modules and important changes might >>> be lost. If the versions were the same, it would be ambiguous to the >>> consume as to whether or not the module was only changed in trivial (i.e., >>> less-than-editorial) or if more substantive changes happened. If you trust >>> the producer, maybe you assume they regenerated the module without trailing >>> whitespace (or the like). We felt there should be a more explicit signal. >>> >>>> >>>>> That said, if a module changes format from one syntax to another but >>>>> maintains semantic equivalency, then the revision and YANG semver MUST >>>>> be the same. In that case, one will use the extension to realize that >>>>> this module file cannot be directly compared to one of another syntax >>>>> without looking at compiled or semantic representation. >>>> >>>> This seems a bit inconsistent. Suppose I round-trip from YANG to YIN >>>> to YANG, and the result is different whitespace in the two YANG >>>> modules. The revision is the same, as explained above. How is this >>>> different from changing the whitespace in YANG directly? >>> >>> We didn’t discuss this directly, but we did discuss auto-generators that >>> could do this type of round-tripping. The general consensus was that you >>> would use the same post-processing tool (e.g., pyang -f yang) on the result >>> to ensure consistency. And a consumer would look to a canonical source >>> (like IANA, the IETF document, or the vendor) to ensure a consistent module. >>> >>> In terms of alternate sources, I would think that if one wanted to trust an >>> IETF module downloaded from some other site, they could. If that site did >>> some additional formatting, that would be up to the consumer to resolve >>> compared to what might be required by a package. But if the publisher >>> (IETF in this case) were to republish a module with these stripped >>> w
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 >>> Cc: jclarke=40cisco@dmarc.ietf.org; netmod@ietf.org >>> Subject: 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 syntax (or vice versa, or to some >>> other format). This was during the discussion of the issue of what >>> should >>> happen if a module changes and the only changes are insignificant >>> whitespaces (e.g., strip trailing spaces, change line length of >>> descriptions, etc.). >>>>>> >>>>>> The authors/contributors discussed on this on our weekly calls, and >>> we propose: >>>>>> >>>>>> If a module changes and those changes are only insignificant >>> whitespace changes and the syntax of the module remains the same >>> (i.e., >>> YANG to YANG, YIN, YIN, etc.), a new revision of the module MUST be >>> created. If you are using YANG semver as your revision scheme, you >>> MUST >>> apply a PATCH version bump to that new module revision to indicate an >>> editorial change. >>>>>> >>>>>> The reasoning behind this decision is that it makes it very clear and >>> unambiguous to consumers that this module has been consciously >>> changed, >>> and those changes are only editorial. This way one won’t be concerned >>> if >>> they note that a module of a given syntax with the same version but >>> different checksums and diffs wasn’t otherwise manipulated. >>>>>> >>>>>> That said, if a module changes format from one syntax to another but >>> maintains semantic equivalency, then the revision and YANG semver MUST >>> be >>> the same. In that case, one will use the extension to realize that >>> this >>> module file cannot be directly compared to one of another syntax >>> without >>> looking at compiled or semantic representation. >>>>> >>>>> The last paragraph means that after a round trip YANG -> YIN -> YANG >>> the >>>>> initial and final YANG modules MUST have the same revision. However, >>>>> depending on the conversion tools used, they may easily differ in >>>>> whitespace, so their byte-oriented checksums won't be equal. >>>>> >>>>> I think there are in fact three cases: >>>>> >>>>> 1. Whitespace outside statement arguments - I believe this should >>>>> never >>>>> be significant. >>>> >>>> Agreed. >>>> >>>>> 2. Whitespace in the argument of "contact", "description", >>>>> "error-message" and "organization" - this is tricky because tools may >>>>> format such arguments differently. I am leaning towards making >>>>> whitespace insignificant in this case as well. >>>>> >>>>> 3. Whitespace in other arguments has to be significant and lead to a >>>>> revision bump. >>>> >>>> I think that any change in an argument string is an editorial change. >>>> >>>> For example, compare these two changes: >>>> >>>>A1. description "a server."; >>>>A2. description "A server."; >>>> >>>>B1. description "A server."; >>>>B2. description "A server."; >>>> >>>> These are editorial changes, and thus the revision should be changed. >>> >>> But consider >>> >>>description >>>"A server and >>> its data."; >>> >>> versus >>> >>>description >>>"A server and >>>its data."; >>> >>> Here the difference is only in presentation - a YANG parser gives the >>> same
Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
"Joe Clarke \(jclarke\)" writes: >> On Aug 11, 2020, at 10:45, Martin Björklund wrote: >> >> Hi, >> >> "Joe Clarke \(jclarke\)" wrote: >>> At the IETF 108 virtual meeting, Lada asked about what would happen if >>> he converted a YANG module to YIN syntax (or vice versa, or to some >>> other format). This was during the discussion of the issue of what >>> should happen if a module changes and the only changes are >>> insignificant whitespaces (e.g., strip trailing spaces, change line >>> length of descriptions, etc.). >>> >>> The authors/contributors discussed on this on our weekly calls, and we >>> propose: >>> >>> If a module changes and those changes are only insignificant >>> whitespace changes and the syntax of the module remains the same >>> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module >>> MUST be created. If you are using YANG semver as your revision >>> scheme, you MUST apply a PATCH version bump to that new module >>> revision to indicate an editorial change. >>> >>> The reasoning behind this decision is that it makes it very clear and >>> unambiguous to consumers that this module has been consciously >>> changed, and those changes are only editorial. This way one won’t be >>> concerned if they note that a module of a given syntax with the same >>> version but different checksums and diffs wasn’t otherwise >>> manipulated. >> >> I think this is the wrong way to go. I clean up formatting issues all >> the time, including IETF modules. I am pretty sure that if you >> retrieve modules like "ietf-interfaces" or "ietf-yang-types" from >> different vendors' products, you will get modules with differences in >> whitespace - and this is not a problem AFAIK. >> >> I think it is ok that a simple "diff" show whitespace changes in this >> case. I don't think it leads to any real problems. > > We discussed this on the call. The thinking was that a long diff output > would essentially be unwieldy for some modules and important changes might be > lost. If the versions were the same, it would be ambiguous to the consume as > to whether or not the module was only changed in trivial (i.e., > less-than-editorial) or if more substantive changes happened. If you trust > the producer, maybe you assume they regenerated the module without trailing > whitespace (or the like). We felt there should be a more explicit signal. > >> >>> That said, if a module changes format from one syntax to another but >>> maintains semantic equivalency, then the revision and YANG semver MUST >>> be the same. In that case, one will use the extension to realize that >>> this module file cannot be directly compared to one of another syntax >>> without looking at compiled or semantic representation. >> >> This seems a bit inconsistent. Suppose I round-trip from YANG to YIN >> to YANG, and the result is different whitespace in the two YANG >> modules. The revision is the same, as explained above. How is this >> different from changing the whitespace in YANG directly? > > We didn’t discuss this directly, but we did discuss auto-generators that > could do this type of round-tripping. The general consensus was that you > would use the same post-processing tool (e.g., pyang -f yang) on the result > to ensure consistency. And a consumer would look to a canonical source (like > IANA, the IETF document, or the vendor) to ensure a consistent module. > > In terms of alternate sources, I would think that if one wanted to trust an > IETF module downloaded from some other site, they could. If that site did > some additional formatting, that would be up to the consumer to resolve > compared to what might be required 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 convert to YIN first and then apply XML canonicalization: https://www.w3.org/TR/2001/REC-xml-c14n-20010315 As an additional benefit, this would also enable digital signatures of YANG modules. Lada > > Joe > > ___ > 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] 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 syntax (or vice versa, or to some other >> > format). This was during the discussion of the issue of what should >> > happen if a module changes and the only changes are insignificant >> > whitespaces (e.g., strip trailing spaces, change line length of >> > descriptions, etc.). >> > >> > The authors/contributors discussed on this on our weekly calls, and we >> > propose: >> > >> > If a module changes and those changes are only insignificant whitespace >> > changes and the syntax of the module remains the same (i.e., YANG to YANG, >> > YIN, YIN, etc.), a new revision of the module MUST be created. If you are >> > using YANG semver as your revision scheme, you MUST apply a PATCH version >> > bump to that new module revision to indicate an editorial change. >> > >> > The reasoning behind this decision is that it makes it very clear and >> > unambiguous to consumers that this module has been consciously changed, >> > and those changes are only editorial. This way one won’t be concerned if >> > they note that a module of a given syntax with the same version but >> > different checksums and diffs wasn’t otherwise manipulated. >> > >> > That said, if a module changes format from one syntax to another but >> > maintains semantic equivalency, then the revision and YANG semver MUST be >> > the same. In that case, one will use the extension to realize that this >> > module file cannot be directly compared to one of another syntax without >> > looking at compiled or semantic representation. >> >> The last paragraph means that after a round trip YANG -> YIN -> YANG the >> initial and final YANG modules MUST have the same revision. However, >> depending on the conversion tools used, they may easily differ in >> whitespace, so their byte-oriented checksums won't be equal. >> >> I think there are in fact three cases: >> >> 1. Whitespace outside statement arguments - I believe this should never >> be significant. > > Agreed. > >> 2. Whitespace in the argument of "contact", "description", >> "error-message" and "organization" - this is tricky because tools may >> format such arguments differently. I am leaning towards making >> whitespace insignificant in this case as well. >> >> 3. Whitespace in other arguments has to be significant and lead to a >> revision bump. > > I think that any change in an argument string is an editorial change. > > For example, compare these two changes: > >A1. description "a server."; >A2. description "A server."; > >B1. description "A server."; >B2. description "A server."; > > These are editorial changes, and thus the revision should be changed. But consider description "A server and its data."; versus description "A server and its data."; Here the difference is only in presentation - a YANG parser gives the same string in both cases. Another awkward case is whitespace before a line break. Lada > > Note however that the following change might look like an editorial > whitespace change in the argument, but in fact it is not: > > C1. > description > "A server and >its data."; > > C2. > description > "A server and > its data."; > > > /martin > > >> >> 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 >> > ___ >> > 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 -- 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] IETF 108: Summary of insignificant whitespace changes and versioning
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 syntax (or vice versa, or to some other > format). This was during the discussion of the issue of what should happen > if a module changes and the only changes are insignificant whitespaces (e.g., > strip trailing spaces, change line length of descriptions, etc.). > > The authors/contributors discussed on this on our weekly calls, and we > propose: > > If a module changes and those changes are only insignificant whitespace > changes and the syntax of the module remains the same (i.e., YANG to YANG, > YIN, YIN, etc.), a new revision of the module MUST be created. If you are > using YANG semver as your revision scheme, you MUST apply a PATCH version > bump to that new module revision to indicate an editorial change. > > The reasoning behind this decision is that it makes it very clear and > unambiguous to consumers that this module has been consciously changed, and > those changes are only editorial. This way one won’t be concerned if they > note that a module of a given syntax with the same version but different > checksums and diffs wasn’t otherwise manipulated. > > That said, if a module changes format from one syntax to another but > maintains semantic equivalency, then the revision and YANG semver MUST be the > same. In that case, one will use the extension to realize that this module > file cannot be directly compared to one of another syntax without looking at > compiled or semantic representation. The last paragraph means that after a round trip YANG -> YIN -> YANG the initial and final YANG modules MUST have the same revision. However, depending on the conversion tools used, they may easily differ in whitespace, so their byte-oriented checksums won't be equal. I think there are in fact three cases: 1. Whitespace outside statement arguments - I believe this should never be significant. 2. Whitespace in the argument of "contact", "description", "error-message" and "organization" - this is tricky because tools may format such arguments differently. I am leaning towards making whitespace insignificant in this case as well. 3. Whitespace 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 > _______ > 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] identityref with multiple base statements
Joey Boyd writes:
> Hi,
>
> I am looking for some clarification regarding RFC 7950 section 9.10.2,
> specifically this statement.
>
> Valid values for an identityref are any identities derived from all the
> identityref's base identities.
>
> Example:
>
> identity base-1 {
> description
> "Base identity #1.";
> }
>
> identity base-2 {
> description
> "Base identity #2.";
> }
>
> identity a {
> base base-1;
> description
> "Identity A.";
> }
>
> identity b {
> base base-1;
> base base-2;
> description
> "Identity B.";
> }
>
> identity c {
> base base-2;
> description
> "Identity C.";
> }
>
> leaf reference {
> type identityref {
> base base-1;
> base base-2;
> }
> description
> "Reference to an identity.";
> }
>
> The question is how to determine the value space for this identityref.
>
> Option #1:
> The value space is any identity which is derived from both base identities.
> This means the only valid value in the example would be 'b'.
>
> Option #2:
> The value space is any identity which is derived from either base identity.
> This means the valid values are 'a', 'b' and 'c'.
>
> The phrasing "...derived from all the identityref'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 that expects straight Unicode for lexical representation and leave
>>>> it to the implementations to convert to Punycode where necessary, e.g.
>>>> when querying DNS.
>>>
>>> Perhaps. But I am not sure this is the time to fix this or how this
>>> can be done in a backwards compatible way. At least this likely can't
>>> be done by disallowing ACE. It may be possible to add an additional
>>> member to the inet:host union that catches internationalized names.
>>
>> I think it would be better to have an extra set of parallel definitions such
>> as idn-domain-name, or perhaps u-domain-name.
>>
>
> So if we define idn-domain-name, what do we do with your hostname?
> Have hostname derived from domain-name (as discussed before) with
>
> typedef host {
>type union {
> type inet:ip-address;
> type inet:host-name;
> }
>
> and we add
>
> typedef idn-host {
>type union {
> type inet:ip-address;
> type inet:idn-hostname;
> }
>
> and then YANG module writers can opt-in to use the new definition if
> they want idn host names without requiring ACE encoding?
Yes, that was my idea. If IDN becomes widespread (ever), the "idn-host"
version would be much easier to use.
Lada
>
>> Lada
>>
>>> Since this would be enlarging the value space, I believe this is
>>> inline with the spirit of section 11 of RFC 7950. Removing the ACE
>>> names, however, restricts the value space and hence seem to contradict
>>> section 11 of RFC 7950. (The explicit removal of underscore and single
>>> letter hostnames may be considered a clarification since we have other
>>> RFCs stating these constraints.)
>>>
>>> /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/>
>>
>> --
>> 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] 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 Schoenwaelder writes: >> >> >> >>> So would the following do the right thing? >> >> >> >> The invert-match pattern also needs to be added in order to avoid >> >> reserved labels: >> > >> > Why are they illegal? If we make them illegal, how are we going to >> > deal with hosts that have non-ASCII names? >> >> I am not able to find in what sense the "Reserved LDH" labels of RFC >> 5890 are really reserved, and I am not sure about the implications of >> permitting "xn--..." hostnames to be explicitly configured. > > Right now, inet:domain-name as defined in RFC 6991 says: > > [...] > Domain-name values use the US-ASCII encoding. Their canonical > format uses lowercase US-ASCII characters. Internationalized > domain names MUST be A-labels as per RFC 5890."; > > Hence, if you want to configure a non-ASCII hostname using inet:host, > you have to write it in a sequence of A-labels, i.e., using the ASCII > Compatible Encoding (ACE). Hence, removing xn-- names seems to have a > significant potential to break things. OK. > >> If we want to allow non-ASCII names, then it would IMO be safer to use a >> type that expects straight Unicode for lexical representation and leave >> it to the implementations to convert to Punycode where necessary, e.g. >> when querying DNS. > > Perhaps. But I am not sure this is the time to fix this or how this > can be done in a backwards compatible way. At least this likely can't > be done by disallowing ACE. It may be possible to add an additional > member to the inet:host union that catches internationalized names. I think it would be better to have an extra set of parallel definitions such as idn-domain-name, or perhaps u-domain-name. Lada > Since this would be enlarging the value space, I believe this is > inline with the spirit of section 11 of RFC 7950. Removing the ACE > names, however, restricts the value space and hence seem to contradict > section 11 of RFC 7950. (The explicit removal of underscore and single > letter hostnames may be considered a clarification since we have other > RFCs stating these constraints.) > > /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/> -- 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 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 in order to avoid reserved >> labels: > > Why are they illegal? If we make them illegal, how are we going to > deal with hosts that have non-ASCII names? I am not able to find in what sense the "Reserved LDH" labels of RFC 5890 are really reserved, and I am not sure about the implications of permitting "xn--..." hostnames to be explicitly configured. If we want to allow non-ASCII names, then it would IMO be safer to use a type that expects straight Unicode for lexical representation and leave it to the implementations to convert to Punycode where necessary, e.g. when querying DNS. Lada > > /js > -- 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
Juergen Schoenwaelder writes:
> So would the following do the right thing?
The invert-match pattern also needs to be added in order to avoid reserved
labels:
>
> typedef host-name {
> type domain-name {
> pattern '[a-zA-Z0-9\-\.]+';
pattern '(.*\.)?..\-\-.*' {
modifier invert-match;
}
> length "2..max";
> }
> description
> "Host names must be at least two characters long (see RFC 952)
> and they are restricted to labels consisting of letters, digits
>and hyphens separated by dots (see RFC1123 and RFC 952).";
> reference
> "RFC 952: DoD Internet Host Table Specification
> "RFC 1123: Requirements for Internet Hosts: Application and Support";
> }
I am also not 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 wrote:
>> 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 slightly
>> >> > different but I am not sure what exactly, hence I asked again.
>> >>
>> >> Oh yes, I messed it up by mixing different things together, sorry. I
>> >> checked again the ML archive, and the message that is relevant to this
>> >> thread is this:
>> >>
>> >> https://mailarchive.ietf.org/arch/msg/netmod/PISOifrtow4oWLGW7meBBSri7nM/
>> >>
>> >> The aim of that proposal was to limit the "inet:host" type to DNS names
>> >> that are reasonable as host names, i.e. eliminate values like "." or "_".
>> >
>> > You are proposing to change the length restriction from 1..253 to
>> > 2..253 following RFC 952:
>> >
>> >[...] Single character names
>> >or nicknames are not allowed.
>> >
>> > And you add
>> >
>> > pattern '(.*\.)?..\-\-.*' {
>> > modifier invert-match;
>> > }
>> >
>> > to restrict things to non-reserved letter-digit-hyphen labels as per
>> > RFC 5890. Is it clear that this second restriction applies to host
>> > names? How do you represent internationalized host names? Perhaps we
>> > need a collection of examples? And is the pattern correct? RFC 5890
>> > says:
>> >
>> >Reserved LDH labels, known as "tagged domain names" in some other
>> >contexts, have the property that they contain "--" in the third and
>> >fourth characters but which otherwise conform to LDH label rules.
>> >
>> > What is the '(.*\.)?' part doing in your pattern?
>> >
>> > Finally, would it be useful to derive a host-name type from the
>> > domain-name type (if host-names are really a strict subset of what
>> > domain-name allows), e.g.:
>>
>> The current definition of "inet:domain-name" in 6991bis also permits the
>> underscore character in labels, so it is not LDH.
>>
>> Lada
>>
>> >
>> > typedef host-name {
>> > type domain-name {
>> > pattern '(.*\.)?..\-\-.*' {
>> > modifier invert-match;
>> > }
>> > length "2..max";
>> > }
>> > description
>> > "Host names must be at least two characters long (see RFC 952)
>> >and they are restricted to non-reserved letter-digit-hyphen
>> >(NR-LDH) labels (see RFC ).";
>> > reference
>> > "RFC 952: DoD Internet Host Table Specification
>> >RFC : ";
>> > }
>> >
>> > /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/>
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>
> --
> 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
--
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
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 slightly
>> > different but I am not sure what exactly, hence I asked again.
>>
>> Oh yes, I messed it up by mixing different things together, sorry. I
>> checked again the ML archive, and the message that is relevant to this
>> thread is this:
>>
>> https://mailarchive.ietf.org/arch/msg/netmod/PISOifrtow4oWLGW7meBBSri7nM/
>>
>> The aim of that proposal was to limit the "inet:host" type to DNS names
>> that are reasonable as host names, i.e. eliminate values like "." or "_".
>
> You are proposing to change the length restriction from 1..253 to
> 2..253 following RFC 952:
>
>[...] Single character names
>or nicknames are not allowed.
>
> And you add
>
> pattern '(.*\.)?..\-\-.*' {
> modifier invert-match;
> }
>
> to restrict things to non-reserved letter-digit-hyphen labels as per
> RFC 5890. Is it clear that this second restriction applies to host
> names? How do you represent internationalized host names? Perhaps we
> need a collection of examples? And is the pattern correct? RFC 5890
> says:
>
>Reserved LDH labels, known as "tagged domain names" in some other
>contexts, have the property that they contain "--" in the third and
>fourth characters but which otherwise conform to LDH label rules.
>
> What is the '(.*\.)?' part doing in your pattern?
>
> Finally, would it be useful to derive a host-name type from the
> domain-name type (if host-names are really a strict subset of what
> domain-name allows), e.g.:
The current definition of "inet:domain-name" in 6991bis also permits the
underscore character in labels, so it is not LDH.
Lada
>
> typedef host-name {
> type domain-name {
> pattern '(.*\.)?..\-\-.*' {
> modifier invert-match;
> }
> length "2..max";
> }
> description
> "Host names must be at least two characters long (see RFC 952)
>and they are restricted to non-reserved letter-digit-hyphen
>(NR-LDH) labels (see RFC ).";
> reference
> "RFC 952: DoD Internet Host Table Specification
>RFC : ";
> }
>
> /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/>
--
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 22. 07. 20 13:00, Juergen Schoenwaelder wrote: > Tom, > > my understanding is that Lada is now proposing something slightly > different but I am not sure what exactly, hence I asked again. Oh yes, I messed it up by mixing different things together, sorry. I checked again the ML archive, and the message that is relevant to this thread is this: https://mailarchive.ietf.org/arch/msg/netmod/PISOifrtow4oWLGW7meBBSri7nM/ The aim of that proposal was to limit the "inet:host" type to DNS names that are reasonable as host names, i.e. eliminate values like "." 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 wrote: >>> Juergen Schoenwaelder writes: >>> >>>> - Lada suggested to replace the inet:domain-name usage in >>>> the union with a new host-name definition that follows >>>> the NR-LDH definition in RFC 5890. >>>> >>>> - Unclear which problem is fixed and how this works from a >>>> backwards compatibility perspective. >>>> >>>> - See the thread '6991bis: host' in your private list archive >>>> (I can't find it in the IETF archive) >> >> Try the NETMOD WG list archive 21 July 2019 >> >> Tom Petch >> >>>> >>>> - I can't tell for sure that Lada's proposal is (i) correct and (ii) >>>> not breaking anything >>>> >>>> - Proposal: ? >>> >>> Maybe it is better to basically keep the existing inet:domain name for use >>> e.g. in host names that appear in all kinds of non-DNS configuration, and >>> leave the definition of a domain name type appropriate for use in DNS zone >>> data etc. to DNSOP WG. >>> >>> So my proposal is to only modify the description accordingly, and in >>> particular remove the comment about the use in A//SRV resource records, >>> because the existing type isn't really suitable for this purpose. >>> >> >> Can you please send OLD NEW text? I do not really see what needs >> changes. Note that this type definition gets tweaked everytime by IESG >> members as well. >> >> /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 > -- 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
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 follows >> > the NR-LDH definition in RFC 5890. >> > >> > - Unclear which problem is fixed and how this works from a >> > backwards compatibility perspective. >> > >> > - See the thread '6991bis: host' in your private list archive >> > (I can't find it in the IETF archive) >> > >> > - I can't tell for sure that Lada's proposal is (i) correct and (ii) >> > not breaking anything >> > >> > - Proposal: ? >> >> Maybe it is better to basically keep the existing inet:domain name for use >> e.g. in host names that appear in all kinds of non-DNS configuration, and >> leave the definition of a domain name type appropriate for use in DNS zone >> data etc. to DNSOP WG. >> >> So my proposal is to only modify the description accordingly, and in >> particular remove the comment about the use in A//SRV resource records, >> because the existing type isn't really suitable for this purpose. >> > > Can you please send OLD NEW text? I do not really see what needs > changes. Note that this type definition gets tweaked everytime by IESG > members as well. We actually agreed on NEW already here: https://mailarchive.ietf.org/arch/msg/netmod/FYMAQSJQsPiPSkWTs4lOWIgM2bI/ Lada > > /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 -- 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:xpath1.0
Juergen Schoenwaelder writes: > - How do we deal with xpath expressions in other encodings > such as JSON. Do we assume an xpath context populated with > module names such that module names can be used to qualify > path expressions. This may need discussion and/or a new > definition. XPath context is not only namespaces and prefixes. For example, are the extra functions from RFC 7950 permitted or not? > > - This interacts with the definition of node-instance-identifier. I think it is necessary to first redefine the lexical representation of instance-identifier in YANG. > > - Options: (i) Leave this definition as it is. (ii) Detail how this > type work with encodings that use module names instead of prefixes > to qualify names. I vote for (i), as long as a general solution is probably impossible. Lada > > - Proposal: ? > > /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 -- 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
Juergen Schoenwaelder writes:
> - Percentages are frequently used in YANG models but usages differ a
> lot in precision and range. It is not clear what the proper
> generic definition of a percentage type would be and whether it is
> worth having it.
>
> RFC 7950 example:
>
> typedef percent { type uint8 { range "0 .. 100"; } }
>
> RFC 8294:
>
> typedef percentage { type uint8 { range "0..100"; } }
>
> I-Ds:
> typedef percentage { type decimal64 { fraction-digits 5; } }
> typedef percentile { type decimal64 { fraction-digits 2; } }
>
> The yang catalogue seems to be down. :-(
>
> - Proposal: do not add a percentage type since it is trivial to
> define a context specific percentage type that matches range and
> precision requirements (and there is already a definition in RFC
> 8294 for those who need exactly that definition).
I agree with this proposal. It is also possible to use
units percent;
where necessary.
Lada
>
> --
> 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
--
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
Juergen Schoenwaelder writes: > - Lada suggested to replace the inet:domain-name usage in > the union with a new host-name definition that follows > the NR-LDH definition in RFC 5890. > > - Unclear which problem is fixed and how this works from a > backwards compatibility perspective. > > - See the thread '6991bis: host' in your private list archive > (I can't find it in the IETF archive) > > - I can't tell for sure that Lada's proposal is (i) correct and (ii) > not breaking anything > > - Proposal: ? Maybe it is better to basically keep the existing inet:domain name for use e.g. in host names that appear in all kinds of non-DNS configuration, and leave the definition of a domain name type appropriate for use in DNS zone data etc. to DNSOP WG. So my proposal is to only modify the description accordingly, and in particular remove the comment about the use in A//SRV resource records, because the existing type isn't really suitable for this purpose. Lada > > -- > 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 -- 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] 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: >>> >>>> >>>> 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 (although that is hardly a proper solution) but it is not >>>>> really possible because the problem may occur whenever there is union >>>>> with a 'string' and 'int8' - 'int32', 'uint8' - 'uint32', or >>>>> 'boolean', in any order. Meaning in lots of, if not most, unions. And >>>>> I have considered only XML and JSON, I have not looked into CBOR, >>>>> which may make it even worse. >>>> What you can do is to define a metadata annotation specifying the union >>>> member for a particular instance, and implement it in your tools. This >>>> would be a solution independent of instance representation. >>> >>> >>> IMO this does not solve the problem that XML can not encode all values >>> of the value space in certain awkward unions (JSON and CBOR can't do >>> that either only the constraints are alternative supersets). >> >> Why not? In XML, everything is encoded as text, and the annotation tells >> how to parse it and interpret. So either the text representation >> conforms to that precise type or otherwise it is an error. There is no >> ambiguity. >> > > An annotation that is only understood by some tools and not by others > is creating a new problem since different tools now start to interpret > data in different ways, i.e., the annotation harms interoperability. I agree, it should eventually be standardized, if it turns out to be a good idea. But to find out, experience with running code always helps. Lada > > /js > -- 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] 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 (although that is hardly a proper solution) but it is not >>> really possible because the problem may occur whenever there is union >>> with a 'string' and 'int8' - 'int32', 'uint8' - 'uint32', or >>> 'boolean', in any order. Meaning in lots of, if not most, unions. And >>> I have considered only XML and JSON, I have not looked into CBOR, >>> which may make it even worse. >> What you can do is to define a metadata annotation specifying the union >> member for a particular instance, and implement it in your tools. This >> would be a solution independent of instance representation. > > > IMO this does not solve the problem that XML can not encode all values > of the value space in certain awkward unions (JSON and CBOR can't do > that either only the constraints are alternative supersets). Why not? In XML, everything is encoded as text, and the annotation tells how to parse it and interpret. So either the text representation conforms to that precise type or otherwise it is an error. There is no ambiguity. Lada > > If the XML representation rules in the YANG definition were provided as > an inherent constraint to the value space of the union type there was > not going to be ambiguity and there would have been a bug in any > encoding that does not enforce this exact constraint. This is not > spelled out in RFC7950 but is a good rule of thumb to avoid unions that > have value space that can not be represented in XML. > > The alternative is to rework the XML representation to not have such > limitation in a next version of YANG (e.g. adding XML attributes with > the active member type index and name). > > That said I think there is one underestimated feature of the union type > being entirely mapped to a string also for integer types as it is in the > current XML encoding definition. Without requirement for resolving which > member type the data actually is representing but just validating there > is at least one match allows implementations to encode the data without > resolving a possibly complex logical relationship. For example a union > of interface index and leafref to interface name (for whatever reason > someone would design such a union). You really do not need to know if > there is an interface named "2" in the candidate configuration when you > send in XML. With JSON you have to resolve this. > > /Vladimir > > >> >> Lada >> >>> Regards, >>> Michal >>> >>>>> In my view, if it is a bug, it is in the design of the union type >>>>> in YANG - there is no general way to signal the actual union member >>>>> type for an instance. >>>> Right. The ambiguity is normally not a problem for a type choice >>>> (which is just a union of the possible values of all types given), >>>> unless what specific alternative was chosen is intended to carry >>>> semantics. >>>> >>>>> I believe it is a good thing that some encodings allow for at least >>>>> partial signalling. >>>>> >>>>> Note that similar issues may arise even more often in CBOR, see >>>>> e.g. comments for section 5.12 in >>>>> >>>>> https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/ >>>>> >>>> In the original YANG (XML-only), everything was represented as a >>>> text string, so the ambiguity was the highest we see now. YANG-JSON >>>> and YANG-CBOR provide progressively more disambiguating information, >>>> so the interpretation (which chosen alternative) may be different >>>> from the one after converting to YANG-XML. >>>> >>>> It gets slightly worse if the non-text type has a conversion 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 of ambiguity do not cause a problem. I would be >>>> interested to know whether there is any tool support for this. >>>> >>>> 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] JSON to XML lossy conversion
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 (although that is hardly a proper solution) but it is not really > possible because the problem may occur whenever there is union with a > 'string' and 'int8' - 'int32', 'uint8' - 'uint32', or 'boolean', in any > order. Meaning in lots of, if not most, unions. And I have considered only > XML and JSON, I have not looked into CBOR, which may make it even worse. What you can do is to define a metadata annotation specifying the union member for a particular instance, and implement it in your tools. This would be a solution independent of instance representation. Lada > > Regards, > Michal > >> >>> In my view, if it is a bug, it is in the design of the union type in YANG - >>> there is no general way to signal the actual union member type for an >>> instance. >> >> Right. The ambiguity is normally not a problem for a type choice (which is >> just a union of the possible values of all types given), unless what >> specific alternative was chosen is intended to carry semantics. >> >>> I believe it is a good thing that some encodings allow for at least partial >>> signalling. >>> >>> Note that similar issues may arise even more often in CBOR, see e.g. >>> comments for section 5.12 in >>> >>> https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/ >> >> In the original YANG (XML-only), everything was represented as a text >> string, so the ambiguity was the highest we see now. YANG-JSON and >> YANG-CBOR provide progressively more disambiguating information, so the >> interpretation (which chosen alternative) may be different from the one >> after converting to YANG-XML. >> >> It gets slightly worse if the non-text type has a conversion 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 of ambiguity do not cause a problem. I would be interested >> to know whether there is any tool support for this. >> >> 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] JSON to XML lossy conversion
Hi Michal,
Michal Vaško writes:
> Hello,
> it seems that there are cases when YANG data represented in JSON include more
> information than when converted to XML. Example:
>
> YANG:
>
> module a {
> leaf l {
> type union {
> type string;
> type uint8;
> }
> }
> }
>
> JSON:
>
> {
> "a:l": 20
> }
>
> These data will be parsed as the leaf "l" of type "uint8" based on the JSON
> specs [1]. Then, when printed again
>
> XML:
>
> 20
>
> this XML would be parsed as leaf "l" of type "string".
>
> Similar problem occurs also for boolean. So I am just wondering, is this a
> known bug/feature, is it intentional? It is true that applications usually
> choose one format and stick to it but it is not a requirement and I can see
> this having possibly quite nasty consequences.
This has already been discussed several times in the past, for example in this
thread:
https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1=dqNrvzOV2Ur6RoX6rTW-ZzsV65g
In my view, if it is a bug, it is in the design of the union type in YANG -
there is no general way to signal the actual union member type for an instance.
I believe it is a good thing that some encodings allow for at least partial
signalling.
Note that similar issues may arise even more often in CBOR, see e.g. comments
for section 5.12 in
https://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/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] Justification for decimal64 over string for floating point values in geo location data?
al type through rounding or truncation.
> For example, pi could be rounded (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. This specification does not define
> rules for the rounding or truncating of such values, considering
> these decisions to be application-specific.";
> }
>
>
>
> David Spakes
>
>
>
> On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:
>
>> Mentioned in the earlier mail
>>
>> instead of
>>
>> "decimal64"
>>
>> use
>>
>> "type string { pattern '[0-9]+(\.[0-9]+)?'; }"
>>
>
>
> On Tue, 7 Jul 2020, Ladislav Lhotka wrote:
>
>> On 07. 07. 20 13:24, Juergen Schoenwaelder wrote:
>>> Precision often means different things to different people. Here is my
>>> take:
>>>
>>> - Floating point numbers have almost always rounding errors. And
>>> floating point numbers use binary fractions, a decimal fraction like
>>> 1.0 has no precise representation as a binary fraction. Type 0.1 +
>>> 0.2 into python or haskell or any other language that gives you bare
>>> floating point numbers and enjoy the result.
>>>
>>> - Fixed precision decimal numbers do not have rounding errors since
>>> they are essentially scaled integers and hence they are precise as
>>> long as calculations stay within the range.
>>>
>>> - Floating point numbers can cover a large number space (from very
>>> tiny to really big), fixed precision decimal numbers are much more
>>> restrictive.
>>>
>>> - In XML and JSON, numbers are rendered in strings that likely do not
>>> look much different if its a decimal64 or a float or ... If you really
>>> care about size, use a binary encoding like CBOR.
>>
>> I know nothing about geo-location formats, but I suspect that the string
>> representation is based on some assumptions regarding the underlying
>> numeric type. So one option might be to define a new type derived from
>> "string", and specify these assumptions in the description.
>>
>> Lada
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>
>
> -
> David Spakes email: spa...@snmp.com
> SNMP Research voice: +1 865 573 1434
> 3001 Kimberlin Heights Road fax: +1 865 573 9197
> Knoxville, TN 37920-9716 USA http://www.snmp.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/mailman/listinfo/netmod
Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?
On 07. 07. 20 15:57, Juergen Schoenwaelder wrote: > On Tue, Jul 07, 2020 at 09:24:31AM -0400, Christian Hopps wrote: >> >> I dislike having to specify arbitrary limits b/c of the type. I think it >> would be useful to have integer and real number support that allowed for >> specifying "at least" precision, but not forcing the model to specify an "at >> most". >> > > You can have defined limits or undefined limits with implementation > specific limits (only rarely you find implementations that de-facto > have no limits). > >> In generally I dislike many of the specified semantic restrictions I >> find in YANG models, they seem to be the most oft-cited examples of >> when a "backward incompatible" change might need to be made to a >> model. > > ASN.1 had INTEGER, a type of unlimited precision. In the early SNMP > days things started to fail to interoperate when you hit the 16-bit > limit. JSON (much newer) has numbers that start to become interesting > when you need more precision, a simple 64-bit counter starts falls > apart in JSON. 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 > -- 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] Justification for decimal64 over string for floating point values in geo location data?
On 07. 07. 20 13:24, Juergen Schoenwaelder wrote: > Precision often means different things to different people. Here is my > take: > > - Floating point numbers have almost always rounding errors. And > floating point numbers use binary fractions, a decimal fraction like > 1.0 has no precise representation as a binary fraction. Type 0.1 + > 0.2 into python or haskell or any other language that gives you bare > floating point numbers and enjoy the result. > > - Fixed precision decimal numbers do not have rounding errors since > they are essentially scaled integers and hence they are precise as > long as calculations stay within the range. > > - Floating point numbers can cover a large number space (from very > tiny to really big), fixed precision decimal numbers are much more > restrictive. > > - In XML and JSON, numbers are rendered in strings that likely do not > look much different if its a decimal64 or a float or ... If you really > care about size, use a binary encoding like CBOR. I know nothing about geo-location formats, but I suspect that the string representation is based on some assumptions regarding the underlying numeric type. So one option might be to define a new type derived from "string", and specify these assumptions in the description. Lada > > /js > > On Tue, Jul 07, 2020 at 07:06:20AM -0400, Christian Hopps wrote: >> I received feedback in my YANG doctor review (thanks Mahesh) regarding the >> use of decimal64 for most of the values in the geo location grouping >> (https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my >> comparison sections I note that some precision (at the very extremes) may be >> lost when converting from other geo location formats that use string (or >> double for w3c) to decimal64. Given that mention of loss of extreme >> precision, the reviewer was asking if some justification for the decimal64 >> should be given in the document. >> >> What are the advantages to using decimal64 for floating point numbers vs >> using a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang >> pattern language). The advantage of using a string is that the precision of >> the value is not restricted by the model. Does the YANG decimal64 values >> have a concise binary format that can be more efficiently transported or >> stored in binary form? If so is this the only advantage, and is it enough of >> one to limit the precision in the model? >> >> It's definitely worth noting that the precision of the decimal64 values seem >> vastly adequate for geo location data (e.g., for Cartesian coordinates and >> height values which are measured in meters the fractional digits is 6 which >> means the 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. > > > >> ___ >> 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
[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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
t; > > }
> > > > > > > }
> > > > > > >
> > > > > > > typedef b {
> > > > > > > type a {
> > > > > > > require-instance false;
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > might be illegal since b has a larger value space than a.
> > > > > >
> > > > > > The value space of b is the same as for a. "require-instance"
> > > > > > doesn't
> > > > > > change the value space; it changes semantic validation of the given
> > > > > > values ((see my mail from 17 Mar, "Require-instance problem").
> > > > > >
> > > > > > /martin
> > > > >
> > > > > 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 ?
On Sat, 2020-03-21 at 14:56 +, Balázs Lengyel wrote: > Hello Kent, > First is very handy and easier to use then xmllint. > Also some people (not me) are writing RFCs without XML. SO if it acceptable to > you, the RFC editor to whoever I will use for the examples. Is that > acceptable? Note that according to Legal Provisions Relating to IETF Documents [1], the ... tags demarcate "Code Components", so the license provisions specified in that document apply. Lada [1] https://trustee.ietf.org/license-info/IETF-TLP-5.htm > > Folding: > Rfcfold folds the line at a fixed 69 character length. This produces some not > so nice results: > Rfcfold: > > > > Manual folding: > > xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> > > The manual folding can keep a nice tabulation and fold the line at a word or > element boundary. I know such editorial niceties are very hard to program in a > script; but this is one reason to do manual folding. > > I used rfcfold to unfold the acme-router-modules example and I don’t notice > anything strange. > Regards Balazs > > From: Kent Watsen > Sent: 2020. március 21., szombat 0:01 > To: Balázs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] CODE BEGINS ENDS for examples ? > > Hi Balazs, > > As I understand it, the blocks are not appropriate for > examples. > > Examples are easily extracted from XML via `xmllint` with the “—xpath” > parameter, after which the `rfcfold` script can be run. Strongly recommend > setting the “name” attribute on the or element in the > XML draft. It’s good to see that you want to do it this way, as I noticed you > hand-folded the examples and I’m pretty sure I spotted what looked like might > result in an undesirable unfolding artifact... > > FWIW, https://pypi.org/project/xiax attempts to do all this, but I suspended > that effort getting distracted with other things... > > Kent // contributor > > > > > > On Mar 20, 2020, at 1:02 PM, Balázs Lengyel < > > balazs.lengyel=40ericsson@dmarc.ietf.org> wrote: > > > > Hello, > > Is it allowed/recommended to use around examples. > > In my case it would be examples of XML and JSON instance data. I would find > > it rather useful. > > > > As a second step if someone could combine rfcstrip with artwork-unfolding > > that would be even better. > > Regards Balazs > > > > -- > > Balazs LengyelSenior Specialist > > Ericsson Hungary Ltd. > > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com > > > > _______ > > 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] Adoption of versioning design team docs
I support the adoption of the entire document set. Lada Lou Berger writes: > Hi, > We'd like to start a two week adoption call for the set of documents > described below by Rob. To be specific, this includes > 1) draft-verdt-netmod-yang-solutions-03 > 2) draft-verdt-netmod-yang-module-versioning-01 > 3) draft-verdt-netmod-yang-semver-01 > 4) draft-rwilton-netmod-yang-packages-03 > 5) draft-wilton-netmod-yang-ver-selection-02 > 6) draft-verdt-netmod-yang-schema-comparison-00 > > The adoption call ends in two weeks, on March 16. > > Please voice your support or objections on list. While we prefer to adopt as > a set, objections on specific documents are acceptable. > > Netmod Chairs > > On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote: > >> Netmod chairs, >> >> The version selection draft draft-wilton-netmod-yang-ver-selection-02 is now >> posted. With that, the YANG versioning design team would like to please >> request you make an WG adoption call for these documents. >> >> The updated full list is: >> >> 1) draft-verdt-netmod-yang-solutions-03 >>- Solution overview, updated since 106 to cover updates to version >> selection and schema comparison drafts. >> >> 2) draft-verdt-netmod-yang-module-versioning-01 >>- Base module versioning solution, unchanged from the version presented >> at 106. >> >> 3) draft-verdt-netmod-yang-semver-01 >>- YANG Semantic version numbers, unchanged from the version presented at >> 106. >> >> 4) draft-rwilton-netmod-yang-packages-03 >>- YANG packages draft, updated since 106 >> >> 5) draft-wilton-netmod-yang-ver-selection-02 >>- Version selection, updated since 106, as per notes below >> >> 6) draft-verdt-netmod-yang-schema-comparison-00 >>- Schema comparison tooling, unchanged from the version presented at 106. >> >> The main changes to the version selection draft are: >>- We have tried to simplify the model, but at the same time give servers >> more flexibility about how they implement version selection and what it can >> be used for. E.g. if the server wants to allow a client to choose between >> different schema versions, 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 >>- The solution provides more information about which schema-sets are >> compatible with each other >> >> Regards, >> 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] Text in import to indicate whether a module is needed as import-only or as implemented
On Mon, 2020-03-02 at 09:52 -0800, Andy Bierman wrote: > > > On Mon, Mar 2, 2020 at 8:57 AM Benoit Claise wrote: > > Sorry to resurrect this old email thread. > > To me, it's an important piece of information to know that ietf-netconf-acm > > is optional to implement. > > > > It seems that we have 3 potential places where to insert this information > > 1. The associated document. We could and should insert it into the RFC text. > > Drawback: Somehow the YANG module is looked at independently of the > > associated document > > 2. import-stmt: people on the list apparently don't like this > > 3. module description? What harm would it do if the description could > > contain this info? > > > > > > IMO it makes more sense to summarize the imported modules that need to be > implemented > and not mention the ones that are not required. The module description-stmt > is better > than each import. (YANG 1.1 allows the same module to be imported multiple > times). Modules that have to be implemented can be imported only once. Adding this information to the import statement 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: > > > > On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote: > > > > > > > > > > On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka wrote: > > > > > > On Tue, 2020-01-07 at 14:29 +, Balázs Lengyel wrote: > > > > > > > If that is the consensus, I can remove the description statements, > > > > no big > > > > > > > deal. (I actually like the statements, but they are not important > > > > for this > > > > > > > draft) > > > > > > > > > > > > Of course, it is not that important, but I don't see how this > > > > information > > > > > > could > > > > > > be harmful, if it is included with the import. In my view, it is not > > > > meant > > > > > > as a > > > > > > conformance requirement but just an info from the module author > > > > about the > > > > > > meaning of the import statement. > > > > > > > > > > > > > > > > It adds a lot of extra work but more importantly the import-stmt is > > > > the wrong > > > > > place > > > > > > > > What work do you mean? I thought that it would be just info for > > > > potential > > > > developers (or their managers) that implementing the module requires > > > > implementing other modules and functionality - or not. > > > > > > > > > > > > > > > > > It is duplication because the individual data-def statements should have > > > any notes > > > about implementation requirements. The duplication may even be wrong. > > > E.g., in the module it says NACM is not required, but what if some objects > > > have NACM requirements listed in the Security Considerations section? > > > That is the RFC section to discuss NACM requirements. > > > > > > > > > > For example, if a module imports ietf-netconf-nacm only for using "node- > > > > instance-identifier" type, it is relatively uninteresting. Otherwise, > > > > implementation of the module may just be out of question. > > > > > > > > > > > > > to document such a complex and unrelated issue as server conformance > > > > > requirements. > > > > > > > > > > > > > > > > The root of this problem (and design flaw of YANG, IMO) is that > > > > import is > > > > > > "overloaded" with two different purposes, one of which effectively > > > > requires > > > > > > that > > > > > > the imported module be also implemented, while the other doesn't. > > > > > > > > > > > > > > > > The import-stmt is only used to map a local prefix to an external > > > > module. > > > > > > > > But one thing is using a prefix for accessing top-level types and > > > > groupings > > > > (i.e. stuff in YANG modules), and another thing is accessing schema > > > > nodes, which > > &
