[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-17.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename: draft-ietf-netmod-yang-instance-file-format-17.txt Pages : 28 Date: 2021-07-28 Abstract: There is a need to document data defined in YANG models at design time, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] yang-instance-file include-defaults leaf
Hello Rob,
Removing the “default trim;” will address Andy’s comment.
Your in-use-values is very specific to one of the use-cases:
reading/documenting operational values. It is not useful for the other
use-cases. I think the “documenting operational datastore” use-case could be
handled by indicating the includes-defaults=report-all. Case (i) would contain
the value case (ii) will not.
Regards Balazs
From: Rob Wilton (rwilton)
Sent: 2021. július 27., kedd 17:38
To: Andy Bierman ; Balázs Lengyel
Cc: NetMod WG
Subject: RE: [netmod] yang-instance-file include-defaults leaf
Hi Andy, Balazs,
So, the reason that I want a flag to indicate whether default values are in use
is because of this definition of operational in RFC 8342:
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.
It was written this way because otherwise a consumer of operational data cannot
differentiate between:
(i) This value is not present because it matches the default
value specified in the YANG module, and
(ii) This value is not present because the server has failed to
return it for some reason (e.g., perhaps the daemon that would have provided
this value is down or not available, or perhaps it is a bug, or perhaps it is
not implemented and is a missing deviation).
So, I think that in some cases, the absence of a data node does not necessarily
mean that the default value is in effect, and I wanted the instance-data
document to be able to contain and correctly report this data.
I think that this behaviour could be captured by a single leaf. Another way of
articulating this would be:
leaf in-use-values {
type boolean;
default false;
description
“Only if set to true, the absence of a value in the
instance data for a given data node implies that the
node is not used rather than implicitly taking the
default value specified by any corresponding
‘default’ statement specified in the YANG schema.”;
}
With this, I’m not sure whether we need the “includes-default” leaf currently
specified in the draft, but if we do, then I would think that leaf should be
entirely optional, i.e., without the default “trim”.
Regards,
Rob
From: Andy Bierman mailto:a...@yumaworks.com> >
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >
Cc: NetMod WG mailto:netmod@ietf.org> >; Balázs Lengyel
mailto:balazs.leng...@ericsson.com> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf
On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:
Andy,
Yes, when I suggested this, I was thinking that a boolean flag might be
sufficient. My point being that automatically filtering out default values
isn’t always the right thing to do.
The solution is simple.
Get rid of the inappropriate "default trim" statement.
If the leaf is present then it identifies the basic-mode that was used to
include defaults.
If not then the information is either not known, not applicable, or defaults
were not added.
The "default" statement is a bug because there is no default basic-mode.
All of the basic-modes are in use in deployments and no camp has ever
been able to convince the others that theirs is right.
Andy
E.g., something along these lines:
leaf exclude-defaults {
type boolean;
default true;
description
“Can be used to reduce the size of the content data file.
When unset or set to true, data nodes that have a default defined and
where the actual value is the default value are excluded from the content
data.
When set to false, data nodes with default value are not filtered, and
may appear in the content data.”
}
Would this satisfy your concern?
Regards,
Rob
From: netmod mailto:netmod-boun...@ietf.org> > On
Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG mailto:netmod@ietf.org> >
Subject: [netmod] yang-instance-file include-defaults leaf
Hi,
The module has this object:
leaf includes-defaults {
type enumeration {
enum report-all {
value 1;
description
"All data nodes SHOULD be included independent of
any default values.";
}
enum trim {
value 2;
description
"Data nodes that have a default defined and where
the actual value is the default value SHOULD
NOT be included.";
}
enum explicit {
value 3;
description
"Data nodes that have a default defined and where
the actual value is the default value SHOULD NOT be
Re: [netmod] yang-instance-file include-defaults leaf
Hello Andy,
I will remove the “default trim; “
Balazs
From: Andy Bierman
Sent: 2021. július 27., kedd 19:00
To: Rob Wilton (rwilton)
Cc: Balázs Lengyel ; NetMod WG
Subject: Re: [netmod] yang-instance-file include-defaults leaf
Hi,
None of this addresses my point that a default value of "trim" is not
appropriate.
Simply remove the default-stmt so that a missing leaf instance means that
no information is provided, rather than meaning defaults were added for
basic-mode=trim.
Andy
On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:
Hi Andy, Balazs,
So, the reason that I want a flag to indicate whether default values are in use
is because of this definition of operational in RFC 8342:
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.
It was written this way because otherwise a consumer of operational data cannot
differentiate between:
(i) This value is not present because it matches the default
value specified in the YANG module, and
(ii)This value is not present because the server has failed to
return it for some reason (e.g., perhaps the daemon that would have provided
this value is down or not available, or perhaps it is a bug, or perhaps it is
not implemented and is a missing deviation).
So, I think that in some cases, the absence of a data node does not necessarily
mean that the default value is in effect, and I wanted the instance-data
document to be able to contain and correctly report this data.
I think that this behaviour could be captured by a single leaf. Another way of
articulating this would be:
leaf in-use-values {
type boolean;
default false;
description
“Only if set to true, the absence of a value in the
instance data for a given data node implies that the
node is not used rather than implicitly taking the
default value specified by any corresponding
‘default’ statement specified in the YANG schema.”;
}
With this, I’m not sure whether we need the “includes-default” leaf currently
specified in the draft, but if we do, then I would think that leaf should be
entirely optional, i.e., without the default “trim”.
Regards,
Rob
From: Andy Bierman mailto:a...@yumaworks.com> >
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >
Cc: NetMod WG mailto:netmod@ietf.org> >; Balázs Lengyel
mailto:balazs.leng...@ericsson.com> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf
On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:
Andy,
Yes, when I suggested this, I was thinking that a boolean flag might be
sufficient. My point being that automatically filtering out default values
isn’t always the right thing to do.
The solution is simple.
Get rid of the inappropriate "default trim" statement.
If the leaf is present then it identifies the basic-mode that was used to
include defaults.
If not then the information is either not known, not applicable, or defaults
were not added.
The "default" statement is a bug because there is no default basic-mode.
All of the basic-modes are in use in deployments and no camp has ever
been able to convince the others that theirs is right.
Andy
E.g., something along these lines:
leaf exclude-defaults {
type boolean;
default true;
description
“Can be used to reduce the size of the content data file.
When unset or set to true, data nodes that have a default defined and
where the actual value is the default value are excluded from the content
data.
When set to false, data nodes with default value are not filtered, and
may appear in the content data.”
}
Would this satisfy your concern?
Regards,
Rob
From: netmod mailto:netmod-boun...@ietf.org> > On
Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG mailto:netmod@ietf.org> >
Subject: [netmod] yang-instance-file include-defaults leaf
Hi,
The module has this object:
leaf includes-defaults {
type enumeration {
enum report-all {
value 1;
description
"All data nodes SHOULD be included independent of
any default values.";
}
enum trim {
value 2;
description
"Data nodes that have a default defined and where
the actual value is the default value SHOULD
NOT be included.";
}
enum explicit {
value 3;
description
"Data nodes that have a default defined and where
the actual value is the default value SHOULD NOT be
Re: [netmod] system configuration sync mechanism
WG, Regarding yesterday’s datastore presentation, there seemed to be support for "Option #2”, which is to have merge into . It was noted that this then would mean that client-validation of would necessitate understanding how the merge works, to expand templates, resolve leafrefs, etc. My thoughts are, so? Firstly, a client that doesn’t understand that there may be some defined configuration will, for the most part, be none the wiser. The client *will* discover configuration in , but this is already the case today. One new thing is that should use “origin:system” for configuration originating from the datastore. This last point might surprise clients…as the definition of “with-origin” doesn’t state that clients must ignore any unrecognized “origin” identities: https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2. Secondly, no shared object defined in will be activated until client-supplied config references it. But any client able to do this already knows how merges into and is accounting for it. Thoughts? Kent > On Jul 16, 2021, at 6:24 AM, maqiufang (A) wrote: > > Hi, Kent, > Please see my reply inline. > > From: Kent Watsen [mailto:kent+i...@watsen.net] > Sent: Friday, July 16, 2021 2:55 AM > To: maqiufang (A) > Cc: netmod@ietf.org > Subject: Re: [netmod] system configuration sync mechanism > > Hi Qiufang, > > [snip] > The question is if the server implementation prunes dangling/unused objects > when is applied, updating . My assumption is that > the server will discard any object that doesn’t actually impact the running > configuration of the system (i.e., values are consumed by the underlying > operating system, drivers, etc.). Thusly, it is my opinion that only the > referenced objects are applied. Hence why, to answer your last question, I > wrote that these configurations (manufacturer-defined objects) are not > applied immediately but only after they are referenced. Makes sense? > [Qiufang Ma] Yes, try to sum up our discussion about the categories of the > system configuration: > · Physical-resource-dependent--> whether this sort of system > configuration exists in dependents on if the physical resource is > present(e.g., physical interface). > · Physical-resource-independent-->which is provided by the device > system > o Further classification from the perspective of “applied” time(dependents > on whether the system configuration impacts the running of the system) > § Config that is applied immediately(e.g., the loopback, the predefined > minimum length of password…) > § Config that is applied only after being referenced by other configs(e.g, > definitions for applications ftp/tftp…) > o Further classification from the perspective of generation time > § Config that is generated unconditionally at each boot time(e.g, loopback, > predefined minimum length of password, ftp/tftp…) > § Config that is generated conditionally during the device running(e.g., > system-generated local-port and remote-port for a new established BGP > connection) > > Keep in mind that what is described above is just one aspect of what can be > in . In addition to defining reference-able objects, can > also define/apply configuration immediately (e.g., the loopback interface). > That is, configuration not does not have to be referenced in order to become > activated. > [Qiufang Ma] Noted. > > > > Note that, by itself would not pass validation, due to missing > leafrefs. Thankfully, NMDA never says that validation runs on . > But once and have been merged, to become , the > result does pass validation. > [Qiufang Ma] The referenced instance must also exist for the data to be > valid since the require-instance defaults to true if not present. Is this > what you had in your mind? Yes, NMDA says that it is which is > subject to validation. But I also notice that In section 5.1.3 of the > NMDA:” MUST always be a valid configuration data tree, as defined > in Section 8.1 of [RFC7950]. ” So my thought here is that should > also conform to the YANG model constraints and that’s to say, a referenced > system-defined data item should also exists in . > Therefore, if system configurations do not exist in , they still > need to be configured in manually in order for being referenced. > In this case, the original purpose of predefining some system configurations > for user convenience is lost. This is the reason why we would like to define > some mechanism here to synchronize into . > > > I see in RFC 8342 " MUST always be a valid configuration data tree, > as defined in Section 8.1 of [RFC7950]”. > > But the question remains if it is possible for the system is able to validate > without, e.g., expanding templates. There may be a 'leafref' or > ‘must’ expression somewhere that will fail because the evaluation occurs > without expanding a template that supplies the missing pa
Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)
On Mon, Jul 19, 2021 at 12:12:09PM -0400, Christian Hopps wrote:
>
>
> > On Jul 17, 2021, at 7:24 PM, Benjamin Kaduk wrote:
> >
> > On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote:
> >>
> >>
> >>> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk wrote:
> >>>
> >>> So, when we refine the coord-accuracy and height-accuracy for an
> >>> instantiation of the grouping, what does that mean?
> >>
> >> It’s supposed to mean the accuracy of the measurement that is recorded in
> >> the grouping. So if the coord-accuracy is .1 and the measurement is
> >> lat/long then the accuracy is within 1/10 of a decimal degree. if the
> >> measurement is in cart coordinates the accuracy would be 100cm. I don’t
> >> think we need to make this anymore complex than that. Is there some text
> >> you would like to see to make that clearer?
> >
> > The accuracy of the measurement with respect to what? The coordinate
> > system, or the actual physical object?
>
> I really don’t see how this could be so confusing.
>
> This grouping is a location, the accuracy applies to the contained location
> data. Consider asking this question about some other field like the lat/long
> — it doesn’t make sense.
It's confusing because there's a type mismatch between what the actual
words on the page say and what you're describing in the email thread.
> I can’t say for sure, but I think you’ve discarded the obvious here and are
> getting pedantic about something that’s not actually confusing.
>
> Finally, as we (the IETF) are not geo location experts, we had this grouping
> reviewed by actual industry experts (thanked in the acknowledgment section)
> and they had no issue with these fields. I would be very hesitant to change
> what they reviewed as correct at this point based on pedantic musings.
I'm confident that the actual fields in the model can provide the needed
information. We just need to clearly describe what information they are
conveying.
So, if we look at the
OLD:
leaf geodetic-datum {
type string {
pattern '[ -@\[-\^_-~]*';
}
description
"A geodetic-datum defining the meaning of latitude,
longitude and height. The default when the
astronomical body is 'earth' is 'wgs-84' which is
used by the Global Positioning System (GPS). The
ASCII value SHOULD have upper case converted to lower
case and not include control characters (i.e., values
32..64, and 91..126). The IANA registry further
restricts the value by converting all spaces (' ') to
dashes ('-')";
[...]
leaf coord-accuracy {
type decimal64 {
fraction-digits 6;
}
description
"The accuracy of the latitude longitude pair for
ellipsoidal coordinates, or the X, Y and Z components
for Cartesian coordinates. When coord-accuracy is
specified, it overrides the geodetic-datum implied
accuracy.";
}
this is indicating that the geodetic datum has some intrinsic default for
accuracy of latitude/longitude (not quoted, there is also some default for
height accuracy intrinsic to the geodetic datum).
If I were holding the pen, I might consider things like the following
NEW1:
leaf geodetic-datum {
type string {
pattern '[ -@\[-\^_-~]*';
}
description
"A geodetic-datum defining the meaning of latitude,
longitude and height. The default when the
astronomical body is 'earth' is 'wgs-84' which is
used by the Global Positioning System (GPS). The
ASCII value SHOULD have upper case converted to lower
case and not include control characters (i.e., values
32..64, and 91..126). The IANA registry further
restricts the value by converting all spaces (' ') to
dashes ('-')";
The specification for the geodetic-datum indicates
how accurately it models the astronomical body in
question, both for the "horizontal" latitude/longitude
coordinates and for height coordinates, typically as a
maximum deviation across the entire astronomical object.
NEW2:
leaf coord-accuracy {
type decimal64 {
fraction-digits 6;
}
description
"The accuracy of the latitude longitude pair for
ellipsoidal coordinates, or the X, Y and Z components
for Cartesian coordinates. When coord-accuracy is
specified, it overrides the geodetic-datum
[netmod] YANG Versioning Weekly Call Minutes - 2021-07-27
YANG Versioning Weekly Call Minutes - 2021-07-27 We reviewed and updated the IETF111 slides - moved discussion of the main open issue (YANG 1.1 vs 1.2 vs 2.0) to the end - added summary slides of 1st two drafts Reconfirmed reasons why we propose these drafts as part of YANG 1.1: - no real harm for anyone who doesn't use them (or tools that don't support them) - imports today are ambiguous - file names are optional (can be mitigated, minor effort to update tooling for this) - adds value for something happening today (vendors are already doing proprietary work arounds,IETF models have had some NBC changes) - NBC changes in IETF models: IANA (AFI/SAFIs removed). L3SM. Other cases are likely coming up as more YANG RFCs get published - IEEE dot1q may have some NBC changes they want to do Next steps: - drive issues to closure on 1st two drafts (+ text for removing history) - author top down reviews (should occur before formal WG LC) -- 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
