Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format
On Fri, Jul 09, 2021 at 08:57:34AM +, tom petch wrote: > From: netmod on behalf of Juergen Schoenwaelder > > Sent: 08 July 2021 11:13 > > On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote: > > It is perhaps worth noting that the NETCONF copy-config allows for the > > configuration to be specified using any URI, but the server capabilities > > announce which URI schemes are supported. > > > > Hence, I think that it is okay for the YANG model to use URI, but I think > > the draft, and data node description should constrain the URI schemes that > > allowed (perhaps file:// and https://). This would allow support for > > future URI schemes to be added in a future revision of the YANG instance > > data module, if required. > > > > I think it is not "allowed" but "mandatory to implement". We should > allow implementations to support an ftps:// scheme as long as there > is a common baseline. > > > I am confused. Is ftps: intended to be an existing scheme or a hypothetical > one that may appear in the future. I do not see it in the IANA registry > https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1 > > sftp: appears as a provisional entry in the IANA registry but AFACT did not > get specified. I recall a debate about ftps: v sftp: I favoured the former > but lost but then I did not see any further work on either. > I used 'ftps:' as an example, I should have taken the time to find RFC 4395 and then I should have picked 'example:'. /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
Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format
On Fri, Jul 09, 2021 at 09:10:34AM +, Rob Wilton (rwilton) wrote: > > "YANG modules that are only required to satisfy import-only dependencies MAY > be excluded from the leaf-list. If they are excluded then the consumer of > the instance data file can choose any versions of the YANG modules that > satisfy the import dependency." > Sorry, this wording is a bit wrong or possibly misleading. I assume your intention was this: OLD: If they are excluded then the consumer of the instance data file can choose any versions of the YANG modules that satisfy the import dependency. NEW: If they are excluded then the consumer of the instance data file has to apply the YANG language rules to resolve the imports. /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
Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format
On Thu, Jul 08, 2021 at 10:58:37AM +, Rob Wilton (rwilton) wrote: > Hi Juergen, > > I believe that having the simple form is worth the extra complexity. > > I think that you are right to be concerned that it should not expand into a > separate parallel format. Overtime, I would like the simple form to be able > to use revision labels instead of revision dates, but beyond this I think > that it should just be a flat list of modules that defines the schema. If a > subset of features, or datastores, or import-only modules are needed then the > YANG library version (or URIs) can and should be used. > A tool that does something useful, such as checking an instance file against a schema, likely needs to have more information than just a module name with a revision identifier to do the job well. Anyway, if people feel strongly that this optimization is essential, I will shut up and watch what happens to this over time. ;-) > Another example of where I expect it to be useful is in YANG packages. > Looking at the examples at the end of > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then > some of those files (which currently aren't defining any schema, but should) > would almost double in size if they represented the schema inline using YANG > library, which I think would make the files harder for humans to read/parse. > Using URIs could help mitigate this, but then we would need to find a place > to publish the file containing the YANG package schema (presumably somewhere > in IANA), and it not obvious to me that adding the dependency on the URL is > really as helpful. Once there are YANG packages and there is a new way to describe a schema, you likely want to augment in a new choice. So I am not convinced by this argument. /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
Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format
The question I asked is "how much simpler is it and does that saving justify the introduction of a new rather limited format (that may risk to grow over time and become a second citizen)". So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports from ietf-yang-types (at the time of publication that resolves to ietf-yang-types@2013-07-15. So the YANG Library instance data would roughly look this (please correct what I messed up, I am writing this by hand): m ietf-netconf-acm 2018-02-14 uri1 ietf-yang-types uri2 s m running s Yes, this is a bit longer, but it also conveys more information (note that your datastore leaf in the header would likely not be needed anymore). I am concerned that we start creating another format to define schemas that is very limited and people later come with extension proposals to address some of the limits and at the end we have multiple formats to maintain and deal with. So the question is whether people think this is worth it. (Note that the felt overhead goes down with every additional module used by your instance file, so the example above is really the most extreme case. And if you have many modules defining NACM rules, then you put the above into a separate file and use the URI to point to the schema, no? /js On Thu, Jul 08, 2021 at 09:27:52AM +, Balázs Lengyel wrote: > Hello Jurgen, > Inline: > This complex form of inline was requested and not objected earlier by other > reviewers. > Based on Rob's and others' proposal inline will be simplified to use only > ietf-yang-library@2019-01-04 as you suggest. > > Simplified inline: > In Ericsson we already use simplified inline a lot, it is the most common > format. > If you are providing data only for one or a few YANG modules and don't have, > > don't care about features/deviations it is the easiest, shortest method to > use. > Our most common use-case is to provide preconfigured access control rules > for new nodes. > When a YANG modeler designs a new module, he immediately provides a set of > NACM rules > for the readOnly and the SystemAdmin roles/groups. > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No > deviations, no features to indicate. > Regards Balazs > > Regards Balazs > > -Original Message- > From: Juergen Schoenwaelder > Sent: 2021. július 7., szerda 21:26 > To: Andy Bierman > Cc: Balázs Lengyel ; Rob Wilton (rwilton) > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > Inline method is needed, if you want to indicate that the file was > > > generated by someone who uses some YANG modules with deviations and > > > some features are not-supported. There is no way to indicate > > > feature-support and deviations with the simplified-inline method. > > > > The Inline anydata solution is very heavyweight. > > Before the YANG library there was a simple URI that is easier to use > > and takes up much less storage. > > > > The inline content schema is super generic since it supports an open ended > set of schema defining modules. While you can use it with say > ietf-yang-library@2019-01-04, you can use anything else as well. In other > words, two implementations supporting inline content schema may not > interoperate. I do not think there is a schema format that is mandatory to > implement for inline content schema. > > So here is my assessment of what we have in terms of interoperability: > > - Simplified-Inline comes with notable restrictions, interoperable > - Inline is an open ended content schema, not necessarily interoperable > - URI method pushes the problem to another instance file, interoperable > - External is by desing not interoperable > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > complexity that is useful for supporting large servers with multiple > datastores and not needed for small instance files (I understand that an > instance file is always tied to a single datastore?). > > To me, it feels that reusing RFC 8525 design is actually a good thing. Being > able to dump a live server datastore into an instance file seems like a very > valid use case to me and ideally this is possible without having to rewrite > the schema part. Well, you could go and trim unused datastore schemas and > from there unused module sets etc but that can all be done by an external > tool trimming the schema part, i.e., it does not need to be done by a tool > that just dumps a server datastore. > > What is the actual value
Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format
On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote: > It is perhaps worth noting that the NETCONF copy-config allows for the > configuration to be specified using any URI, but the server capabilities > announce which URI schemes are supported. > > Hence, I think that it is okay for the YANG model to use URI, but I think the > draft, and data node description should constrain the URI schemes that > allowed (perhaps file:// and https://). This would allow support for future > URI schemes to be added in a future revision of the YANG instance data > module, if required. > I think it is not "allowed" but "mandatory to implement". We should allow implementations to support an ftps:// scheme as long as there is a common baseline. /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
Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format
On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > IMO the 4 separate ways to identify the schema are 3 too many, but that > is what the WG wants. It seems obvious that any reader of the file > has to implement all 4 methods and any writer of the file is free to pick > just one. > So the feature does not really help. > The feature statements declare that implementation won't work together. Back in a day, the IETF was all about interoperability (and implementation costs). Nowadays we seem to be fine if implementations declare that they won't work together. Well, still slightly better than having implementations fail arbitrarity. /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
Re: [netmod] comments on draft-ietf-netmod-yang-module-versioning-02
On Wed, Jun 30, 2021 at 02:57:46PM -0700, Andy Bierman wrote: > > The only extension that is really useful is "revision-or-derived". > But I agree with all the concerns originally raised by Martin wrt/ > this should be a real-statement instead of an extension. > This is the way import-by-revision should have worked from the start. > > The draft contains some reasonable updates to YANG and YANG Guidelines > wrt/ updating a module.. They would be appropriate for a new YANG language > version. > +1 /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
Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?
On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote: > > Juergen Schoenwaelder wrote: > >> Juergen Schoenwaelder wrote: > >> > Note that there is also a middle ground, namely an enumeration type > >> > factored out into an IANA maintained module that is process wise > easier > >> > to extend - should extensions be needed more regularly. > >> > >> That would suit me. How do we do that? > >> > > > You revise RFC 8366 and do the following: > > > - You define an IANA maintained module defining the enumeration type. > > This is the part that I don't know to do. > https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6 > says nothing about IANA. Is RFC7224 the model for this? > > What document am I missing here? Yes, RFC 7224 defining the iana-if-type module may serve as a template. There are a couple of IANA maintained YANG modules, I am not sure whether we have a good place listing them all. Well, you can filter out the iana- modules from this list: https://www.iana.org/assignments/yang-parameters/ /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
Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?
On Mon, Jun 28, 2021 at 12:04:46PM -0400, Michael Richardson wrote: > > Juergen Schoenwaelder wrote: > > Note that there is also a middle ground, namely an enumeration type > > factored out into an IANA maintained module that is process wise easier > > to extend - should extensions be needed more regularly. > > That would suit me. How do we do that? > You revise RFC 8366 and do the following: - You define an IANA maintained module defining the enumeration type. - You write IANA considerations for the new module. - You modify the existing module to import and use the enumeration type. - You do not make any modifications to the existing enumerations. - You republish the revised version of RFC 8366. A couple of month later (and after surviving all the reviews), you declare success. I fear there is nothing "cheaper". /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
Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?
On Mon, Jun 28, 2021 at 11:54:04AM +, tom petch wrote: [...] > As you say, this is never going to be an Erratum. Yep. > A leaf of type empty is encoded as, well, empty. > > as per RFC 7950. > > When this concept was first mentioned, my sense was that while it was > technically possible, it would still add complexity for little gain. As I > see YANG Doctors for ever saying, identity can be augmented, enumeration can > not so enumeration are used when you positively want to stop people > augmenting, when the concept does not make sense so a revised enum may make > sense or a change to something like identity which I see as as big a change > as the use of 'empty' but the latter is not in current use and so may cause > some uncertainty, some confusion. > Enumerations are centrally managed. Section 11 of RFC 7950 does allow additions to enums but only where the enum itself is defined, i.e., you need to create a new revision of the YANG module to add an enum value. An identity is more flexible as the value space is not centrally managed. Using leafs of type as a way to define a non-centrally managed enumerated set of values really is a hack. It may work if people follow certain rules, but it is unlikely that tools will understand the rules (i.e., which places of a data model were designed to be used as a 'leafs of type enumeration'). Hence, there is nothing that will prevents people from augmenting in a leaf that is not using the type empty or even an entire subtree of YANG definitions. I do not know exactly what the issue with RFC 8366 is but it seems you will have to revise the YANG module defined in RFC 8366 anyway. Note that there is also a middle ground, namely an enumeration type factored out into an IANA maintained module that is process wise easier to extend - should extensions be needed more regularly. /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
Re: [netmod] YANG revision dates unique in module ?
The assumption back then was indeed that an organization would not _publish_ two revisions on the same date. Note the choice of the verb 'publish', which is not to be confused with edits made during development, at least back then we made this distinction between module development and module publication. /js On Tue, Jun 01, 2021 at 01:36:09PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > In our YANG versioning work we are proposing that a revision-label is unique > and the revision history of a module must not contain the same revision-label > twice. > > We're debating whether we should state the same rule for revision *date* as > well. > > RFC7950 doesn't seem to explicitly say that revision date must not be > duplicated in the revision history. > > This issue came up recently in an OpenConfig discussion here: > Updates to OpenConfig types modules. * openconfig/public@f20ed84 > (github.com)<https://github.com/openconfig/public/commit/f20ed8411a6fc1f55c9debed55c852ea4ffef5bb#commitcomment-51076470> > > Was it the intention of RFC7950 that a revision history should never have the > same revision date twice ? > > I think it is somewhat inferred from various drafts that describe how a > module name + revision date uniquely identifies a module revision. But it > doesn't seem to be explicitly stated in RFC7950. > > If we disallow duplicate revision dates, that makes the module-name+date > tuple unique, but it does mean that authors can't produce 2 versions of a > module in the same day. In theory we *could* do something like this: > - require unique revision-labels > - allow duplicate revision dates > > But in that case, only the module-name+revision-label can be the unique > identifier for a revision. > > Jason > > _______ > 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
Re: [netmod] I-D Action: draft-lear-opsawg-ol-01.txt
Hi,
I have not followed the discussion but skimming through the document,
I felt that calling a grouping an extension is somewhat confusing
since YANG also has extensions that are a very different thing
(i.e. we get a clash between a MUD and YANG extensions). Perhaps more
careful wording can help. In the YANG definitions, I would rather
avoid using 'extension'.
OLD
grouping ol-extension {
description
"OL extension grouping";
NEW
grouping owner-licence-grouping {
description
"A grouping expression ownership and license information";
Whether 'ol' makes a good container name can be discussed.
Whether allowing multiple owners all sharing a single license is
appropriate I do not know; in the open source world there are
occasionally projects that can be used with different licenses
(perhaps making this just a list of (owner, spdx-tag, license-info)
instead of a leaf-list of owners with exactly one spdx-tag and
license-info would be more flexible. I am also not sure that using an
'owner' leaf to contain a copyright statement is what I would have
expected to be an 'owner' (i.e., a person or legal entity).
/js
On Thu, May 27, 2021 at 06:21:44AM -0700, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : Ownership and licensing statements in YANG
> Authors : Eliot Lear
> Carsten Bormann
> Filename: draft-lear-opsawg-ol-01.txt
> Pages : 7
> Date: 2021-05-27
>
> Abstract:
>This memo provides for an extension to RFC 8520 that allows MUD file
>authors to specify ownership and licensing of MUD files themselves.
>This memo updates RFC 8520. However, it can also be used for
>purposes outside of MUD, and the grouping is structured as such.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-lear-opsawg-ol/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-lear-opsawg-ol-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-lear-opsawg-ol-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--
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
Re: [netmod] GDPR and private data
GDPR uses the term 'personal data' and I assume for many leafs in a
data model the answer whether a leaf is 'personal data' is not simple
to answer given that also data items belong to 'personal data' if they
combined with other information can identify a natural person.
For example, is an IPv6 prefix 'personal data'? Well, it depends...
‘personal data’ means any information relating to an identified or
identifiable natural person (‘data subject’); an identifiable
natural person is one who can be identified, directly or indirectly,
in particular by reference to an identifier such as a name, an
identification number, location data, an online identifier or to one
or more factors specific to the physical, physiological, genetic,
mental, economic, cultural or social identity of that natural
person;
Another possible question is whether the act of tagging (or not
tagging) leafs in a data model has a legal liability component at the
if the processing of data depends on such tags. Well, that surely
depends on what the presence of such a tag implies, does such a tag
control access to data on a NC/RC server (nacm:default-deny-all), does
it control storage of data outside a NC/RC server, does it control
processing of data outside a NC/RC server?
What you need I think are context (deployment) specific tags, static
data model tags likely only work for the (obvious) trivial cases and
may mislead people to be GDPR compliant while they are not.
/js
On Wed, May 26, 2021 at 09:49:32AM +, Balázs Lengyel wrote:
> Hello,
>
> Netconf/Restconf can transfer a lot of data. Some of this data can be
> personal/private like end-user names, personal phone records, street
> addresses. Is there a way to marks such data as private? I am thinking about
> something like putting a YANG extension in the data models:
>
>
>
> extension private-data {
>
> description
>
> "Indicates that a leaf or leaf-list contains private data.
>
> argument privacy-type;
>
> }
>
>
>
> Is there any standard solution for this or any proposal ? In the world of
> GDPR we should be thinking about this.
>
>
>
> 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
--
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
Re: [netmod] Typedefs for bandwidth
I assume it is best to settle this in teas. Form a programmatic point of view, you likely want to have a single unit. Even if you go for bps (bits per second), a uint64 still allows you to express quite big data rates (I think 16777216 terra bits per second but please check yourself). From a human point of view, having a notation that supports different units may be desirable. But if you have multiple representations, this surely increases implementation cost and it gets you into answer questions whether there should be a canonical format or a way to decide which unit is selected. Writing constraints in when or must statements will also become much more fun. Whether you really need the range of a floating point number, I can't tell. Perhaps check what the realistic smallest and biggest bandwidth is that you need to represent. Generally, floating point numbers seem to be a no-brainer for management application writers but I have been told that they are less frequently found in line cards or OS kernels. /js On Fri, May 14, 2021 at 10:08:00AM +, Italo Busi wrote: > Reshad, Juergen, > > Actually, there is some on-going discussion within TEAS because some packet > technology-specific YANG modules are not using the bandwidth-ieee-float32 but > prefers using some uint type: > > https://github.com/tsaad-dev/te/issues/116 > > The ietf-te-packet-types already defines bandwidth-kbps, bandwidth-mbps and > bandwidth-gbps but during the discussion of this open issue it was pointed > out that it would be desirable to specify both the bandwidth and the units > (Kbps/Mbps/Gbps) > > Italo > > > -Original Message- > > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] > > Sent: giovedì 13 maggio 2021 19:25 > > To: Reshad Rahman > > Cc: 'netmod@ietf.org' > > Subject: Re: [netmod] Typedefs for bandwidth > > > > On Thu, May 13, 2021 at 11:57:26AM -0400, Reshad Rahman wrote: > > > Hi, > > > > > > > > > > > > Has there been any discussions wrt adding new bandwidth types e.g. the > > bandwidth-xxx types in draft-ietf-teas-yang-te-types? I see RFC8294 has > > bandwidth-ieee-float32 but it doesn’t have units (Kbps/Mbps/Gbps). > > > > > > > The description of bandwidth-ieee-float32 says: > > > > The units are octets per second. > > > > Note that draft-ietf-teas-yang-te-types has been published as RFC 8776 in > > June > > 2020, it should be safe to use these definitions. > > > > /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 https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Typedefs for bandwidth
On Thu, May 13, 2021 at 11:57:26AM -0400, Reshad Rahman wrote: > Hi, > > > > Has there been any discussions wrt adding new bandwidth types e.g. the > bandwidth-xxx types in draft-ietf-teas-yang-te-types? I see RFC8294 has > bandwidth-ieee-float32 but it doesn’t have units (Kbps/Mbps/Gbps). > The description of bandwidth-ieee-float32 says: The units are octets per second. Note that draft-ietf-teas-yang-te-types has been published as RFC 8776 in June 2020, it should be safe to use these definitions. /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
Re: [netmod] inet:ipv4-address
The zone identifiers you find in practice are either numeric (interface indexes) or symbolic interface names, this is also stated in the description. The zone index is used to disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index number or the name of an interface. If the zone index is not present, the default zone of the device will be used. in other words, its 'not usually very long' but there is not concrete restriction. Note that the interface name leaf in RFC 8343 also has no restriction. /js On Mon, May 10, 2021 at 02:02:01PM +, Don Fedyk wrote: > Thanks - In DetNet we have an ID in progress we should change from type > inet:ip-address to inet:ip-address-no-zone. I did not know that. > > My other thought is since the ipv4-address (with the zone) is of format > "127.1.1.0%AndAUnterminatedString..", shouldn't every use of ipv4-address > type also have a maximum length restriction? - If not - what controls the > Maximum length? It is good practice to have maximums on input strings and I > have come across xml validation rules that require exceptions for long > strings - and the definition long is not usually very long. > > Thanks > Don > > -Original Message- > From: netmod On Behalf Of Christian Hopps > Sent: Monday, May 10, 2021 2:46 AM > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] inet:ipv4-address > > > Well you were right, ipv4-address is used all over the place and it probably > shouldn't have been. Chalk another one up to sticking to the rules even when > it harms us. > > Thanks, > Chris. > > Ladislav Lhotka writes: > > > 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%22 > > draft-schoenw-netmod-rfc6021-bis-01%20(20130204)%22 > > > > * > > https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1=gcMx6c-NF > > t2UCbtBFi7BsUWf0EU > > > > 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 > > ___ > 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 -- 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
Re: [netmod] Compatibility of config=false data
RFC 7950 section 8: Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines. o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on state data, it MUST be true in a valid state data tree. The main difference between configuration data and state data is that a server can keep the configuration data in a valid state by rejecting any changes that make the configuration data invalid. If, however, a server reports an invalid state data tree, then obviously the server did choose to do so and the clients may have to deal with it (which includes the option of the client to reject all state data since it is invalid, but that might not always be the best or most desirable option). If there is a mandatory state leaf that the server can't implement, what should the server do? The worst of all possible solutions is to report a fake leaf. This has happened quite a bit in the history of SNMP and this is really really bad. Instead of reporting fake values, it is far better to not report the leaf so that the deviation is clear. Ideally, the server formally declare the deviation and all is good. When the NMDA document was put together, the intention was to say that we want the state data to be as close as possible to the ground truth and we rather do not want systems to report fake leafs. /js On Wed, Apr 21, 2021 at 08:45:02AM +, Balázs Lengyel wrote: > Hello Andy, > > While NMDA states “it is possible that constraints MAY be violated under some > circumstances” > > * this was never declared for non-NMDA systems, so IMHO a client can > reasonably assume that if mandatory=true for a config=false node was declared > the reason is that it will always be present; otherwise it should simply be > mandatory=false. > * IMHO this allowance for the operational datastore is for extra-ordinary > situations. In the normal case as defined in the NMDA-RFC“ > SHOULD conform to any constraints specified”. > > > > Regards Balazs > > > > From: Andy Bierman > Sent: 2021. április 20., kedd 20:21 > To: Juergen Schoenwaelder ; Balázs > Lengyel ; Sterne, Jason (Nokia - CA/Ottawa) > ; Andy Bierman ; netmod@ietf.org > Subject: Re: Compatibility of config=false data > > > > > > > > On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder > <mailto:j.schoenwael...@jacobs-university.de> > wrote: > > My understanding is that a returns the leafs that exist and that > are not filtered. > > > > Yes -- this is what clients expect. > > It is not clear that real client apps rely too much on YANG validation of > > the config=false nodes in . > > > > The validation of server provided monitoring data was not a focus of YANG. > > It may not be valid to assume every sentence that applies to config=true > > also applies to config=false. > > > > Even the NMDA RFC ignores YANG validation of config=false nodes. > > There is a paragraph that says it SHOULD be done, but it really refers > > to how operational values of config=true MAY not pass validation. > > > > > > /js > > > > Andy > > > > > On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote: > > Hello Juergen, > > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: > > > > If "mandatory" is "true", the behavior of the constraint depends on > >the type of the leaf's closest ancestor node in the schema tree that > >is not a non-presence container (see Section 7.5.1): > >o If no such ancestor exists in the schema tree, the leaf MUST > > exist. > >o Otherwise, if this ancestor is a case node, the leaf MUST exist if > > any node from the case exists in the data tree. > >o Otherwise, the leaf MUST exist if the ancestor node exists in the > > data tree. > > > > Let's take the simplest example a top level leaf. If it is mandatory=true -> > > the leaf MUST exist. The above statements do not differentiate between > > config=true or config=false leaves. > > > > If the leaf exists, for me, it is trivial that the reply to a get/get-data > > operation MUST return it. (assuming it is not filtered out) > > Anything else would be counter-intuitive and IMHO contradict RFC 7950. > > > > Do you agree? > > If not, could you please describe what does a mandatory=true statement mean > > for a config=false leaf in your interpretation? > > > > --
Re: [netmod] Compatibility of config=false data
My understanding is that a returns the leafs that exist and that are not filtered. /js On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote: > Hello Juergen, > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: > > If "mandatory" is "true", the behavior of the constraint depends on >the type of the leaf's closest ancestor node in the schema tree that >is not a non-presence container (see Section 7.5.1): >o If no such ancestor exists in the schema tree, the leaf MUST > exist. >o Otherwise, if this ancestor is a case node, the leaf MUST exist if > any node from the case exists in the data tree. >o Otherwise, the leaf MUST exist if the ancestor node exists in the > data tree. > > Let's take the simplest example a top level leaf. If it is mandatory=true -> > the leaf MUST exist. The above statements do not differentiate between > config=true or config=false leaves. > > If the leaf exists, for me, it is trivial that the reply to a get/get-data > operation MUST return it. (assuming it is not filtered out) > Anything else would be counter-intuitive and IMHO contradict RFC 7950. > > Do you agree? > If not, could you please describe what does a mandatory=true statement mean > for a config=false leaf in your interpretation? > > ------- > IMHO we never stated that > > > Regards Balazs > > -Original Message- > From: Juergen Schoenwaelder > Sent: 2021. április 14., szerda 17:08 > To: Balázs Lengyel > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; Andy Bierman > ; netmod@ietf.org > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote: > > > * On the other hand, changing a state leaf from mandatory false to > true means always including the leaf in a response. > > Where do you get this from? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > <https://protect2.fireeye.com/v1/url?k=9e758f86-c1eeb764-9e75cf1d-86073b36ea > 28-0d304a28a3dae2f9=1=81180de4-8958-40ba-aeb8-c689e3da33e8=https%3A%2F > %2Fwww.jacobs-university.de%2F> -- 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
Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13
On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote: > * On the other hand, changing a state leaf from mandatory false to true > means always including the leaf in a response. Where do you get this from? /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
Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]
Creating lots of special rules makes me feel uncomfortable. Is there evidence that people reduce state value spaces a lot and in isolation, i.e., they just rev a module to reduce some state value spaces? /js On Fri, Apr 09, 2021 at 02:00:42PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > The key focus here is *if* the author does remove the enum, then how should > we label the revision -> BC or NBC ? > > RFC7950 does indeed say that is NBC. But do we actually want that for state > for: > - removing an enum > - shrinking a range > - changing a pattern in a manner that reduces the value space > > We're worried that will create too much "NBC noise" when it really in > practice won't be an issue at all for clients. Client just won't receive the > old values from the larger value space anymore. So why flag this as NBC and > make people do work to analyze it ? > > Jason > > > -Original Message- > > From: Juergen Schoenwaelder > > Sent: Friday, April 9, 2021 9:53 AM > > To: Sterne, Jason (Nokia - CA/Ottawa) > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > Weekly Call Minutes - 2021-04-06] > > > > I do not recall that removing an enum was ever an issue in > > practice. If an enum value is not used anymore, you leave the old enum > > value and it will slowly but surely not be used anymore. (An enum > > statement even has a status statement, so you can deprecate or > > obsolete enum values.) That said, if the module owner decides to > > remove the value, then this is indeed non-backwards compatible. (And > > removing an enum paves the way to reallocate the associated number, > > and be it by accident later again. I suggest people think twice > > before removing enums.) > > > > /js > > > > On Fri, Apr 09, 2021 at 01:43:09PM +, Sterne, Jason (Nokia - CA/Ottawa) > > wrote: > > > Urghh. I reversed my example. I should have said removing an enum. Let > > me reword: > > > > > > One key example is this: 7950 says that removing an enum from an > > enumeration leaf is NBC (and that applies to state). But that may not really > > be how most implementations would want to treat state. Would we really > > want to flag a module as non backwards compatible when a state leaf has an > > enum removed? Wouldn't that create a lot of unnecessary noise? > > > > > > > -Original Message- > > > > From: Juergen Schoenwaelder > > > > Sent: Friday, April 9, 2021 9:39 AM > > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > > > Weekly Call Minutes - 2021-04-06] > > > > > > > > On Fri, Apr 09, 2021 at 01:32:15PM +, Sterne, Jason (Nokia - > > CA/Ottawa) > > > > wrote: > > > > > > > > > One key example is this: 7950 says that adding another enum to an > > > > enumeration leaf is NBC (and that applies to state). But that may not > > really > > > > be how most implementations would want to treat state. Would we > > really > > > > want to flag a module as non backwards compatible when a state leaf > > gets an > > > > additional enum? Wouldn't that create a lot of unnecessary noise? > > > > > > > > I read this in RFC 7950: > > > > > > > >o An "enumeration" type may have new enums added, provided the > > old > > > > enums's values do not change. Note that inserting a new enum > > > > before an existing enum or reordering existing enums will result > > > > in new values for the existing enums, unless they have explicit > > > > values assigned to them. > > > > > > > > What do you want this to change to? > > > > > > > > /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/> -- 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
Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]
I do not recall that removing an enum was ever an issue in practice. If an enum value is not used anymore, you leave the old enum value and it will slowly but surely not be used anymore. (An enum statement even has a status statement, so you can deprecate or obsolete enum values.) That said, if the module owner decides to remove the value, then this is indeed non-backwards compatible. (And removing an enum paves the way to reallocate the associated number, and be it by accident later again. I suggest people think twice before removing enums.) /js On Fri, Apr 09, 2021 at 01:43:09PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Urghh. I reversed my example. I should have said removing an enum. Let me > reword: > > One key example is this: 7950 says that removing an enum from an enumeration > leaf is NBC (and that applies to state). But that may not really be how most > implementations would want to treat state. Would we really want to flag a > module as non backwards compatible when a state leaf has an enum removed? > Wouldn't that create a lot of unnecessary noise? > > > -Original Message- > > From: Juergen Schoenwaelder > > Sent: Friday, April 9, 2021 9:39 AM > > To: Sterne, Jason (Nokia - CA/Ottawa) > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > Weekly Call Minutes - 2021-04-06] > > > > On Fri, Apr 09, 2021 at 01:32:15PM +, Sterne, Jason (Nokia - CA/Ottawa) > > wrote: > > > > > One key example is this: 7950 says that adding another enum to an > > enumeration leaf is NBC (and that applies to state). But that may not really > > be how most implementations would want to treat state. Would we really > > want to flag a module as non backwards compatible when a state leaf gets an > > additional enum? Wouldn't that create a lot of unnecessary noise? > > > > I read this in RFC 7950: > > > >o An "enumeration" type may have new enums added, provided the old > > enums's values do not change. Note that inserting a new enum > > before an existing enum or reordering existing enums will result > > in new values for the existing enums, unless they have explicit > > values assigned to them. > > > > What do you want this to change to? > > > > /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 https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]
On Fri, Apr 09, 2021 at 01:32:15PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > One key example is this: 7950 says that adding another enum to an > enumeration leaf is NBC (and that applies to state). But that may not really > be how most implementations would want to treat state. Would we really want > to flag a module as non backwards compatible when a state leaf gets an > additional enum? Wouldn't that create a lot of unnecessary noise? I read this in RFC 7950: o An "enumeration" type may have new enums added, provided the old enums's values do not change. Note that inserting a new enum before an existing enum or reordering existing enums will result in new values for the existing enums, unless they have explicit values assigned to them. What do you want this to change to? /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
Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]
ft-ietf-netmod-yang-module-versioning-02. > > (A) > Valuespace: > - value space (with a space between the words): use 7950 meaning/definition > (remove the definition in our draft) > - make "must" its own bullet > - don't particularly address "description" > - Balazs propose updated text > > (B) > replace this: > > "an additional state leaf can easily be discarded" > > with this: > > "the presence of an unexpected state leaf is not typically a problem and may > be ignored by the client" > > (C) > replace "config=false data" in the 1st paragraph with the following (and keep > the quotes - that is how RFC8342 presents it): > "config false" data > > (D) > Lots of debate about the "client" bullets in 3.1.2. Didn't conclude. > Perhaps just summarize and say clients need to sanitize data (give examples > of data they might get, values outside range) > > ACTION: focus on reviewing section 3.1.2 > > -- > Weekly webex call details: > Meeting number (access code): 171 069 0374 > Meeting password: semver? > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70 > Tap to join from a mobile device (attendees only) > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > ___ > 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
Re: [netmod] review of state NBC rules in yang-module-versioning-02
express 'URI absent' where required. > > > > In the value set and its semantics, this type is equivalent > > to the Uri SMIv2 textual convention defined in RFC 5017."; > >reference > > "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax > > RFC 3305: Report from the Joint W3C/IETF URI Planning Interest > >Group: Uniform Resource Identifiers (URIs), URLs, > >and Uniform Resource Names (URNs): Clarifications > >and Recommendations > > RFC 5017: MIB Textual Conventions for Uniform Resource > >Identifiers (URIs)"; > > } > > > > The value space is all legal URIs, even though there is no pattern > > defined. An implementation may hook up a standard uri parser to > > objects of this type. > > > > Are we discussing a real problem here? > > > > > > > > /martin > > > > > > > > > > Jason > > > > > > > -Original Message- > > > > From: tom petch > > > > Sent: Tuesday, March 30, 2021 11:51 AM > > > > To: Sterne, Jason (Nokia - CA/Ottawa) ; > > Martin > > > > Björklund ; j.schoenwael...@jacobs-university.de > > > > Cc: netmod@ietf.org > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > versioning- > > > > 02 > > > > > > > > From: netmod on behalf of Sterne, Jason > > > > (Nokia - CA/Ottawa) > > > > Sent: 30 March 2021 13:13 > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > versioning- > > > > 02 > > > > > > > > Hi guys, > > > > > > > > The text in 7950 doesn't mention anything about semantics in the > > > > description. That is part of what made me feel it isn't accurate or > > complete. > > > > > > > > It also doesn't mention constraints like range or pattern. It only > > > > mentions > > the > > > > type. > > > > > > > > > > > > I am with Martin and Juergen on this one. You pick on two of the ten > > > > substatements for type but all are part of the definition of a type and > > > > are > > > > relevant in defining the value space; and elsewhere in the RFC, e.g. > > > > decimal64, there are explicit descriptions of the value space. Whereas > > > > if > > you > > > > take, say, uint32 what more do you need to say to describe the value > > space? > > > > > > > > Tom Petch > > > > > > > > Jason > > > > > > > > > -Original Message- > > > > > From: Martin Björklund > > > > > Sent: Tuesday, March 30, 2021 2:10 AM > > > > > To: j.schoenwael...@jacobs-university.de > > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > > > > netmod@ietf.org > > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > > > versioning- > > > > > 02 > > > > > > > > > > Juergen Schoenwaelder > > wrote: > > > > > > On Tue, Mar 30, 2021 at 01:55:18AM +, Sterne, Jason (Nokia - > > > > > CA/Ottawa) wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules for > > config > > > > > false and output data" of > > > > > https://tools.ietf.org/html/draft-ietf-netmod- > > > > > yang-module-versioning-02. > > > > > > > > > > > > > > Here are some suggestions (mostly just editorial - I agree with > > > > > > > the > > > > > general spirit of what's in here). > > > > > > > > > > > > > > (A) Valuespace > > > > > > > > > > > > > > Valuespace is defined in module versioning 02: > > > > > > >o Valuespace: The valuespace of a leaf or leaf-list is the > > > > > > > set of > > > > > > > values that the schema node may have according to the type > > > > > > > and > > > > > > > constraint statements of the YANG model. > > > > > > > > > > > > > > It seems to be a
Re: [netmod] review of state NBC rules in yang-module-versioning-02
On Tue, Mar 30, 2021 at 01:55:18AM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > I took a look at section "3.1.2 Backwards-compatibility rules for config > false and output data" of > https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. > > Here are some suggestions (mostly just editorial - I agree with the general > spirit of what's in here). > > (A) Valuespace > > Valuespace is defined in module versioning 02: >o Valuespace: The valuespace of a leaf or leaf-list is the set of > values that the schema node may have according to the type and > constraint statements of the YANG model. > > It seems to be a more complete definition than "value space" in RFC7950 > (which doesn't seem to take into account "range", "pattern", etc statements): > >o value space: For a data type; the set of values permitted by the > > data type. For a leaf or leaf-list instance; the value space of > > its data type. > > Should we mention that this definition replaces/supercedes that of 7950 (at > least for the scope of the module versioning doc) ? Please no. RFC 7950 says data type and for me this includes everything that defines a type, including the semantics carried in the type's description statement. We do not need to fix what is not broken. Why do we need a new definition at all? If definitions in RFC 7950 are broken, then we need to fix it in YANG next. /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
Re: [netmod] The Uselessness of webmail
On Sat, Mar 20, 2021 at 11:49:09AM +, tom petch wrote: > From: Juergen Schoenwaelder > Sent: 19 March 2021 17:54 > > Subject: Re: [netmod] Use of prefixes in YANG models > > On Fri, Mar 19, 2021 at 04:38:11PM +, tom petch wrote: > > > > > > Apologies for the useless quoting that my webmail imposes on me:-( > > > > Your webmail does not allow to edit the quoted text? > > It has no replace function so I would have to insert a > character in front > of every line by hand. And, often, the original e-mail as displayed has a > series of coloured lines down the left hand side which give some indication > as to what the level of quoting is. When composing a reply, those lines have > vanished so I would have to go back to the original e-mail to see what the > level of quoting is for any one paragraph and then insert the appropriate > number of > characters for each line of each paragraph. Life is too short > to iron tea towels (as a famous person once said)! > I do not know what forces you to use this webclient but there is always a readers vs. writers or who pays the price aspect. I do occasionally press 'delete' on emails requiring extra time or special tools to identify the contribution (and given that I am of the dying species reading emails in plain text, I accept that the world is moving on and I am just stuck in the 20th century). /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
Re: [netmod] Use of prefixes in YANG models
On Fri, Mar 19, 2021 at 04:38:11PM +, tom petch wrote: > > > Apologies for the useless quoting that my webmail imposes on me:-( > Your webmail does not allow to edit the quoted text? /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
Re: [netmod] Use of prefixes in YANG models
On Fri, Mar 19, 2021 at 09:23:06AM +, tom petch wrote: > > If the spec was more precise it would settle the arguments. > RFC 7950 says that tools must support a prefix statement inside an import statement, which overrides the prefix defined in the imported module. A tool that does not support this is not implementing RFC 7950 correctly. RFC 8407 provides additional rules for authors writing IETF YANG modules. Implementations may generate warnings (perhaps even errors, may be implementation specific) if these rules are violated by modules to which the RFC 8407 rules apply. (This implies that a tool needs to know whether RFC 8407 rules apply or not.) It is true that RFC 8407 is not very explicit to which YANG modules the rules apply but given the many IETF specific rules, it is kind of implicit that the rules may not apply 1:1 to YANG modules published by other organizations. /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
Re: [netmod] Use of prefixes in YANG models
We often do not do a good job in distinguishing technical requirements from usage guidelines. (And RFC 2119 keywords make things worse.) As far as I recall, the intent of the RFC 8407 text was to say that it is helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 'date-and-time' defined in 'ietf-yang-types'. I believe we agreed that module authors assigning a prefix different from the default prefix during an import should have either technical reasons for doing so (resolving prefixes clashes) or some other good reason to depart from the general guideline aiming to reduce human confusion. /js (who stopped believing that RFC 2119 keywords are helpful years ago) On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > I have seen the debate on the use of prefixes in YANG models, specially as it > relates to their use when importing a model. I think it would nice to be > clear on what is required, what is nice, and what is not ok to do. I do not > want to confuse this discussion with the length of the prefix, which I > believe is somewhat related but not the same discussion. > > RFC 7950 says: > >All prefixes, including the prefix for the module itself, MUST be >unique within the module or submodule. > > This is a requirement, as is clear by the MUST. > > Then RFC 7950 says: > >To >improve readability of YANG modules, the prefix defined by a module >SHOULD be used when the module is imported, unless there is a >conflict. > > It also says: > >When used inside the "import" statement, the "prefix" statement >defines the prefix to be used when accessing definitions inside the >imported module. > > Clearly, the scope of the “prefix" statement used with an “import” statement > is limited to the module where it is imported and does not impact the > imported module. As such, and because it is a SHOULD and not a MUST, this is > a “nice to have” without conflicts, but one would not be wrong using a > different prefix from the one defined in the imported module. Add to this, > most tools, e.g. pyang or yanglint do not complain if you do define a > different prefix when there are no conflicts. I have not seen a problem in > the implementation of the module when the prefix is different. > > RFC 8407 confuses this whole situation by saying: > > The proper module prefix MUST be used for all identifiers imported > from other modules. > > which as written is true for identifiers (but not for other types of > imports??). Besides, it does not define what is “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
Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match
I now understand that the original request was about two things:
- allowing sets of prefixes in an ACL (instead of just a single)
- sharing of sets of prefixes between ACLs
And yes, if the WG goes there, then of course the same questions will
come up for all the other possible header fields...
- allowing sets of ports/port ranges
- sharing of sets of ports/port ranges between ACLs
[...]
/js
On Wed, Mar 17, 2021 at 03:49:11PM +, Aseem Choudhary (asechoud) wrote:
> Hi,
>
> Similarly, there is NxM issue when there are more than one source and
> destination port/port ranges.
>
> -thanks,
> Aseem
>
> On 3/17/21, 5:29 AM, "netmod on behalf of Juergen Schoenwaelder"
>
> wrote:
>
> Hi,
>
> let me check whether I understand your request correctly: I heard you
> saying that you would like to have
>
> leaf-list destination-ipv6-network {
> type inet:ipv6-prefix;
> description
> "Destination IPv6 address prefix.";
> }
>
> instead of just
>
> leaf destination-ipv6-network {
> type inet:ipv6-prefix;
> description
> "Destination IPv6 address prefix.";
> }
>
> (and similar changes for the other IP prefix related leafs).
>
> While such a direct change may be difficult, given that the header
> fields are defined in a choice, it should be possible to add
> additional choices for sets of prefixes. So from the YANG side, this
> seems to be something possible to address without too much trouble.
>
> Whether implementors are happy with supporting such a change is
> something others have to comment on.
>
> /js
>
> On Wed, Mar 17, 2021 at 10:31:10AM +, Oscar González de Dios wrote:
> > Dear netmod wg colleagues,
> >
> > The ietf-acl YANG model defined in RFC 8519 allows to
> create rules, and for each a rule, in case of IPv4/IPv6 you can specify in
> the match the source-network and destination-network. The source-network (or
> equally the destination network) is in the model an address prefix. In our
> use case in Telefonica we are specifying a prefix-list for source network and
> another prefix list for destination network. If you had to create this
> behavior using the ACL model, you would need to create NxM rules. Besides,
> the management of those rules would be more complex.
> >
> > The routing policy model has the concept of
> prefix-sets, but is a separate model (and a different use case).
> >
> > The functionality of specifying a prefix list for
> source and destination in access control lists is available in most vendors
> that I am aware today. Hence, it's a pretty standard functionality.
> >
> > Do you think it is useful to add this functionality to
> the ACL YANG model? If yes, what would be the procedure, given that ACL is
> already defined in an existing RFC?
> >
> > Best Regards,
> >
> >Oscar
> >
> >
> >
> >
> >
> >
> >
> > Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y es
> para uso exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de la
> legislación vigente. Si ha recibido este mensaje por error, le rogamos que
> nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> >
> > The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete it.
> >
> > Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é para
> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o
> destinatário indicado, fica notificado de que a lei
Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match
Hi,
let me check whether I understand your request correctly: I heard you
saying that you would like to have
leaf-list destination-ipv6-network {
type inet:ipv6-prefix;
description
"Destination IPv6 address prefix.";
}
instead of just
leaf destination-ipv6-network {
type inet:ipv6-prefix;
description
"Destination IPv6 address prefix.";
}
(and similar changes for the other IP prefix related leafs).
While such a direct change may be difficult, given that the header
fields are defined in a choice, it should be possible to add
additional choices for sets of prefixes. So from the YANG side, this
seems to be something possible to address without too much trouble.
Whether implementors are happy with supporting such a change is
something others have to comment on.
/js
On Wed, Mar 17, 2021 at 10:31:10AM +, Oscar González de Dios wrote:
> Dear netmod wg colleagues,
>
> The ietf-acl YANG model defined in RFC 8519 allows to create
> rules, and for each a rule, in case of IPv4/IPv6 you can specify in the match
> the source-network and destination-network. The source-network (or equally
> the destination network) is in the model an address prefix. In our use case
> in Telefonica we are specifying a prefix-list for source network and another
> prefix list for destination network. If you had to create this behavior using
> the ACL model, you would need to create NxM rules. Besides, the management of
> those rules would be more complex.
>
> The routing policy model has the concept of prefix-sets, but
> is a separate model (and a different use case).
>
> The functionality of specifying a prefix list for source and
> destination in access control lists is available in most vendors that I am
> aware today. Hence, it's a pretty standard functionality.
>
> Do you think it is useful to add this functionality to the
> ACL YANG model? If yes, what would be the procedure, given that ACL is
> already defined in an existing RFC?
>
> Best Regards,
>
>Oscar
>
>
>
>
>
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el destinatario
> indicado, queda notificado de que la lectura, utilización, divulgación y/o
> copia sin autorización puede estar prohibida en virtud de la legislación
> vigente. Si ha recibido este mensaje por error, le rogamos que nos lo
> comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and confidential
> information intended only for the use of the individual or entity named
> above. If the reader of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this transmission
> in error, do not read it. Please immediately reply to the sender that you
> have received this communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo da
> pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia
> sem autorização pode estar proibida em virtude da legislação vigente. Se
> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente
> por esta mesma via e proceda a sua destruição
> ___
> 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
Re: [netmod] type equivalence
After some iteration with Rob, here is a new version: NEW''' o A "type" statement may be replaced with another "type" statement as long as the underlying built-in type and the representation and semantics of the type do not change (other than allowed by other rules in this section). For example, an inline type definition may be replaced with a semantically equivalent typedef derived from the same built-in type, but an int8 type cannot be replaced by an int16 type, since the underlying built-in type would change. /js On Wed, Feb 24, 2021 at 09:39:15PM +0100, Juergen Schoenwaelder wrote: > Here is an attempt to come up with better wording. If people agree on > a new wording, I volunteer to submit an errata. > > OLD > >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. > > NEW > >o A "type" statement may be replaced with another "type" statement > that does not change the semantics of the type or the underlying > built-in type. For example, an inline type definition may be > replaced with a semantically equivalent typedef derived from the > same built-in type, but an int8 type cannot be replaced by an > int16, since the underlying built-in type would change. > > /js > > On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote: > > On 2021-02-22, at 15:17, Juergen Schoenwaelder > > wrote: > > > > > > I guess considering the built-in types as incompatible is the most > > > robust approach. If we agree that RFC 7950 tried to say this, we could > > > file an errata and propose clearer language. > > > > Right. And we can keep the COMI key-to-URL mapping as is, as this > > clarification is necessary for its correct functioning. > > > > Grüße, Carsten > > > > -- > 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 https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Questions about how to assign default values with YANG
On Wed, Mar 10, 2021 at 05:34:41PM +, Italo Busi wrote: > Juergen, > > I think you have got the problem: "a data model author thought the default is > always 0 and later he/she realizes that in some contexts the default should > be something different" > > Unless I am missing something, creating a new leaf (e.g., foo-new) would > confuse an existing client. No, it does not confuse the client, the client will ignore it. > For example, within the operational DS, the value of foo will be set to 0 (as > per YANG default statement) while the value of foo-new will be set to 10, > which represents the actual value in use by the system. Yes, a new implementation will have to declare that it does not implement foo. > Now, the existing client, which is not aware of foo-new, when reading the > value of foo in the operational DS will incorrectly think that the actual > value in use by the system is 0 rather than 10. A client reading knows the value in use. But clients do not have to real operational. > Am I missing anything? > > Instead, if we can find a magic way to apply the value 10 to foo within the > operational DS, the existing client can read the value of foo in the > operational DS and correctly understand that the actual value in use by the > system is 10 (even if this is not the default value of foo). In general, you can't assume that clients read operational. I can't judge the specific circumstances but in traditional NC/RC, a default statement can be interpreted as "assume the default value is in force if this lead is not configured" (unless the client uses RFC 6243 report-all). If all clients are in an NMDA world, the issue is much smaller - it is reduced to "does the client believe the server has a bug or not". But even then, I continue to believe that a leaf changing the semantics of another leaf is bad design. /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
Re: [netmod] Questions about how to assign default values with YANG
I do not understand where the problem is. a) If a leaf says my default is 0, then the default is 0 and you can't change that by creating other leafs somewhere else that says something different. b) If a leaf says that is has a default value but the value is determined in some magic way not defined here, then you can add additional leafs that detail the magic for certain contexts The point is that a) tells clients they can safely assume the default value is 0 while b) tells clients that they can assume that there is a default but the exact default value they will not know unless they understand magic. If a data model author thought the default is always 0 and later he/she realizes that in some contexts the default should be something different, then you have to resolve that by creating new leafs (in the current version of YANG) or you declares a non-backwards compatible new version of the definition of the leaf (if the versioning work gets standardized). /js On Wed, Mar 10, 2021 at 03:25:13PM +, Italo Busi wrote: > Hi Andy, > > I see your point, > > At the beginning of this thread, I have had a doubt about how to reconcile > sec. 7.6.1 of RFC7950 with sec. 5.3 of RFC8342: > >Requests to retrieve nodes from always return the value >in use if the node exists, regardless of any default value specified >in the YANG module. If no value is returned for a given node, then >this implies that the node is not used by the device. > > My understanding that the client will always get the applied value > independently on whether it is 0 or 10 or another value. > > Anyway, it seems to me that the issue is mainly about the keyword “default” > so let me take a step back and try to define the issue I am trying to solve, > without assuming any solution. > > What I need is to find a solution that allows a client to request the server > to apply the value 10 for the leaf foo in the operational DS without > “explicitly” writing the value 10 in the running DS but “implicitly” by > writing another leaf bar in the running DS, even if the leaf foo has a YANG > default statement defining 0 as its default value. > > I think that the NMDA architecture is quite flexible and could be leveraged > to resolve this issue. > > Stepping away from defining default values, one possibility could be that the > applied configuration of the value of foo is defined by the system before > applying the intended configuration in the operational DS, as a side effect > of applying the configuration of the leaf bar. > > Another alternative which is just jumping to my mind, could be that the value > of 10 for the leaf foo is set by the system in the intended DS, applying a > sort of template. Should in this case the definition of the leaf bar be > interpreted as a template configuration or how should the required template > configuration be provided? > > Could any of this option be used to resolve this issue? > > Italo > > From: Andy Bierman [mailto:a...@yumaworks.com] > Sent: mercoledì 10 marzo 2021 15:16 > To: Italo Busi > Cc: Juergen Schoenwaelder ; > netmod@ietf.org > Subject: Re: [netmod] Questions about how to assign default values with YANG > > > > On Wed, Mar 10, 2021 at 12:54 AM Italo Busi > mailto:italo.b...@huawei.com>> 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 model. I am > just willing to understand if a work-around is possible, without breaking any > client, to allow re-using an existing module which has already defined a > default value. > > > Read sec. 7.6.1 again, especially this part: > >When the default value is in use, t
Re: [netmod] Questions about how to assign default values with YANG
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.
/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 model. I am
> just willing to understand if a work-around is possible, without breaking any
> client, to allow re-using an existing module which has already defined a
> default value.
>
> Italo
>
> From: Andy Bierman [mailto:a...@yumaworks.com]
> Sent: martedì 9 marzo 2021 21:12
> To: Juergen Schoenwaelder ; Italo Busi
> ; netmod@ietf.org
> Subject: Re: [netmod] Questions about how to assign default values with YANG
>
>
>
> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder
> mailto:j.schoenwael...@jacobs-university.de>>
> wrote:
> Changing the semantics of a definition via augments is bad design.
>
> A system that does not understand the augment will believe the default
> is 0. Since there is no way to force an existing implementation to
> understand a certain augmentation, different implementation will
> rightfully disagree on the default value in effect.
>
>
> deviation /ex:example/ex:foo {
> delete {
>default 0;
> }
> }
>
> IMO it was a bad idea to say deviations MUST NOT appear in standard modules.
> Here is a use-case for it.
>
> The old-client does not know about the new dynamic default but it could know
> that the old YANG default is not being used.
>
>
> /js
>
> Andy
>
>
> On Mon, Mar 08, 2021 at 08:19:39PM +, Italo Busi wrote:
> > 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:
> >
> > 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.
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
Dear Qin, I believe this work repeats failures of the past but since the WG agreed to entertain this, I will keep my mouth shut. I suggest you do not spend your energy to convince the that this work is viable since it is rather unlikely that I will change my mind. YANG is for me _not_ a suitable policy language, it is at best a language to carry policies written in a suitable policy language (and I am not even sure about this). All attempts in the past to reach agreement on a common usable standard policy language leading up to interoperable implementations failed. The reasons are manifold but strong (I think), standards-based interoperability at a generic policy language abstraction layer is for me a myths. Please don't take this personal in any way. I just do not believe into this work but I am happy to be proven wrong. /js On Wed, Mar 10, 2021 at 08:07:46AM +, Qin Wu wrote: > Hi, Juergen: > Come back to the key issues for ECA Policy. > I think Policies need to be readable and hence be expressed at a high level > of abstraction and in a suitable _language_. > But I propose to separate policy expression and intent representation, > especially high level service intent representation, translation, mapping > which is the hot topic in NMRG. > High level language we select for policy representation is YANG, expressed by > the NMS or controller. > We can compare YANG vs NETCONF with RMON vs SNMP, RAMON is an extension of > SNMP, provides traffic flow data for troubleshooting and the controls > necessary to adjust for better performance from a central console. > I think we set similar goal as ROMON in our draft. > > Unlike other intent translation or mapping, we compile High-level policy > expression down into more verbose primitive representations that are closer > to an execution abstraction. YANG expression is capable for such a > compilation;. > Primitive representation in the device is script language, typical examples > are Python or TCL used in the device > > Of course there is pitfall to start somewhere in the middle of several layers > of abstraction and then getting stuck somewhere when compiling things down to > _efficient_ instrumentations. > One of lesson we learn from the past is SUPA is defined and described very > abstractly, with its high-level blocks and UMLs, and is very difficult to be > written in YANG and harder to be implemented. > We will avoid such pitfall. > > At the current stage YANG is used for abstraction and representation. YANG is > both representative and implementable. > > -Qin (on behalf of authors) > -邮件原件- > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder > 发送时间: 2020年12月30日 2:56 > 收件人: Adrian Farrel > 抄送: 'NETMOD Group' > 主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10 > > Adrian, > > some key issues when it comes to policy-based management systems: > > - What is an adequate abstraction level to express policies and intent? > >This question has no simple answer. I believe policies need to be >readable and hence they need to be expressed at a high level of >abstraction and in a suitable _language_. High-level policy >expression may be compiled down into more verbose primitive >representations that are closer to an execution abstraction. A >common pitfall is to start somewhere in the middle of several >layers of abstraction and then getting stuck with something awkward >to put a clean higher layer abstract onto and to compile things >down to _efficient_ instrumentations. > > - Where are policies executed? > >This can range from a logically centralized policy execution >engine, which is part of what people call an orchestrator these >days, to fully distributed policy execution models. In reality, you >likely want to distribute functions dynamically but this makes >solutions technically much more complicated. Given today's scalable >computing and networking capabilities, logically centralized >solutions are on the rise and have replaced the distributed >approaches of the 90s. > > - When to detect and resolve policy conflicts? > >Detecting and resolving conflicts in larger collections of policies >is non-trivial. This includes problems ranging from micro timescale >atomicity issues to larger timescale stability issues (interacting >policy control loops). If policy execution is distributed (or the >event / information sources are distributed), this ultimately >resolves to problems such as taking consistent snapshots or finding >ways to work with inconsistent observations of a distributed system >that are guaranteed to converge to stable states (self-stabilizing >
Re: [netmod] Questions about how to assign default values with YANG
Changing the semantics of a definition via augments is bad design.
A system that does not understand the augment will believe the default
is 0. Since there is no way to force an existing implementation to
understand a certain augmentation, different implementation will
rightfully disagree on the default value in effect.
/js
On Mon, Mar 08, 2021 at 08:19:39PM +, Italo Busi wrote:
> 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:
>
> 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]
> > Sent: mercoledì 20 gennaio 2021 17:05
> > To: Italo Busi
> > Cc: '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
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] type equivalence
On Fri, Feb 26, 2021 at 07:05:32PM +, Rob Wilton (rwilton) wrote: > > > E.g., I'm wondering, would your proposed new definition allow us to change > from the IETF to IEEE MAC address definition? The underlying type is the > same (String), and arguably the semantics of both types is the same (i.e., > they both represent an IEEE 802 MAC address), but the syntax of the two types > clearly differs. > If [1] is true, then the answer is obviously 'no' since the value spaces of the two types are disjunct. /js [1] https://www.ieee802.org/1/files/public/docs2020/yangsters-smansfield-mac-address-format-0420-v01.pdf -- 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
Re: [netmod] type equivalence
On Fri, Feb 26, 2021 at 03:27:39PM +, Rob Wilton (rwilton) wrote:
>
> Sure, but if we are going to submit an errata for this definition, we want to
> ensure that updated definition is clear in all axes, not only the specific
> issue that was originally raised.
>
This is where the IETF shines, there is an attempt to fix a minor
problem and the result is N additional possible problems are put on
the table to be considered as well before the minor problem can be
fixed. My interest was the original question since I did run into it,
my interest is low in fixing all other possible problems that people
can think of.
Note, there are other places in RFC 7950 where the phrase 'semantics
of a definition' is used, e.g.,
Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier.
and this wording goes back to RFC 2578 and I am not aware that many
people had a problem with that, i.e., it seems to have worked 20+
years.
> Hence, my question is really whether "semantics of the type" is intuitively
> obvious, or it requires further text that defines what is meant by that,
> specifically, that the description in the type (and probably parent types
> it's derived from) forms part of the semantics of a type definition.
I believe 'semantics of a definition' is likely as good as it gets.
> Otherwise, it is possible that someone may think that it is pattern statement
> that defines the semantics of inet:ipv6-address, and not also the description.
>
If 'semantics of a definition' is a problem, then someone should come
up with a separate proposal to fix this new problem (and as outlined
above, this phrase goes beyond the paragraph I suggested to clarify).
I am not interested in that can of worms and I assume most technical
people will know when they change the semantics of a definition.
I started this thread because
type int8 { range "1..10"; description "a number between 1 and 10"; }
type uint8 { range "1..10"; description "a number between 1 and 10"; }
can appear to be the same type but it is actually not due to the
change of the underlying built-in type and this is what I considered
worth to clarify. This is relevant for people writing YANG modules and
also for people working on encodings of YANG data where it matters
whether they can rely on underlying built-in types not changing.
Anyway, if this leads to N additional problems that can be considered
to be fixed, then I rather leave things as they 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
Re: [netmod] type equivalence
On Fri, Feb 26, 2021 at 12:21:26PM +, Rob Wilton (rwilton) wrote:
>
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> >
> > Here is an attempt to come up with better wording. If people agree on
> > a new wording, I volunteer to submit an errata.
> >
> > OLD
> >
> >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.
> >
> > NEW
> >
> >o A "type" statement may be replaced with another "type" statement
> > that does not change the semantics of the type or the underlying
> > built-in type. For example, an inline type definition may be
> > replaced with a semantically equivalent typedef derived from the
> > same built-in type, but an int8 type cannot be replaced by an
> > int16, since the underlying built-in type would change.
> [RW]
>
> Would the text be more clear it is just specified what is allowed, e.g.,
>
> o A "type" statement may be replaced with another "type" statement
> that resolves to the same underlying built-in type. For example,
> ...
Perhaps - but it is not just the built-in type that matters...
> What does "semantics of the type" cover?
>
> If I have this type:
>
> typedef "timestamp" {
> type "string";
> description
> "The time of day that an event occurred, in any format";
> }
>
> then can I replace it with this definition:
>
> typedef "timestamp" {
> type "string";
> description
> "The time of day, and optionally date, that an event
>occurred, in any format";
> }
This example seems to be constructed since "in any format" is already
broken to begin with. A more perhaps better example: If you have
type inet:ipv4-address;
then you can't replace that with
type inet:ipv6-address;
since that changes the semantics of the type. If you have a counter
that only counts upwards (until it wraps or latches), then you can't
replace it with a gauge that goes up and down. The point is that you
break expectations about the semantics of a value of existing
applications.
In your example, if you have time in any format, then well
interoperability does not seem to be expected in the first place and
then you can start a philosophical discussion whether making something
non-interoperable even more non-interoperable is not just leading to
non-interoperable.
Anyway, the "semantics" part was not the question that triggered this
thread, the question was whether changing built-in types is allowed or
not.
> Tangentially, it is worth noting the RFC 8342 also writes about syntactic
> constraints covering types:
>
> 5.3. The Operational State Datastore ()
>
>Syntactic constraints MUST NOT be violated, including hierarchical
>organization, identifiers, and type-based constraints. If a node in
> does not meet the syntactic constraints, then it
>MUST NOT be returned, and some other mechanism should be used to flag
>the error.
>
> I'm not sure how clear RFC 8342 section 5.3 is about returning values
> that can be represented by the underlying built-in-type, but are outside
> the value space defined by a range, length, or pattern statement.
>
> My memory during the discussions was that it is allowed to return a value
> outside arange, length, pattern statement, as long as it is contained
> in the value space of the built-in-type. E.g., cannot return 257 in a
> uint8, but can return 11 even if the type range is 1..10.
>
> But, I'm not sure that is what the text actually states.
Perhaps this requires a separate thread. Perhaps 'syntactic
constraints' was not a good choice and yes different people might
understand 'type-based constraints' differently. RFC 7950 says:
The following properties are true in all data trees:
o All leaf data values MUST match the type constraints for the leaf,
including those defined in the type's "range", "length", and
"pattern" properties.
So I am not sure about returning 11 for a range 1..10.
/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
Re: [netmod] type equivalence
On Fri, Feb 26, 2021 at 11:31:58AM +, Rob Wilton (rwilton) wrote: > > I also note that draft-ietf-netmod-yang-module-versioning-02 states: > >This document updates [RFC7950] section 11. Section 3 describes >modifications to YANG revision handling and update rules, and >Section 4 describes a YANG extension statement to do import by >derived revision. > > So, I'm still of the opinion that clarifying this behaviour in > draft-ietf-netmod-yang-module-versioning-02, if the proposed change cannot be > accepted as a verified errata, is a pragmatic solution. > This document has a long way to go. I am not sure everybody agrees with changing YANG 1.1 rules by an update (without changing YANG's version number, i.e., it becomes upclear which rules apply to a given YANG module). /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
Re: [netmod] type equivalence
On Thu, Feb 25, 2021 at 07:22:27PM +, Rob Wilton (rwilton) wrote: > > As an AD: > Whether this can be done as a verified errata isn't so clear, but would > obviously depend on the proposed text. > I have proposed text that tries to fix the unfortunate use of 'syntax'. Does the AD see an issue with the proposed text? /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
Re: [netmod] type equivalence
On Thu, Feb 25, 2021 at 05:10:21PM +, Rob Wilton (rwilton) wrote: > > Since the YANG module versioning draft clarifies the BC/NBC rules, perhaps we > could add text to clarify this in that draft? > > I.e., perhaps something for section 3.1.3 of > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/ > I rather have this fixed (or clarified) in RC 7950, as far as I understand I can choose to ignore the versioning extensions and simply use YANG 1.1, no? That said, draft-ietf-netmod-yang-module-versioning-02.txt says in 3.1.2.: o Modifying the type of a leaf or leaf-list is NBC This seems to be way more restrictive than the existing YANG 1.1 rules we have today. Perhaps that is what the versioning people want, but then we better keep the YANG 1.1 rules and the YANG + versioning rules separate. /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
Re: [netmod] type equivalence
Here is an attempt to come up with better wording. If people agree on a new wording, I volunteer to submit an errata. OLD 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. NEW o A "type" statement may be replaced with another "type" statement that does not change the semantics of the type or the underlying built-in type. For example, an inline type definition may be replaced with a semantically equivalent typedef derived from the same built-in type, but an int8 type cannot be replaced by an int16, since the underlying built-in type would change. /js On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote: > On 2021-02-22, at 15:17, Juergen Schoenwaelder > wrote: > > > > I guess considering the built-in types as incompatible is the most > > robust approach. If we agree that RFC 7950 tried to say this, we could > > file an errata and propose clearer language. > > Right. And we can keep the COMI key-to-URL mapping as is, as this > clarification is necessary for its correct functioning. > > Grüße, Carsten > -- 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
Re: [netmod] type equivalence
On Mon, Feb 22, 2021 at 02:55:57PM +0100, Carsten Bormann wrote:
> On 2021-02-22, at 14:53, Juergen Schoenwaelder
> wrote:
> >
> > Yes, "base type" is the wrong term, I think we talk about what RFC
> > 7950 calls "build-in types”.
>
> OK, so rephrasing my question:
>
> Are all built-in types incompatible in the sense that moving from one to the
> other is NBC, or are there clusters where moving within is innocuous?
>
I do not think we ever had the notion of "clusters" (or something like
the universal unlimited INTEGER in ASN.1, a common root of all fixed
precision integer types).
Martin and Lada seem to say that all built-in types are incompatible.
Lada made the point that range restrictions can be expanded and hence
the differences of the size or the signedness of the underlying
built-in type may eventually matter.
Of course, if we go down this route, then encodings may take advantage
of this. I have no clue what code generators do, if they indeed map
type int32 { range "0..10"; }
to a 32-bit signed number (to be prepared that someone may enlarge the
range) or whether they go for more space efficient representations
(and then versioning issues may arise or you live with implicit
integer conversions if your programming language does them).
I guess considering the built-in types as incompatible is the most
robust approach. If we agree that RFC 7950 tried to say this, we could
file an errata and propose clearer language.
/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
Re: [netmod] type equivalence
On Mon, Feb 22, 2021 at 11:47:05AM +0100, Carsten Bormann wrote:
>
>
> > On 2021-02-22, at 11:13, Martin Björklund wrote:
> >
> > Juergen Schoenwaelder wrote:
> >> Thanks Martin,
> >>
> >> so you are saying that
> >>
> >> int8 { range "1..10"; }
> >>
> >> is indeed different from
> >>
> >> uint8 { range "1..10"; }
> >>
> >> and
> >>
> >> int32 { range "1..10"; }
> >
> > Yes.
>
> Oh. People often choose uint8 etc. with an intention to set a range.
> I don’t think they know that they are setting themselves up for NBC if that
> range needs to be extended later.
> So I would have expected that there is a common base type these are all
> derived from.
>
> RFC 7950 does not use "base type" as an absolute term; it only can be used
> relative to “derived type”.
> I don’t know which of the built-in types are “absolute base types” in the
> sense you would need it to define the rule.
>
Yes, "base type" is the wrong term, I think we talk about what RFC
7950 calls "build-in types".
/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
Re: [netmod] type equivalence
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. /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
Re: [netmod] type equivalence
Thanks Martin,
so you are saying that
int8 { range "1..10"; }
is indeed different from
uint8 { range "1..10"; }
and
int32 { range "1..10"; }
The use of the word "syntax" in the text you quote may be a left-over
from SMIv2 times, it does not really seem to be aligned with how the
term 'syntax' is used elsewhere in RFC 7950. Anyway, if the agreement
back then was that you can't change base types (regardless of type
restrictions), it would have been nice if the text would say this more
clearly.
/js
On Mon, Feb 22, 2021 at 10:49:38AM +0100, 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).
>
>
> /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
--
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
Re: [netmod] type equivalence
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
Re: [netmod] type equivalence
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. 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.
/js
On Fri, Feb 19, 2021 at 06:24:02PM +0100, Carsten Bormann wrote:
> On 2021-02-19, at 17:55, Juergen Schoenwaelder
> wrote:
> >
> > Hi,
> >
> > can I safely replace
> >
> >leaf foo {
> > type int8 { range "0..100"; };
> >}
> >
> > with
> >
> >leaf foo {
> > type uint8 { range "0..100"; };
> >}
> >
> > or with
> >
> >leaf foo {
> > type int32 { range "0..100"; };
> >}
> >
> > or are these a non-backwards compatible changes?
>
> I don’t have an answer to that, but would like to point you to the table at
> the top of page 14 in draft-ietf-core-comi-11.txt [1], which would make the
> first replacement a non-backwards compatible change in the way we build URIs
> from that.
>
> [1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14
>
> > Note that the value
> > set is always the same, however the underlying base type changes. Did
> > we ever define type equivalence?
>
> The way unions are handled in YANG gives me the impression that as long as
> the sets of XML representations generated by the two types are the same, they
> are equivalent.
>
> Grüße, Carsten
>
--
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] type equivalence
Hi,
can I safely replace
leaf foo {
type int8 { range "0..100"; };
}
with
leaf foo {
type uint8 { range "0..100"; };
}
or with
leaf foo {
type int32 { range "0..100"; };
}
or are these a non-backwards compatible changes? Note that the value
set is always the same, however the underlying base type changes. Did
we ever define type equivalence?
/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
Re: [netmod] MD5 in ianach ex-RFC7317
RFC 8407:
4. YANG Usage Guidelines
Modules in IETF Standards Track specifications MUST comply with all
syntactic and semantic requirements of YANG 1.1 [RFC7950].
The rule you quoted does not apply since we are talking about an IANA
document.
/js
On Wed, Feb 10, 2021 at 05:25:26PM +, Kent Watsen wrote:
>
>
> > On Feb 10, 2021, at 11:46 AM, tom petch wrote:
> >
> > Not quite for me. The current version is that on the IANA website, RFC7317
> > is history at least for IANACH so I think that the YANG reference for the
> > update should be to the IANA website.
> >
>
> Please provide OLD/NEW text.
>
> FWIW, RFC8407 says:
>
>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.
>
> So what is the “document”?
>
> revision 2021-MM-DD {
> description
> “Deprecated the 'crypt-hash-md5’ feature per RFC 6151.";
> reference
> "RFC 6151:
> Updated Security Considerations for the MD5
> Message-Digest and the HMAC-MD5 Algorithms";
> }
>
> But note that 6151 was published long before 7317 and, besides, it doesn’t
> “deprecate” MD5.
>
> We can’t reference 8573 because it's NTP-specific. Perhaps iana-crypt-hash
> is fine, and instead ntp-yang-data-model should be republished, augmenting in
> the desired “status” while referencing 8573.
>
> K.
> ___
> 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
Re: [netmod] MD5 in ianach ex-RFC7317
On Tue, Feb 09, 2021 at 05:47:28PM +, Kent Watsen wrote: > > > I agree, but it takes an I-D to do the update, yes? > > > > > > I don't see why; the registry is expert review and we are doing a change > > that comes under permitted changes for a YANG module, ie a status change. > > My understanding is that a publication of a draft altering an IANA registry > will trigger an “expert review”, if that registry was created with the > update-policy set that way. The draft itself doesn’t request an expert > review, the expert review happens in the background. I’m not familiar with > this being done without an I-D, in order to show WG consensus. > My understanding is that IANA reviews all documents during the publication process and while performing this review they will notice that something is requested to be added/changed in a registry that requires expert review and then they will go and run the procedure. My understanding is this is _one_ way to make a request to IANA but not the only way to make a request to IANA. The more interesting bit is what IANA has to say about this registry: iana-crypt-hash YANG Module RFC 7317 Expert Review (Expert: Unassigned) Perhaps we should focus more on finding a volunteer willing to take the role of the Designated Expert... /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
Re: [netmod] MD5 in ianach ex-RFC7317
On Tue, Feb 09, 2021 at 05:06:38PM +, Kent Watsen wrote: > Hi Tom, > > > MD5 has long been deprecated as in RFC6151, RFC8573(NTP). > > > > The NTP YANG I-D, ntp-yang-data-model, imports ianach without any > > constraint and so goes against RFC8573. > > > > I think we should update ianach to deprecate MD5 by adding a status clause. > > This is a permitted update per YANG and the module is Expert Review so I > > believe that with the consensus of the NETMOD WG, IANA could be asked to > > add 'status deprecated' to MD5. > > > > Thoughts? > > I agree, but it takes an I-D to do the update, yes? I believe the process is that someone submits an update request to IANA and IANA will then contact the Expert for Review and then the Expert does whatever she does. "The designated expert is not required to personally bear the burden of evaluating and deciding all requests, but acts as a shepherd for the request, enlisting the help of others as appropriate." (RFC 5226, BCP 26) /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
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/> ___ 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 Wed, Jan 20, 2021 at 10:51:09AM +, Italo Busi wrote: > > Does it mean that a server may not use/implement in the operational datastore > a leaf for which a YANG default statement has been defined? > RFC 7950 section 7.6.1 mentions describes situations where a leaf is conditional, i.e., there is when condition or an if-feature expression or the leaf is a case node. > What would be the value of defining a YANG default statement for config > false leaf? > Technically, this can happen because a type has a defined default value and this type may be used by config false leafs. An example is the zero-based-counter32 typedef in RFC 6991. However, this style may be debated since it (mis)uses a default statement to define an initial value. I am not sure whether the pattern of using default statements for specifying intial values is a good one. /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
Re: [netmod] Questions about how to assign default values with YANG
On Wed, Jan 20, 2021 at 08:57:48AM +, Italo Busi wrote:
> Hi all,
>
> I have read RFC7950 and RFC8342 but I have still some questions for
> clarification about how to deal with default values in YANG.
>
> Let's consider a config true leaf for which a YANG default statement has been
> defined in the YANG module.
>
> If the client does not configure that leaf in the running datastore, the leaf
> is not present (cannot be read) in the running datastore.
>
> The default value for that leaf is assigned by server in the operational
> datastore as part of the applied configuration (assuming that other
> configurations do not override it).
>
> If that leaf exists in the operational datastore, the server shall return the
> default value if that leaf is read.
>
> Is our understanding correct?
Yes. And you would tag the value with or:origin="or:default", appendix C.1
in RFC 8342 is a good example.
> Is it possible for a server not to use that leaf and not to return any value
> if that leaf is read?
>
> According to this text from RFC8342, it seems that this is possible:
>
>Requests to retrieve nodes from always return the value
>in use if the node exists, regardless of any default value specified
>in the YANG module. If no value is returned for a given node, then
>this implies that the node is not used by the device.
>
> However, according to this text from RFC7950, it seems that this is not
> possible:
>
>When the default value is in use, the server MUST operationally
>behave as if the leaf was present in the data tree with the default
>value as its value.
I do not see the conflict. Note that RFC 7950 predates the notion of
an operational datastore.
> There are case where the default value to assign to a leaf depends on the
> configuration of other leaves. In this case, the default value cannot be
> defined using a YANG default statement.
>
> In this case, is it possible in this case to define the default value in the
> description (maybe referencing some other standard specification)?
>
> Would the behavior of the system be exactly the same as in the cases where
> the default value is assigned using a YANG default statement?
RFC 8342 says:
o default: represents configuration using a default value specified
in the data model, using either values in the "default" statement
or any values described in the "description" statement. The
default origin is only used when the configuration has not been
provided by any other source.
and
identity default {
base origin;
description
"Denotes configuration that does not have a configured or
learned value but has a default value in use. Covers both
values defined in a 'default' statement and values defined
via an explanation in a 'description' statement.";
}
So it is possible to define the default in a description clause.
> Would it be possible in this case to define a default value for a leaf
> defined in a base model which depends on an attribute defined in another
> model which augments the base model?
> In this case, the description of the leaf in the base model cannot be changed
> in the augmented model. Should the default value for the leaf defined in the
> base model be described in the description for the leaf defined in the
> augmenting module?
> For example, would this YANG be valid/correct to define a default value 10
> for the leaf foo when the leaf bar exist?
>
> module example-base {
> container example {
> leaf foo {
> type uint8;
> }
> }
> }
>
> module example-augment {
> import example {
> prefix ex;
> }
>
> augment "ex:example" {
> leaf bar {
> type empty;
> description
> "When present, the default value for foo is 10.";
> }
> }
> }
>
Well, this may be meaningful in some cases but it is also risky, if
multiple augementations start to disagree on what should be the
default of some other leaf. Alternatively, you could report the value
foo=10 with the origin "system". For most clients, it likely does not
matter much whether foo=10 is reported with origin=default or
origin=system if the default derivation logic becomes more complex.
For me personally, if there is more complex logic involved in deriving
a value for a leaf (i.e., the existence of other leafs or values of
other leafs matter), then I would rather call it a system provided
value and not a default value.
/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
Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
) (DOI: 10.17487/RFC8328) WGs/RGs that at least partially related to policy-based management: - Simplified Use of Policy Abstractions WG (supa) (2015 - 2017) - Policy Framework WG (policy) (1998 - 2004) - Resource Allocation Protocol WG (rap) (1997 - 2005) - Distributed Management WG (disman) (1996 - 2006) - Services Management RG (smrg) (2019? - 2001?) - Network Management RG (nmrg) - draft-clemm-nmrg-dist-intent (2017-2019) - draft-irtf-nmrg-ibn-concepts-definitions-02.txt (2019-2020) Other resources: - https://en.wikipedia.org/wiki/Policy-based_management - https://www.youtube.com/watch?v=E_v-of582xg - Boutaba, R. and I. Aib, "Policy-Based Management: A Historical Perspective". Journal of Network and Systems Management (JNSM), Springer, Vol. 15 (4), December 2007. https://doi.org/10.1007/s10922-007-9083-8 - Pavlou, G., "On the Evolution of Management Approaches, Frameworks and Protocols: A Historical Perspective". Journal of Network and Systems Management (JNSM), Springer, Vol. 15 (4), December 2007. https://doi.org/10.1007/s10922-007-9082-9 - Strassner, J., "Policy-Based Network Management: Solutions for the Next Generation", Morgan Kaufmann, December 2003. On Tue, Dec 29, 2020 at 04:26:12PM -, Adrian Farrel wrote: > Hi Juergen, > > What you say about learning lessons from the past is wise and valuable. > > Sadly (well, it's a good thing, really) we have new people in the IETF and > the memory of events over the last 20 years are not immediately accessible > to them. Others, who are old and grey, have been around that long but were > not necessarily involved in previous ECA discussions. > > Since "intent-based networking" is a big thing once again (see recent > reports of acquisitions in this sector) the excitement about ECA may be > forgiven, but it would help to ground the discussions if those who can > remember previous efforts would share their experiences or at least some > pointers. > > Best, > Adrian > > -Original Message- > From: netmod On Behalf Of Juergen Schoenwaelder > Sent: 23 December 2020 18:09 > To: Andy Bierman > Cc: NetMod WG Chairs ; NETMOD Group > > Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10 > > On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote: > > On Wed, Dec 23, 2020 at 3:14 AM tom petch wrote: > > > > > From: netmod on behalf of Dhruv Dhody < > > > dhruv.i...@gmail.com> > > > Sent: 21 December 2020 17:12 > > > > > > Hi Lou, WG, > > > > > > I find the motivation in the Introduction to be focused on ECA at the > > > network devices (with all the talk about issues with Centralized > > > network management). > > > > > > I see the value of ECA on the controller as well, say a customer > > > network controller or an orchestrator can set the ECA on a central > > > controller (reference ACTN in TEAS WG). Perhaps you would consider > > > adding a sentence to describe this as well. The client-server > > > terminology in the rest of the document covers it already. > > > > > > And I do see value in this and support adoption. > > > > > > > > > My take is that the I-D is unclear on what ECA is. > > > > > > ECA has been worked on in at least two IETF WG AFAICT. It cropped up in > > > I2RS but as I recall, it was along the lines of 'This is ECA' 'No It is > > > not' 'Yes it is' which gave me the impression that ECA is not a > > > well-defined, or well-understood, term. > > > > > > More recently, I2NSF have produced a YANG capability-data-model which is > > > 55 pages of ECA. Lacking a definition in this netmod I-D, I am unclear > > > what the relationship is between the I2NSF I-D and the netmod I-D, > whether > > > or not they are using ECA in the same sense. > > > > > > > > Hi Tom, > > > > It usually helps to agree on the problem-space before focusing on the > > solution-space. > > ECA seems like a methodology (ala MVC) more than anything else. > > The problem statement seems to be that some client tasks need to be > handled > > on the > > server using ECA methodology, instead of on the client. > > Which tasks? Seems to be any task of arbitrary purpose or complexity. > > And now the scope is supposed to include controllers (just another > client), > > so the problem-stmt > > is even less clear. > > > > The traditional approach is to pick specific client tasks to move to the > > server. > > The example of detecting and reporting route-flaps has been used. > > (No E
Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
On Wed, Dec 23, 2020 at 07:08:52PM +0100, Juergen Schoenwaelder wrote: > > ECA work has a long 20+ year tradition in the IETF and several > specifications have been published over the years by various working > groups. As far as I can tell, none of them got traction in terms of > signifiant deployment of interoperable implementations. > > I would have hoped that the next iteration of ECA work would have > started with a deep reflection about why all the previous attempts > failed to gain traction and some genuine insights how to design things > differently in order to improve the likelihood to have impact. > Let me be a bit more explicit. I would have expected that the senior IETF people mentioned as co-authors or contributors, who are very well familiar with the relevant history (Benoit Claise, Andy Bierman, Alex Clemm), would have explained here (or in the document) why this approach to create an interoperable standard for ECA has potential to succeed given the limited success of the prior attempts. Adopting this work without having answered this question seems premature. If the proponents of this work do not have an answer to this question, the WG will likely not find one either. /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
Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote: > On Wed, Dec 23, 2020 at 3:14 AM tom petch wrote: > > > From: netmod on behalf of Dhruv Dhody < > > dhruv.i...@gmail.com> > > Sent: 21 December 2020 17:12 > > > > Hi Lou, WG, > > > > I find the motivation in the Introduction to be focused on ECA at the > > network devices (with all the talk about issues with Centralized > > network management). > > > > I see the value of ECA on the controller as well, say a customer > > network controller or an orchestrator can set the ECA on a central > > controller (reference ACTN in TEAS WG). Perhaps you would consider > > adding a sentence to describe this as well. The client-server > > terminology in the rest of the document covers it already. > > > > And I do see value in this and support adoption. > > > > > > My take is that the I-D is unclear on what ECA is. > > > > ECA has been worked on in at least two IETF WG AFAICT. It cropped up in > > I2RS but as I recall, it was along the lines of 'This is ECA' 'No It is > > not' 'Yes it is' which gave me the impression that ECA is not a > > well-defined, or well-understood, term. > > > > More recently, I2NSF have produced a YANG capability-data-model which is > > 55 pages of ECA. Lacking a definition in this netmod I-D, I am unclear > > what the relationship is between the I2NSF I-D and the netmod I-D, whether > > or not they are using ECA in the same sense. > > > > > Hi Tom, > > It usually helps to agree on the problem-space before focusing on the > solution-space. > ECA seems like a methodology (ala MVC) more than anything else. > The problem statement seems to be that some client tasks need to be handled > on the > server using ECA methodology, instead of on the client. > Which tasks? Seems to be any task of arbitrary purpose or complexity. > And now the scope is supposed to include controllers (just another client), > so the problem-stmt > is even less clear. > > The traditional approach is to pick specific client tasks to move to the > server. > The example of detecting and reporting route-flaps has been used. > (No ECA example of this complexity has been provided yet). > The traditional approach would be to write a route-flap-detection YANG > module with some > configuration, monitoring data, and notification events. > > The generalized approach is likely to be extremely complex to standardize > and implement. > ECA work has a long 20+ year tradition in the IETF and several specifications have been published over the years by various working groups. As far as I can tell, none of them got traction in terms of signifiant deployment of interoperable implementations. I would have hoped that the next iteration of ECA work would have started with a deep reflection about why all the previous attempts failed to gain traction and some genuine insights how to design things differently in order to improve the likelihood to have impact. /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
Re: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)
If module A imports from module B, then the question whether a change in module B is compatible or not for module A is answered by what module A actually uses of module B's definitions. The question is not answered by module B's version number. The maintainer of module B can't tell whether her change breaks module A without knowing A. And the maintainer of A can't predict how module B will change in the future. As a consequence, the maintainer of A cannot realiably decide whether revision-or-derived or revision-or-derived-compatible is the right choice. The author of A has to _guess_, having more options to guess may help, or it may not. My point is that it is always a guess. The maintainer of module B may be acting in a conservative way and bumping major numbers frequently (and many times not affecting module A) or maintainer B may be lenient - and B's decision may be influenced by how central module B is, the more modules depend on B, the higher the pressure to not bump the major version number of B and to either avoid non-backwards compatible changes or to label them as compatible (even though it is possible they are not). In some realities, you end up with a need for more complex expressions over the version number space to define which versions are known to work together. And this information is often maintained _outside_ the code artifacts (one advantage being that this makes dependency updates possible without having to touch the files with the definitions). Some examples: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html https://cabal.readthedocs.io/en/latest/developing-packages.html#modules-imported-from-other-packages https://semver.npmjs.com/ Given these examples, one can ask whether decorating the YANG import statement with 'inline' versioning constraints is actually the right way to go. Perhaps dependency constraints are better managed outside. /js On Fri, Dec 11, 2020 at 07:17:22PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > Enclosed are the materials for the Virtual Interim on Monday. Have a good > weekend! > > Rgds, > Jason > ___ > 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
Re: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)
It may help to add a slide explaining the purpose YANG module checksums have. In the packages I-D, there is an explanation what package checksums are good for, but I have not found an explanation why YANG module checksums are useful to have. If the checksum is specific to a certain location (i.e., its scoped to the location), then there is no need to have a universal checksum for a YANG module. But it anyway, it would help to understand that the purpose of the checksum is. /js On Fri, Dec 11, 2020 at 07:17:22PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > Enclosed are the materials for the Virtual Interim on Monday. Have a good > weekend! > > Rgds, > Jason > ___ > 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
Re: [netmod] RFC 8802 (reset to factory defaults) versus RFC 8342 (NMDA)
On Fri, Nov 06, 2020 at 03:31:36PM +, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hi, > > We are a little confused when reading RFC8808 (reset to factory-default > datastore) in relation to the "system configuration" source in figure 2 of > RFC8342. When correctly understanding RFC 8342, the running datastore is > empty when the system starts up after coming from the factory, and 'factory > default' data is entered in the operational datastore as 'system/default > configuration' data. > > RFC 8808 seems to suggest that the running datastore contains > (factory-default, system) data when the system starts up after coming from > the factory. I.e. the understanding is that a reset to factory default brings > the system back to the status as if it comes from the factory, and it is said > the factory default goes into the running, ... > > What exactly is the content of the running datastore when it comes from the > factory? > Could this be clarified? > I consider RFC 8808 an extension that people may implement if their systems do what RFC 8808 describes, namely that the running datastore is bootstrapped from a factory default datastore. (Of course, a system with an empty running datastore after a factory reset may claim to be bootstrapped from an empty factory default datastore.) In other words, I think the answer to "What exactly is the content of the running datastore when it comes from the factory?" is that it is empty. On first boot, on a system implementing RFC 8808, it would be loaded with the content of the factory default datastore and on systems not implementing RFC 8808 it would most likely remain empty. /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
Re: [netmod] Adveritzing submodule in
On Tue, Oct 20, 2020 at 04:28:45PM +0200, Martin Björklund wrote: > Hi, > > Ram Polisetty Subbaiah wrote: > > Thanks Martin, > > > > One more follow up question: > > > > If in case both Client and Server are compatible only with Yang 1.0, > > how client/server are supposed to > > handle capabilities advertisement for submodules? By any chance is it > > a limitation in 1.0? > > If the module uses include-by-revision (which it should ;-) then both > sides know which revisions of the submodules a given revision of the > module refers to. > > In any case, a server that implements YANG 1 can implement YANG > library revision 2016-06-21, which includes info about the submodules. > Perhaps a bit of extra information: The exchange can get very long on systems that support many modules and not every client needs the complete module list every time a connection is (re-)established. This is why the recommendation is to use the YANG library wherever possible, it scales better than the orignal exchange design and it is more flexible. /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
Re: [netmod] Import by revision-date or label vs semantic version
If you change the YANG import semantics, then I think you make an NBC change to YANG. Do the versioning people propose to release YANG 2, which just changes the import semantics and nothing else? That I would have understood from a semantic versioning perspective (where the assumption is that bumping a major version number is not a big deal). Or do the versioning people propose to make an NBC under the covers? /js On Wed, Sep 16, 2020 at 10:48:23PM +, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > We have a practical problem though. YANG NEXT/2.0 is some indeterminate date > in the future. Certainly measured in years (not months) and likely >2. > > But we could really use a lot of this versioning work, including a more > complete solution for importing by revision, now. Maybe we will roll this > into YANG 2.0 but we can take advantage of it years before that will happen. > > If we can add some improvements here, and the downside (i.e. clients/tools > that don't understand the extensions) is no worse than today, then we should > go ahead IMO. > > > The existing import behaviour is ambiguous in RFC 7950, so if multiple > revisions of an imported module are available then two compilers could > produce different schema. It is also quite likely that the compile would just > break if the imported version was too old (i.e. missing dependency) > > Consider this text from RFC8526: > > An NMDA-compliant NETCONF server MUST implement the "ietf-netconf-nmda" > module defined in this document, MUST support the operational state > datastore, and MUST implement at least revision 2019-01-04 of the > "ietf-yang-library" module defined in > [RFC8525<https://tools.ietf.org/html/rfc8525>]. > > Notice the "at least revision 2019-01-04". > > As another example: RFC8572 Secure Zero Touch Provisioning (SZTP) imports > ietf-yang-types in order to use hex-string. But hex-string was only > introduced in the second standard version of ietf-yang-types in rfc 6991. So > the import should be something like "revision 2013-07-15 or derived;". > > Rgds, > Jason > > > From: netmod On Behalf Of Andy Bierman > Sent: Wednesday, September 2, 2020 10:52 AM > To: Juergen Schoenwaelder ; Rob Wilton > (rwilton) ; netmod@ietf.org > Subject: Re: [netmod] Import by revision-date or label vs semantic version > > > > On Wed, Sep 2, 2020 at 3:55 AM Juergen Schoenwaelder > mailto:j.schoenwael...@jacobs-university.de>> > wrote: > I continue to have a problem with changing YANG import semantics using > extension statements. Versioning people should understand that this is > an NBC change and hence they should request that the YANG version > number is changed. > > +1 > > IMO it is a huge mistake to think YANG will be easier to use in the long run > by > adding optional extensions to YANG 1.1 instead of introducing a new language > version. > YANG 1.1 will splinter into several dialects, all relying on different > subsets of an ad-hoc > set of language extensions. > > > /js > > > Andy > > > On Wed, Sep 02, 2020 at 10:51:38AM +, Rob Wilton (rwilton) wrote: > > Hi, > > > > During the NETMOD 108 meeting I had made a comment that imports using > > revision-or-derived are not done using a semantic version number, but > > instead are done by revision label, which limits how they behave and what > > they are allowed to do. Some participants were concerned that this might > > be confusing or even broken, and the outcome of that short discussion was > > that I should send an email to NETMOD with an example to help explain how > > they are proposed to work. > > > > The main principle here is that the versioning drafts have a clear > > distinction between supporting an abstract version label vs a specific > > version label scheme (such as YANG Semver). > > > > The new "revision-or-derived" extension is defined as part of base > > draft-ietf-netmod-yang-module-versioning. The "revision-or-derived" > > extension takes a single argument that can either be a "revision date" or a > > "revision label". It can be used regardless of the versioning scheme that > > is being used as a revision label, but therefore is also restricted to > > treating the revision label as an opaque textual label for a revision date. > > > > So, making use of the examples in section 4.1 of > > https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-01 > > > > When a module has an import statement like this: > > > >import example
Re: [netmod] Import by revision-date or label vs semantic version
I continue to have a problem with changing YANG import semantics using
extension statements. Versioning people should understand that this is
an NBC change and hence they should request that the YANG version
number is changed.
/js
On Wed, Sep 02, 2020 at 10:51:38AM +, Rob Wilton (rwilton) wrote:
> Hi,
>
> During the NETMOD 108 meeting I had made a comment that imports using
> revision-or-derived are not done using a semantic version number, but instead
> are done by revision label, which limits how they behave and what they are
> allowed to do. Some participants were concerned that this might be confusing
> or even broken, and the outcome of that short discussion was that I should
> send an email to NETMOD with an example to help explain how they are proposed
> to work.
>
> The main principle here is that the versioning drafts have a clear
> distinction between supporting an abstract version label vs a specific
> version label scheme (such as YANG Semver).
>
> The new "revision-or-derived" extension is defined as part of base
> draft-ietf-netmod-yang-module-versioning. The "revision-or-derived"
> extension takes a single argument that can either be a "revision date" or a
> "revision label". It can be used regardless of the versioning scheme that is
> being used as a revision label, but therefore is also restricted to treating
> the revision label as an opaque textual label for a revision date.
>
> So, making use of the examples in section 4.1 of
> https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-01
>
> When a module has an import statement like this:
>
>import example-module {
> rev:revision-or-derived 2.0.0;
>}
>
> Then the processing to find a suitable revision to import would be something
> like this (ignoring the issue of which revision is chosen from the set of
> suitable candidate revisions):
>
> 1) Iterate suitable candidate "example-module" YANG files.
> 2) For each candidate file, parse the revision history, and check back
> through the revision history to see if a revision with label "2.0.0" exists.
> If it does, then that module revision is a suitable candidate for import. If
> no revision with label "2.0.0" exists then that module revision does not
> satisfy the import. Note the tooling does not need to understand the format
> of the revision label at all, a textual comparison between labels is
> sufficient.
>
> The algorithm works equivalently if the import was done using a revision date
> instead of a label (e.g., rev:revision-or-derived 2019-02-01), except that
> obviously the comparison in the revision history is done on the revision date
> rather than the revision labels.
>
>
> ---
>
> So, how does this interact with YANG Semver (or vanilla Semver 2.0.0)?
>
> Well, this still works because each version of a YANG module contains the
> revision history back to the root of the version tree.
>
> E.g., the YANG file defining version 2.2.0 would contain revisions for
> versions 2.2.0, 2.1.0, 2.0.0, 1.0.0 in its revision history, and hence would
> satisfy an import using label "2.0.0" or derived" solely because a revision
> with that label exists in its revision history.
>
> However, if the revision history had entries pruned (i.e., perhaps 2.1.0
> hadn't been included in the revision history so that it was just 2.2.0,
> 2.0.0, 1.0.0) then this particular YANG file for version 2.2.0 WOULD NOT
> satisfy an import for "revision-or-derived 2.1.0;" because the module's
> revision history does not contain revision 2.1.0.
>
> So, the import revision-or-derived works fine for Semver version labels as
> long as the revision history is consistent and complete.
>
> ---
>
> Finally, there has been some discussion about whether it would be useful to
> have an import statement that restricts imports to only backwards compatible
> versions - I'll post a separate email on this.
>
> If the WG decided that this is useful, then this could still be supported,
> and without needing to understand the revision label. Instead, it can be
> done by checking the revision history for the "rev:nbc-changes" substatement
> that indicates where NBC changes have occurred in the revision history. As
> long as the allocated YANG Semver revision labels are consistent with the use
> of the rev:nbc-changes" substatement in the revision history then it would
> still behave in the intuitive way.
>
>
> Regards,
> Rob
>
> [As an individual contributor]
>
>
> ___
> netmod mailing list
>
Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
On Sun, Aug 30, 2020 at 10:40:36AM +, Qin Wu wrote: > > Wrong. The semantics of the counter types provided by ietf-yang-types are > well defined. > > [Qin]: I agree counter types in ietf-yang-types are well defined. > If counter types can help distinguish avg value from min, max, sum value, > current value, I am > happy to adopt it, however I fail to see ietf-yang-types can do that and I > don't think distinguishing avg from min,max etc > is the job of ietf-yang-types. It add complexity if going with that > direction, in my understanding. You miss my point: The specification of a leaf needs to be clear what it is. If it is not clear, then the specification is buggy. /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
Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
On Thu, Aug 27, 2020 at 05:21:13PM +, Joe Clarke (jclarke) wrote: > > If I make a non-backwards compatible change to the definition of > object-identifier in ietf-yang-types, then likely >98% of the modules > importing ietf-yang-types will not at all be affected by this. Still I > would have to declare a major version change triggering a lot of 'uhm, > ehm, what'. Expressing incompatibilities at the module level is pretty > arbitrary since the way definitions are organized into modules is > already somewhat arbitrary. > > I feel the hint is still helpful, especially for those that may be in the <2% > group, whereas not causing an undue burden given that without it, that >98% > group would have to take every module change and analyze them for relevant > changes. > If you mark the definitions that changed, tools can do the work to figure out whether importing modules are affected or not. This is relatively straight forward for a compiler that already knows what is used and what is not used, this does not require much magic. Instead, the approch taken here is to provide a somewhat vague warning indicator (the version number) at the module level and then you rely on tools (or humans) to identify semantic changes. And tools will likely fail if semantics in descriptions have changed or they will fail to decide whether two regular expressions are backwards compatible or not or if a must statement is equivalent to a previous when statement in a certain context. For the person making the change, however, it is fairly easy to leave a mark since he/she can be expected to understand the nature of the change. It turns out that we already have some marks in the form of the status statement. We can mark definitions as deprecated or obsolete. We do not have a value to say 'changed' in an nbc way and we do not have a mechanism to document the history of status changes for a given definition, but that is easy to engineer into YANG. /js PS: I assume that we focus on 'published' YANG modules where the nbc change churn is reasonably under control. During active development phases, modules may undergo many little (nbc) changes but dealing with them should be left to version management systems. -- 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
Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
On Wed, Aug 26, 2020 at 05:43:27PM +, Joe Clarke (jclarke) wrote: > > > > On Aug 13, 2020, at 06:23, Juergen Schoenwaelder > > wrote: > > > > On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote: > >> > >> > >> $ pyang -f yin ietf-inet-types.yang | xmllint --c14n - | sha256sum > >> 8d1ca8f30566ce8cbeffa095e20642f8f6e9f3a724286be4ead863b4467dc40b - > >> > >> might be a very good start. It is certainly much more robust than > >> relying on a simple checksum of the YANG module text. > > > > This work started with the need for _semantic_ version numbers and now > > we are down to hashes of modules? Do we still have a clear idea which > > problem we are solving? > > Sorry for the delay. I was traveling and then trying to get caught back up. > Yes, things got off track a bit here. > > > > > - Sane development environments use version control systems, we should > > in my view not attempt to go there. We should assume that people > > developing YANG modules use version control systems to track > > changes. > > Agreed. And through that development, we are not trying to impose any > versioning up to the point that a module would be published (e.g., in a draft > where it might be implemented). Certainly, people could also pull and > implement any arbitrary revision from a VCS, but we haven’t created any text > to cover that (nor do I think we want to impose that each commit revs some > version in the module itself). > > > > > - There apparently is a need for a packaging system that can express > > which combinations of YANG module version are known to work > > together. > > > > The YANG versioning work was driven (I think) by the desire to > > support non-backwards compatible changes (section 4 of > > draft-ietf-netmod-yang-versioning-reqs-03). Why do we end up > > discussing how to calculate hashes or the impact of whitespace > > changes? Whitespace and layout changes are backwards compatible, > > even today's YANG versioning rules handle them well. > > The intent, at least for the whitespace changes was at a module release time > to indicate what constitutes a version bump. But the question could likely > be rephrased. Would one change the _revision_ of a module for any of the > changes mentioned thus far? And if a new revision is created, and semantic > versioning is used a revision-label scheme, then that revision should have a > new version label. At least this was the opinion of the contributors in the > regular weekly calls. > The goal of the effort was to allow for non-backwards compatible changes. Backwards compatible changes already work today (and white space changes are obviously backwards compatible). If you want to _publish_ a module with just whitespace changes, it is defined how to do this. I would find it way more important to mark which specific definitions had backwards incompatible changes (plus perhaps hints how to deal with them) instead of sticking a label on an entire module and then to let others figure out what this label actually means for them (and ultimately it is then the package maintainer's job to dig out which revision sets can meaningfully work together). If I make a non-backwards compatible change to the definition of object-identifier in ietf-yang-types, then likely >98% of the modules importing ietf-yang-types will not at all be affected by this. Still I would have to declare a major version change triggering a lot of 'uhm, ehm, what'. Expressing incompatibilities at the module level is pretty arbitrary since the way definitions are organized into modules is already somewhat arbitrary. /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
Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
On Mon, Aug 17, 2020 at 10:05:27PM +, Kent Watsen wrote: > This email begins a 2-week adoption poll for: > > https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-05 > > Please voice your support or objections on list before August 31. > > Notes: >1) -03 was presented during the 108 session, hence the I-D has been > updated twice since then. >2) Please be aware that IPR has been filed for this I-D: > > https://datatracker.ietf.org/ipr/search/?submit=draft=draft-tao-netmod-yang-node-tags > > <https://datatracker.ietf.org/ipr/search/?submit=draft=draft-tao-netmod-yang-node-tags>. > I am against adoption. I am against introducing a collection of standards-track extension statements without answering the question who controls, enforces and reviews the usage of these extension statements (when and how are they used). Some statements and tags are either addressing issues caused by underspecified YANG modules or they overlap with the deviation mechanism that we have in place since day one of YANG. Others are very vaguely specified, it is unclear how they will lead to interoperable behavior. If module authors are too lazy to use existing YANG mechanisms properly, does it make sense to add more mechanism to the YANG eco system? I doubt it. /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
Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote: > > > $ pyang -f yin ietf-inet-types.yang | xmllint --c14n - | sha256sum > 8d1ca8f30566ce8cbeffa095e20642f8f6e9f3a724286be4ead863b4467dc40b - > > might be a very good start. It is certainly much more robust than > relying on a simple checksum of the YANG module text. This work started with the need for _semantic_ version numbers and now we are down to hashes of modules? Do we still have a clear idea which problem we are solving? - Sane development environments use version control systems, we should in my view not attempt to go there. We should assume that people developing YANG modules use version control systems to track changes. - There apparently is a need for a packaging system that can express which combinations of YANG module version are known to work together. The YANG versioning work was driven (I think) by the desire to support non-backwards compatible changes (section 4 of draft-ietf-netmod-yang-versioning-reqs-03). Why do we end up discussing how to calculate hashes or the impact of whitespace changes? Whitespace and layout changes are backwards compatible, even today's YANG versioning rules handle them 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
Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
On Tue, Aug 11, 2020 at 05:06:13PM +0200, Martin Björklund wrote: > > 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. > > 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."; +1 I agree since whitespace outside YANG strings is insignificant. Lets raise this to the next level. What about the following? D1. description "A server."; D2. description "A server."; // not very descriptive E1. description "A server."; // not very descriptive E2. // not very descriptive description "A server."; /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
Re: [netmod] submodules the hidden benefits
roblem with trying to compile a sub-module can > > be > > addressed in the tools themselves. > > > > > > On Aug 5, 2020, at 2:44 PM, Reshad Rahman (rrahman) > > mailto:rrahman=40cisco.com@dmarc.i > > etf.org>> wrote: > > > > Indeed > > https://github.com/netmod-wg/yang-next/issues/26 > > > > On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev" > boun...@ietf.org on behalf of vladimir@lightside- > > instruments.com<mailto:netmod- > > boun...@ietf.org%20on%20behalf%20of%20vladimir@lightside- > > instruments.com>> wrote: > > > >On 05/08/2020 18.48, Juergen Schoenwaelder wrote: > > > > > > I personally meanwhile believe that sub-modules add complexity with > > little extra value but this view surely is not shared by others. > > > >+1. IMO removing sub-modules from YANG 2.0 should be on the list of > >proposed changes. > > > >/Vladimir > > > >___ > >netmod mailing list > >netmod@ietf.org<mailto:netmod@ietf.org> > >https://www.ietf.org/mailman/listinfo/netmod > > > > ___ > > 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 -- 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
Re: [netmod] submodules the hidden benefits
As a data point, RFC 7407 uses sub-modules. The sub-modules more or less reflect SNMPv3's modular architecture, the different transports are for example separated out as sub-modules. I guess we also used sub-modules back then because we wanted to see how this works in an IETF context (RFC 7407 was approved/published 6 years ago, we were still learning how to use YANG at that time). I personally meanwhile believe that sub-modules add complexity with little extra value but this view surely is not shared by others. Anyway, people using them should have a good reason for using them. Since SNMPv3 has a great modular architecture, it makes sense to structure the YANG modules accordingly and instead of having many ietf-snmp- modules, sub-modules came in handy to have everything in a single namespace. For technologies that do not have a modular architecture that can be followed, creating modular sub-modules is likely not worth the effort. /js PS: I am not sure that sub-modules are necessarily harder to review. For the crypto YANG modules, we have several intertwined modules, they are likely as complex to review as if they were all sub-modules sharing a single namespace - or a single module with all definitions in one big module. On Wed, Aug 05, 2020 at 04:20:17PM +, tom petch wrote: > Looking at an I-D with endless submodules, I am left thinking > > Costs > > greater in size > more complex to understand > harder to review > more likely to have undetected errors > > Benefits > > > > What am I missing? I have only ever seen one such module in the IETF that I > can recall and it is draft-ietf-idr-bgp-model and AFAICT it would be smaller, > simpler, easier to understand if it were done with grouping instead of > submodule. > > Tom Petch > > ___ > 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
Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code
Having skimmed draft-ietf-netmod-geo-location-05.txt again, I agree
that people should use the grouping. The examples in Appendix A make
it pretty clear that it is possible to report minimal values if that
is desirable but having the flexibility to report more details may
come in handy where needed.
As far as rfc6991bis is concerned, it is clear that there is nothing
to be done for latitude and longitude.
/js
On Fri, Jul 31, 2020 at 04:34:17AM -0400, Christian Hopps wrote:
> The point of the grouping is to not cut corners, and that it was vetted by
> experts in the field. Just re-using some typedefs of lat/long/height is not
> sufficient. You must also talk about the reference system which defines the
> meaning of those values, and know what you are talking about. It matters.
> Providing typedef's would suggest that it was OK to just re-use those values
> alone, when in fact it is not. If you read through the document you will see
> comparisons to other geographic location specifications. None of them just
> define "lat/long" as decimal degrees and call it done, as that is not
> sufficient.
>
> Why shouldn't the grouping be used as is here? Nothing says that the software
> has to support every possible variation of data. Yes, the grouping allows
> specifying many types of coordinates (e.g., on the Moon), but that does not
> mean that the software that uses the grouping has to actually support those
> inputs.
>
> In fact, If you look at the case we are talking about here, there's not only
> no reason to be limiting the geo-location, it's literally the use-case that
> drove me to create the grouping and its generality (i.e., locating network
> elements for a telecom and its management system).
>
> Thanks,
> Chris.
>
> > On Jul 30, 2020, at 9:32 PM, Qin Wu wrote:
> >
> > Thanks Chris and Jurgen for clarification,
> > Chris, I am not sure I catch what you said. Does adding new typedef for
> > longtitude and latitude do harm to draft-ietf-netmod-geo-location-05?
> > Type in my opinion is more reusable building block.
> >
> > -Qin
> > 发件人: Christian Hopps [mailto:cho...@chopps.org <mailto:cho...@chopps.org>]
> > 发送时间: 2020年7月31日 0:38
> > 收件人: Juergen Schoenwaelder > <mailto:j.schoenwael...@jacobs-university.de>>
> > 抄送: Christian Hopps mailto:cho...@chopps.org>>; Qin Wu
> > mailto:bill...@huawei.com>>; netmod@ietf.org
> > <mailto:netmod@ietf.org>; netmod-cha...@ietf.org
> > <mailto:netmod-cha...@ietf.org>
> > 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude,
> > yang:postal-code, yang:country-code
> >
> > I received specific external feedback from the geo experts to just use a
> > number instead of a type. I think they may have been thinking that it would
> > be easier to redefine the values meaning for different systems.
> >
> > Thanks,
> > Chris.
> >
> >
> > On Jul 30, 2020, at 12:23 PM, Juergen Schoenwaelder
> > > <mailto:j.schoenwael...@jacobs-university.de>> wrote:
> >
> > Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
> > defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
> > has:
> >
> > +--ro geolocation
> > +--ro altitude?int64
> > +--ro latitude?geographic-coordinate-degree
> > +--ro longitude? geographic-coordinate-degree
> >
> > You might simply use the grouping here that comes out of
> > draft-ietf-netmod-geo-location-05 - but then the grouping is
> > also a bit more complex than what you have.
> >
> > Unfortunately, draft-ietf-netmod-geo-location-05 does not define
> > helper types. The latitude and longitude leafs are simply decimal64s
> > with all details spelled out inline:
> >
> > leaf latitude {
> > type decimal64 {
> > fraction-digits 16;
> > }
> > units "decimal degrees";
> > description
> > "The latitude value on the astronomical body. The
> > definition and precision of this measurement is
> > indicated by the reference-frame value.";
> > }
> > leaf longitude {
> > type decimal64 {
> > fraction-digits 16;
> > }
> > units "decimal degrees";
> > description
> > "The longitude value on the astronomical body. The
> > definition an
Re: [netmod] Follow-up: impact of changing an import statement
On Sat, Aug 01, 2020 at 02:51:54AM +, Reshad Rahman (rrahman) wrote: > WG, > > Following up from the discussions during NETMOD meeting on Thursday. One of > the main open topics is what to do when an import stmt is changed, for example > > 1. Module A (1.0.0) imports module B using “2.0.0 or derived”. There is no > version 3+ for module B so module A uses 2.Y.Z > 2. A new revision 3.0.0 of module B is created AND there is a change in > module A to import module B using “3.0.0 or derived”. What does "2.0.0 or derived" mean? Does it mean (i) any module >= 2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)? > Authors/contributors have discussed 2 options and right now we don’t have > unanimity: > > 1. Option A: depending on the impact on the importing module A, the > import-stmt is deemed BC or NBC. E.g. if the only NBC change in the imported > module is to a type which the importing module does NOT use, that’s a BC > change for the importing module. > 2. Option B: consider the import-stmt change as a BC change and resolve > this elsewhere e.g. YANG-Packages or YANG-Library. Whether a change is BC or not always depends on which definitions have changed, how they have changed, and how these definitions are used. So the answer very likely must be option 1. Option 2 also seems to push the problem elsewhere (packages, library) without providing the details. /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
Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code
Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
has:
+--ro geolocation
+--ro altitude?int64
+--ro latitude?geographic-coordinate-degree
+--ro longitude? geographic-coordinate-degree
You might simply use the grouping here that comes out of
draft-ietf-netmod-geo-location-05 - but then the grouping is
also a bit more complex than what you have.
Unfortunately, draft-ietf-netmod-geo-location-05 does not define
helper types. The latitude and longitude leafs are simply decimal64s
with all details spelled out inline:
leaf latitude {
type decimal64 {
fraction-digits 16;
}
units "decimal degrees";
description
"The latitude value on the astronomical body. The
definition and precision of this measurement is
indicated by the reference-frame value.";
}
leaf longitude {
type decimal64 {
fraction-digits 16;
}
units "decimal degrees";
description
"The longitude value on the astronomical body. The
definition and precision of this measurement is
indicated by the reference-frame.";
}
The teas document has
typedef geographic-coordinate-degree {
type decimal64 {
fraction-digits 8;
}
description
"Decimal degree (DD) used to express latitude and longitude
geographic coordinates.";
}
leaf latitude {
type geographic-coordinate-degree {
range "-90..90";
}
description
"Relative position north or south on the Earth's surface.";
}
leaf longitude {
type geographic-coordinate-degree {
range "-180..180";
}
description
"Angular distance east or west on the Earth's surface.";
}
Note also the differences in the precision. Obviously,
draft-ietf-netmod-geo-location-05 could have defined
helper types like
typedef latitude {
type decimal64 {
fraction-digits 16;
}
units "decimal degrees";
description
"The latitude value on the astronomical body.";
}
typdef longitude {
type decimal64 {
fraction-digits 16;
}
units "decimal degrees";
description
"The longitude value on the astronomical body. The
definition and precision of this measurement is
indicated by the reference-frame.";
}
and a bunch more and used them to define the leafs. These types could
then have been reused in situations where the grouping in all its
details is not needed.
I am not entirely sure where draft-ietf-netmod-geo-location-05 is in
the WG process, the datatracker says "In WG Last Call, Revised I-D
Needed - Issue raised by WGLC" - so perhaps there is a chance to get
the inline type definitions factored out so that they can be reused.
I think this is something where the input from Chris Hopps and the
NETMOD chairs is important to determine the path forward. Since we
have an ietf-geo-location module, I would prefer to have common types
for location information defined there and not in yang-types.
/js
On Thu, Jul 30, 2020 at 04:02:51PM +0200, Juergen Schoenwaelder wrote:
> But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
> or you need to use a grouping. I think we should not have overlapping
> work in different documents.
>
> /js
>
> On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> > That is a good option, but draft-ietf-netmod-geo-location-05 only define
> > grouping, there is typedef for longitude and latitude, altitude.
> >
> > -Qin
> > -邮件原件-
> > 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> > 发送时间: 2020年7月30日 21:32
> > 收件人: Qin Wu
> > 抄送: netmod@ietf.org
> > 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude,
> > yang:postal-code, yang:country-code
> >
> > But there is draft-ietf-netmod-geo-location-05... What about using the
> > types defined in there?
> >
> > /js
> >
> > On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which
> > > defines longitude and latitude, altitude.
> > > I know it is beneficial for future document to import these types from
> > > rfc6991bis instead of from te topo model.
> > >
> > > -Qin
> > > -邮件原件---
Re: [netmod] rfc6991bis: yang:percentage
On Thu, Jul 30, 2020 at 04:48:41PM +0100, William Lupton wrote: > except that percent doesn't really seem like a routing-specific data type! > > (perhaps the "right" thing to do is to deprecate, and eventually obsolete, > the routing one and define it in a core netmod module?) > Yes, the percentage type is not not routing specific. But if we choose to go down this route, we likely have to move more definitions, I also see timeticks64 and uint24 in RFC 8294 that don't seem to be routing specific. Since RFC 8294 comes from a different WG in a different IETF "area", deprecation requires some internal communication and collaboration (but not deprecating also won't hurt much for these fairly simple types). /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
Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code
But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated or you need to use a grouping. I think we should not have overlapping work in different documents. /js On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote: > That is a good option, but draft-ietf-netmod-geo-location-05 only define > grouping, there is typedef for longitude and latitude, altitude. > > -Qin > -邮件原件- > 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] > 发送时间: 2020年7月30日 21:32 > 收件人: Qin Wu > 抄送: netmod@ietf.org > 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, > yang:country-code > > But there is draft-ietf-netmod-geo-location-05... What about using the types > defined in there? > > /js > > On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote: > > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines > > longitude and latitude, altitude. > > I know it is beneficial for future document to import these types from > > rfc6991bis instead of from te topo model. > > > > -Qin > > -邮件原件- > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder > > 发送时间: 2020年7月18日 3:16 > > 收件人: netmod@ietf.org > > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, > > yang:postal-code, yang:country-code > > > > - It was suggested to add types for longitude, latitude, postal > > code, country-code. Do we go there or do we leave these for other > > modules to define? It seems such definitions should go into > > draft-ietf-netmod-geo-location. > > > > - Geo location is covered by draft-ietf-netmod-geo-location > > (so do nothing). > > > > - For country codes, there is ISO 3166, which defines two-letter, > > three-letter, and numeric country codes. I assume people wanted > > two-letter codes (as used in the DNS), i.e. they want DE and not > > DEU. But note that it is GB and not UK, i.e., what we commonly > > use in the DNS may not be exactly ISO 3166. (The devil is always > > in the details.) > > > > - For postal codes, it is unclear what the requirements are or what > > a proper definition for postal codes is. It is not entirely clear > > what the authoritative definition of the format of postal codes > > is, perhaps the Universal Postal Union. > > > > - Options: (i) do nothing or (ii) add a country code definition > > only or (iii) add both a country code definition and a postal > > code definition (which might be to some extend vague) > > > > - Proposal: do nothing > > > > -- > > 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 > > -- > 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 https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] rfc6991bis: loopback addresses
Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang. With that, your request is relatively clear now and the question the WG needs to answer is whether these types are common enough to warrant being part of inet-types, i.e., are there any other places where these types may be useful? /js On Thu, Jul 30, 2020 at 01:19:11PM +, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > As Reshad mentioned, RFC8029 uses internal host loopback address > (127..0.0.0/8 range as defined in section 4.2.2.11 of RFC1812). The YANG > module for LSP Ping (RFC8029) defined in draft-nainar-mpls-lsp-ping-yang is > using this address and so we felt it will be good to have the same included > in the right document. > > Thanks, > Nagendra > > On 7/20/20, 2:54 PM, "Reshad Rahman (rrahman)" wrote: > > Hi, > > I think what you're referring to is the use of "loopback interfaces". The > loopback addresses Juergen was referring to do not belong to loopback > interfaces. > > Regards, > Reshad. > > > On 2020-07-20, 11:30 AM, "tom petch" wrote: > > From: Reshad Rahman (rrahman) > Sent: 20 July 2020 14:39 > > I don't understand the comment "...implementation choice of one > manufacturer." > > > Go back to the early specifications of IPv4 routers and routing > protocols, which are still the ones we use today, and loopback was a state > into which an interface could be put, with a loop back in hardware or > software, often used for testing. A router had a router id, a 32 bit number > with no syntax. One major manufacturer conflated parts of this and created a > virtual address or addresses which could be used to send and receive packets > for the router, as opposed to an interface on the router, which had no > physical manifestation; fine until they called it the loopback address(es) > which, sadly, caught on and many people, included those writing IETF I-D > think that the router id can only be such a routable address. Some even > think that there can only be one such address on a box, as opposed to one for > network management, one for the control plane and so on. Not so. > > Tom Petch. > > As for the details, see > https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00 > > Regards, > Reshad. > > > On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" > wrote: > > I am not a fan of loopback seeing it as the implementation choice > of one manufacturer. On the other hand, the IETF has defined documentation > addresses which many if not most writers of examples for YANG modules seem > unaware of so if we add anything, I would add those. > > Tom Petch > > From: netmod on behalf of Juergen > Schoenwaelder > Sent: 17 July 2020 20:25 > > - There was a request to add types for loopback addresses > (127.0.0.0/8 and ::1/128). > > - This is related to an effort to define a YANG module for MPLS > LSP > Ping (RFC 8029) but the details are unclear, i.e., what is > exactly > needed and how such a type will be used and whether there is a > common need for types for loopback addresses. > > - Proposal: do not add such types at this point in time > > -- > 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 > > > -- 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
Re: [netmod] rfc6991bis: inet:host
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?
> 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
--
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
Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code
But there is draft-ietf-netmod-geo-location-05... What about using the types defined in there? /js On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote: > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which defines > longitude and latitude, altitude. > I know it is beneficial for future document to import these types from > rfc6991bis instead of from te topo model. > > -Qin > -邮件原件- > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder > 发送时间: 2020年7月18日 3:16 > 收件人: netmod@ietf.org > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, > yang:country-code > > - It was suggested to add types for longitude, latitude, postal > code, country-code. Do we go there or do we leave these for other > modules to define? It seems such definitions should go into > draft-ietf-netmod-geo-location. > > - Geo location is covered by draft-ietf-netmod-geo-location > (so do nothing). > > - For country codes, there is ISO 3166, which defines two-letter, > three-letter, and numeric country codes. I assume people wanted > two-letter codes (as used in the DNS), i.e. they want DE and not > DEU. But note that it is GB and not UK, i.e., what we commonly > use in the DNS may not be exactly ISO 3166. (The devil is always > in the details.) > > - For postal codes, it is unclear what the requirements are or what > a proper definition for postal codes is. It is not entirely clear > what the authoritative definition of the format of postal codes > is, perhaps the Universal Postal Union. > > - Options: (i) do nothing or (ii) add a country code definition > only or (iii) add both a country code definition and a postal > code definition (which might be to some extend vague) > > - Proposal: do nothing > > -- > 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 -- 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
Re: [netmod] rfc6991bis: yang:percentage
On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:
> On 20/07/2020 11:19, Ladislav Lhotka wrote:
> > 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.
> On the other hand, when I look at the numerous percent/percentage
> occurrences in YANG model, it doesn't hurt to define that typedef.
>
> https://yangcatalog.org/yang-search/ => search on "node name" and typedef
> only
> We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
> Most of them points to:
>
>*typedef* percent {
> *type* uint8 {
> *range* "0 .. 100";
>
> }
>}
>
But that one is already defined in RFC 8294 in ietf-routing-types.
Does it make sense to define it again in yang-types?
/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
Re: [netmod] rfc6991bis: inet:host
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. > 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. 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/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"
On Mon, Jul 27, 2020 at 12:33:39PM +, Qin Wu wrote: > -邮件原件- > 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] > 发送时间: 2020年7月27日 18:42 > 收件人: Qin Wu > 抄送: netmod@ietf.org > 主题: Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in > state "Candidate for WG Adoption" > > On Mon, Jul 27, 2020 at 10:13:43AM +, Qin Wu wrote: > > > > On the technical side, it is not clear why a central list of tags providing > > meta information is preferrable over metadata annotations that can be > > shipped with the values. > > > > > > [Qin]: If we take metadata annotation approach, we need to define new > > module for each device level modules such as interface module, IP > > management module, BGP module, QoS module deployed in the device or revise > > these modules that has already been published and update devices with these > > new modules corresponding to deployed device level modules. Suppose the > > device level modules that has been deployed in the device is huge, such > > metadata annotation solution require update on each device for the new > > modules, the number of new modules is same as the number of existing > > deployed device level modules, which doesn't scale well. > > > > I do not think this answer is technically correct. For a counter example, see > the definition of md:annotation origin in RFC 8342. > > [Qin]:umm, have a second thought, I think this is the design choice we made, > we did investigate metadata annotation approach, but the essence of metadata > annotation is to add attribute to the model, we think adding attributes still > have limitation, since you can not add too many attributes one time to the > same xml element. > Secondly, we need to know which data is the characteristics data or telemetry > data category the client want to subscribe before sending subscription > request to the server. If we take metadata annotation approach, we need to > have at least two times subscriptions before finding targeted data objects, > or first retrieve telemetry data tag from the server and then subscribe > targeted data object. It is hard to automate subscription with metadata > annotation approach. I do not think there is a restriction of the number XML attributes. You can simply send a get operation. You will need a get operation as well for your central list of tags. > > It does not seem harmful to adopt this work if people think this is needed > > and they are willing to work on this. The others can safely ignore this > > with. Personally, I am not convinced yet, but then I do not work on > > 'multiple dimensional network visibility analysis'. > > Perhaps a good convincing concrete example would help, the tables in Fig. 2 > > do not help me much. > > > > [Qin]: Suppose we can classify telemetry data from different angles, > > we can tag the telemetry data with various different data object tag, > > e.g., whether the data object is performance metric data, which category > > the performance metric data belong, if the data object Is performance > > metric data or KPI data, we can further classify KPI data from operation > > type, e.g., whether KPI data is average value, minimum value, maximum > > value, whether KPI data allow set threshold for it, if the KPI data can > > come from multiple source, We can indicate whether KPI data is aggregated > > data or not, so collector can use these telemetry data tag to subscribe > > targeted data object or these telemetry data tag associated with subscribed > > data can be further consumed by big data analytics platform/open > > observability platform such as InfluxDB/grafana and provide different > > outputs based on the telemetry tag or telemetry data classification that is > > selected. > > > > The goal seems to add tags to node instances. I do not understand what they > > are called 'self-explanation-node-tags' and not simply 'node-tags'. > > You assume that the device manufacturer implementing YANG modules can predict > what a management application wants to do with a certain piece of > information. I doubt this is generally true. And if you look at basic > counters, they often serve many different purposes. Even if the WG believes > this to be true, there likely needs an overwrite mechanism in case the > manufacturer predicted things wrongly. > [Qin]: no, it is not always necessary for device manufacturer to do such > prediction, it can be put into offline document together with module schema > for NMS to retrieve. In addition, it allows the device adding or removing tag > in the same
Re: [netmod] rfc6991bis: inet:host
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? /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
Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"
On Mon, Jul 27, 2020 at 10:13:43AM +, Qin Wu wrote: > > On the technical side, it is not clear why a central list of tags providing > meta information is preferrable over metadata annotations that can be shipped > with the values. > > > [Qin]: If we take metadata annotation approach, we need to define new module > for each device level modules such as interface module, IP management module, > BGP module, QoS module deployed in the device or revise these modules that > has already been published and update devices with these new modules > corresponding to deployed device level modules. Suppose the device level > modules that has been deployed in the device is huge, such metadata > annotation solution require update on each device for the new modules, the > number of new modules is same as the number of existing deployed device level > modules, which doesn't scale well. > I do not think this answer is technically correct. For a counter example, see the definition of md:annotation origin in RFC 8342. > It does not seem harmful to adopt this work if people think this is needed > and they are willing to work on this. The others can safely ignore this with. > Personally, I am not convinced yet, but then I do not work on 'multiple > dimensional network visibility analysis'. > Perhaps a good convincing concrete example would help, the tables in Fig. 2 > do not help me much. > > [Qin]: Suppose we can classify telemetry data from different angles, we can > tag the telemetry data with various different data object tag, e.g., whether > the data object is performance metric data, which category the performance > metric data belong, if the data object > Is performance metric data or KPI data, we can further classify KPI data from > operation type, e.g., whether KPI data is average value, minimum value, > maximum value, whether KPI data allow set threshold for it, if the KPI data > can come from multiple source, > We can indicate whether KPI data is aggregated data or not, so collector can > use these telemetry data tag to subscribe targeted data object or these > telemetry data tag associated with subscribed data can be further consumed by > big data analytics platform/open observability platform such as > InfluxDB/grafana and provide different outputs based on the telemetry tag or > telemetry data classification that is selected. > > The goal seems to add tags to node instances. I do not understand what they > are called 'self-explanation-node-tags' and not simply 'node-tags'. You assume that the device manufacturer implementing YANG modules can predict what a management application wants to do with a certain piece of information. I doubt this is generally true. And if you look at basic counters, they often serve many different purposes. Even if the WG believes this to be true, there likely needs an overwrite mechanism in case the manufacturer predicted things wrongly. > [Qin]: The reason to call it as 'self-explanation-node-tag' is to make it > better reflect what it is really aimed for, if you have better name, I am > happy to accept it. Well, to me these look like node instance tags. If anything, I would be interested in a generic solution and not something taylored to one specific use case (telemetry) and this is why I would prefer to have the specific semantics in the tags and not in the set of leafs carrying the tags. /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
Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"
I do not understand the abstract of the document. The main sentence is this one: This YANG data node tagging method can be used to provide input, instruction, indication to selection filter and filter queries of operational state on a server during a "pub/sub" service for YANG datastore updates and provide multiple dimensional network visibility analysis when the state of all subscriptions of a particular Subscriber to be fetched is huge, so that the amount of data to be streamed out to the destination can be greatly reduced and only targeted to the characteristics data. I can follow up to 'multiple dimensional network visibility analysis' and then I am lost. On the technical side, it is not clear why a central list of tags providing meta information is preferrable over metadata annotations that can be shipped with the values. It does not seem harmful to adopt this work if people think this is needed and they are willing to work on this. The others can safely ignore this with. Personally, I am not convinced yet, but then I do not work on 'multiple dimensional network visibility analysis'. Perhaps a good convincing concrete example would help, the tables in Fig. 2 do not help me much. The goal seems to add tags to node instances. I do not understand what they are called 'self-explanation-node-tags' and not simply 'node-tags'. It is also unclear why we need exactly those eight different tag types. How does this relate to YANG defined properties such as units? If there is a mismatch, what takes precedence? If I define tags in a module using the extension statements, why do I also have to have these tags in the instance tree? draft-ietf-netmod-module-tags defines module tags plus mechanisms to tweak them if needed. This document seems to define node instance tags but hidden in a very specific use case. I think the WG should determine whether it wants to work on "YANG Node Instance Tags" along the "YANG Module Tags" work. I personally find the scope of the work behind the current document unclear. /js On Sun, Jul 26, 2020 at 06:56:17AM -0700, IETF Secretariat wrote: > > The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state > Candidate for WG Adoption (entered by Lou Berger) > > The document is available at > https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/ > > Comment: > IPR disclosures: > https://datatracker.ietf.org/ipr/4216/ > Mail poll: > https://mailarchive.ietf.org/arch/msg/netmod/pyk2fLkG8srCuZKg7dDI3ypzKrQ/ > > Liang Geng: > https://mailarchive.ietf.org/arch/msg/netmod/rXb-ZeXzvCQAByu2fFJlbno6tR4/ Du > Zongpeng: > https://mailarchive.ietf.org/arch/msg/netmod/PRfcKZjjttBO4l3hW2VwEKwXJmc/ Ran > Tao: > https://mailarchive.ietf.org/arch/msg/netmod/O54ihWu6g5dnZmkJGHVByX7hpoo/ Qin > Wu: https://mailarchive.ietf.org/arch/msg/netmod/7jdfrEj61mcF2ASE6dDP8zOHfps/ > Benoit Claise: > https://mailarchive.ietf.org/arch/msg/netmod/3C-K4JaAgLnpAoPqcQAn59DFHYw/ > > _______ > 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
Re: [netmod] rfc6991bis: inet:host
So would the following do the right thing?
typedef host-name {
type domain-name {
pattern '[a-zA-Z0-9\-\.]+';
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";
}
/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
Re: [netmod] rfc6991bis: inet:host
On Fri, Jul 24, 2020 at 12:14:17PM +0200, Erik Auerswald wrote: > Hi, > > On Fri, Jul 24, 2020 at 10:36:17AM +0200, Juergen Schoenwaelder wrote: > > On Wed, Jul 22, 2020 at 01:46:38PM +0200, Ladislav Lhotka wrote: > > > On 22. 07. 20 13:00, Juergen Schoenwaelder wrote: > > > > > > > > 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. > > What about single character host names currently used, e.g., > a.root-servers.net.? > > There are single character subdomain labels in use as well, e.g., l.de.. > The description of 'host name' in RFC 8499 explains that host names are considerd to be domain names but in some contexts a host name is considered to be just the first label of a domain name. In our context, however, it is pretty clear that we consider a host name to be a domain name. Hence, what Lada suggests is to formally disallow names like 'a.' while 'a.root-servers.net.' would not be affected. /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
Re: [netmod] rfc6991bis: yang:xpath1.0
On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote: > On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev < > vladi...@lightside-instruments.com> wrote: > > > On 17/07/2020 21.14, Juergen Schoenwaelder wrote: > > > > > - 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. > > > > > > - This interacts with the definition of node-instance-identifier. > > > > > > - 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. > > > > > > - Proposal: ? > > > > > > How about leaving the xpath1.0 type definition as it is and specifying a > > canonical form for the node-instance-identifier where namespace prefixes > > must be module names. > > > > > Since (i) is the only BC option why is (ii) even being considered? > Of course a new type name is needed to change the XPath syntax > to something that is not backward-compatible. > The idea was not to propose something non-backwards compatible but to try to explain how xpath1.0 values work with non-XML encodings. But perhaps this is 'unexplainable' in the sense that people deal with this in different ways. /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
Re: [netmod] rfc6991bis: inet:host
On Fri, Jul 24, 2020 at 10:36:17AM +0200, Juergen Schoenwaelder wrote: > > What is the '(.*\.)?' part doing in your pattern? > OK, I figured it out, the NR-LDH label and be in anywhere in the sequence of labels. /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
Re: [netmod] rfc6991bis: inet:host
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.:
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/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] rfc6991bis: inet:host
Tom, my understanding is that Lada is now proposing something slightly different but I am not sure what exactly, hence I asked again. /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 -- 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
Re: [netmod] rfc6991bis: inet:host
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. /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
Re: [netmod] rfc6991bis: loopback addresses
Adding documentation addresses as a _type_?? /js On Mon, Jul 20, 2020 at 08:46:37AM +, tom petch wrote: > I am not a fan of loopback seeing it as the implementation choice of one > manufacturer. On the other hand, the IETF has defined documentation > addresses which many if not most writers of examples for YANG modules seem > unaware of so if we add anything, I would add those. > > Tom Petch > > From: netmod on behalf of Juergen Schoenwaelder > > Sent: 17 July 2020 20:25 > > - There was a request to add types for loopback addresses > (127.0.0.0/8 and ::1/128). > > - This is related to an effort to define a YANG module for MPLS LSP > Ping (RFC 8029) but the details are unclear, i.e., what is exactly > needed and how such a type will be used and whether there is a > common need for types for loopback addresses. > > - Proposal: do not add such types at this point in time > > -- > 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 -- 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] rfc6991bis: loopback addresses
- There was a request to add types for loopback addresses (127.0.0.0/8 and ::1/128). - This is related to an effort to define a YANG module for MPLS LSP Ping (RFC 8029) but the details are unclear, i.e., what is exactly needed and how such a type will be used and whether there is a common need for types for loopback addresses. - Proposal: do not add such types at this point in time -- 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] rfc6991bis: inet:urn-scheme, inet:uri-authority, inet:uri-path, inet:uri-query, ...
- It is not clear how commonly useful these types are, the WG was pretty silent about this proposal. - On the technical side, it is unclear whether data is represented with percent escapes resolved or not. - Proposal: do not add these typedefs since their use seems rather specific -- 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] rfc6991bis: inet:email-address
- Current definition follows addr-spec (idea: follow mailto: url scheme format). The current pattern does not take care of quoted-string, obs-local-part, domain-literal, obs-domain. - Proposal: Add the typedef cover addr-spec but this work would benefit from some help to get the pattern right. -- 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] rfc6991bis: inet:host
- 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: ? -- 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
