Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
Randy Presuhn wrote: > In ltru the I-Ds contained both material for publication > in the RFC as well as a *massive* amount of material for > population of the IANA language tag registry. We needed > it in I-D form for review during development, but wanted to > remove all temptation to use the RFC instead of the IANA > registry. > All it took was a word of instruction to the RFC editor > to delete the many many many pages of registry content > upon publication. Worked fine. > In this case, just tell the RFC editor to delete the > IANA-maintained module. I think you mean, the RFC-maintained module :-) How do we keep the YANG catalog from latching onto it. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
Hi - On 2021-07-05 9:13 AM, tom petch wrote: ... Well my answer would be that confusion reigns. An IANA Registry is > authoritative so the minute the RFC is published asking IANA to maintain a module, then the module in RFC8366(-bis) is obsolete. Trouble is, that the rest of the RFC - if any - is not. ... There are other straightforward ways to deal with this. In ltru the I-Ds contained both material for publication in the RFC as well as a *massive* amount of material for population of the IANA language tag registry. We needed it in I-D form for review during development, but wanted to remove all temptation to use the RFC instead of the IANA registry. All it took was a word of instruction to the RFC editor to delete the many many many pages of registry content upon publication. Worked fine. In this case, just tell the RFC editor to delete the IANA-maintained module. Randy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
Tom writes: > If by 'value' that means the value substatement of the 'enum' YANG > statement, then that may not give you what you expect. What goes on > the wire is the text name string. If a number is displayed to a user, > then it is because the local software had deduced one, perhaps from a > YANG module. The text string is the authoritative definition, the > value conveys nothing. If you want a value, then you need a different > type of leaf like an integer. (In other languages, the binding of text > string to value is part of the specification of an enumeration - not in > YANG). yes, it's a text string for XML and JSON, this isn't the case for YANG-CBOR if a value is set. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
From: Michael Richardson Sent: Monday, July 05, 2021 16:17 tp> Likewise involving IANA. They maintain registries which anyone can tp> access. They perform updates, on request, according to the policy of tp> the registry, which is set when the registry is set up and can range tp> from requiring a Standards Track RFC to First Come First Served, tp> depending on how easy you want it to be to make changes. See 'IANA tp> Considerations' RFC for the range of options. And they can turn tp> updates to a registry into an update to a code module (such as an SMI tp> MIB). Probably Standards Track RFC to update the voucher types. tp> What I am missing is how easy or difficult you want it to be to make tp> changes, who will make changes, (IETF only, another SDO, a manufacturer tp> ), what review you want for changes by whom, how frequent changes tp> will be (usually a guess and usually wrong but it helps to have the tp> assumptions about the requirements spelt out) and such like. tp> As an engineer, I do like to know the requirements before working on the design! We need to be able to write RFCs that extend the voucher types. Not that often though. Michael, That is nice and clear. To quote an earlier e-mail in this thread, > Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses > RFC8366 gets updated when IANA revises the module. I think, it mostly doesn't > matter because none of are generating code from YANG... AT THIS TIME. Well my answer would be that confusion reigns. An IANA Registry is authoritative so the minute the RFC is published asking IANA to maintain a module, then the module in RFC8366(-bis) is obsolete. Trouble is, that the rest of the RFC - if any - is not. (You may have seen this on the DHCP list with I-D referencing an RFC when they should have been referencing the IANA website) RFC7224 gets it right because the contents are only the initial version of the IANA module so that (almost) any reference to RFC7224 is an error, the reference should be to the IANA website. That says that having long-lived text in an RFC with the initial version of an IANA-maintained module can only cause confusion (IMHO); they are clearer as separate RFC. Again a quote that caught my eye, "I also think that in our enumeration/Registry, that we should include the "value" parameter, so that constrained-voucher can consistently set values even if the enumeration changes order." If by 'value' that means the value substatement of the 'enum' YANG statement, then that may not give you what you expect. What goes on the wire is the text name string. If a number is displayed to a user, then it is because the local software had deduced one, perhaps from a YANG module. The text string is the authoritative definition, the value conveys nothing. If you want a value, then you need a different type of leaf like an integer. (In other languages, the binding of text string to value is part of the specification of an enumeration - not in YANG). The usual alternative to a YANG enum is identity which can also be in an IANA-maintained module but which can be augmented. It is just an identifier (which to me is more honest than an enum with its 'value' substatement:-). It is referenced by identityref. (It can also form a tree structure). AFAICT 'leaf assertion' in RFC8366 could equally well be an identityref. and then later RFC could augment the identity. So I have reservations about enum and about IANA-maintained modules (at least as part of a larger RFC:-) but I did note when I looked at draft-ietf-anima-voucher that one of the authors was a YANG doctor so assumed that the choice of 'enum was made knowingly. Tom Petch -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
tp> Likewise involving IANA. They maintain registries which anyone can tp> access. They perform updates, on request, according to the policy of tp> the registry, which is set when the registry is set up and can range tp> from requiring a Standards Track RFC to First Come First Served, tp> depending on how easy you want it to be to make changes. See 'IANA tp> Considerations' RFC for the range of options. And they can turn tp> updates to a registry into an update to a code module (such as an SMI tp> MIB). Probably Standards Track RFC to update the voucher types. tp> What I am missing is how easy or difficult you want it to be to make tp> changes, who will make changes, (IETF only, another SDO, a manufacturer tp> ), what review you want for changes by whom, how frequent changes tp> will be (usually a guess and usually wrong but it helps to have the tp> assumptions about the requirements spelt out) and such like. tp> As an engineer, I do like to know the requirements before working on the design! We need to be able to write RFCs that extend the voucher types. Not that often though. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-14.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-14.txt Pages : 29 Date: 2021-07-05 Abstract: There is a need to document data defined in YANG models at design, 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-14 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
[netmod] FW: AD review of draft-ietf-netmod-yang-instance-file-format
Hello Rob,
Thanks for the review. Here are my answers below. I will also upload the
new version asap.
Regards Balazs
---
Hi,
Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.
Thanks for this document, I think that it represents important useful work
for advancing the YANG ecosystem.
This document is in good shape, and I mostly have minor comments but with a
few more significant comments.
Main comments:
1.
An instance data set MAY contain data for any number of YANG modules;
if needed it MAY carry the complete configuration and state data for
a server. Default values SHOULD NOT be included.
This document recommends that default values SHOULD NOT be included, but
there are cases where they are useful, and e.g., NMDA recommends that
"in-use" values (effectively including default values) are returned.
Further, there is no way for a consumer of the file to know whether default
values are included or not.
Hence, I would recommend that the instance-data-set defines an
"includes-defaults" leaf that indicates whether default values are included
in the dataset, the leaf can default to them not being included in the
dataset.
Further, I would suggest weakening "Default values SHOULD NOT be included"
to something like:
"Default values should be excluded where they do not provide additional
useful data."
BALAZS: Section 2 states that a default attribute may be specified,
following the with-defaults capability.
However, your proposal is better. I will include it.
Added leaf includes-defaults.
2.
In the YANG Module:
feature inline-content-schema {
description
"This feature indicates that inline content-schema
option is supported. Support for this feature might
be documented only via out-of-band documentation.";
}
What is the benefit of having 'inline-content-schema' as a feature? It
seems to potentially add complexity without any benefit, given that the
device originating the instance data file would effectively choose whether
to use the inline-content-schema, hence I suggest that it might be simpler
just to remove the feature definition.
BALAZS: This was explicitly requested earlier by a reviewer (Andy ?).
The system can declare supported/not-supported in design documentation.
In a use-case when a client or a design department is sending data to a
server this is needed. E.g. in UC2, Preloading Default Configuration the
designer preparing instance data, can decide to use or not use the
inline-content-schema based on this.
3.
In the YANG Module:
"case inline", description:
The first item is either ietf-yang-library or
some other YANG module that contains a list of
YANG modules with their name, revision-date,
supported-features, and deviations.
The usage of revision '2019-01-04' of the
'ietf-yang-library' module MUST be supported.
Using other modules, module versions MAY also
be supported.
This seems to make interop for consumers of instance data files hard, since
the schema can be defined by any arbitrary YANG module without updating this
module. I would suggest that it is safer to limit this to the two currently
published versions of YANG library.
BALAZS: I fully agree, however this was explicitly requested by some
reviewer earlier (Juergen ?) Shall I simplify this or not?
If additional modules are supported in future, then I think that it would be
safer to create a new version of this YANG module that documents what other
module formats can be used.
4.
In the YANG Module:
list "revision"
Is revision expected to be unique, if provided? If so, should this be
explicitly stated in the YANG module description?
BALAZS: I don't think I understand your comment. There may be multiple list
entries for revision. The 'leaf date' is a key, so it is inherently unique.
The description may or may not be unique.
5.
In the YANG Module:
Is an instance-data file allowed to contain both a revision and also a
timestamp? If so, is there any constraints on the values. If not, then
would it make sense to put them under a choice?
BALAZS: It is allowed to have both. There is some recommendation text about
when to use each. However I can see some corner cases, when using both in
the same file would be useful, E.g. we want a timestamp including hour,
minutes, but we also want the history of the instance data set, including
multible revision/descriptions.
I propose to add: if both are included the timestamp, SHOULD contain
the same date as the latest revision statement.
6.
References:
- RFC 6020 needs to be normative for the IANA YANG module registration.
BALAZS: OK
Minor comments:
7.
Abstract:
There is a need to document data defined in YANG models when a live
server is unavailable. Data is
Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
From: netmod on behalf of Michael Richardson Sent: 05 July 2021 00:21 Michael Richardson wrote: > I propose that the WG adopt this as the -00, and then we change the document > to change this into an RFC7224-style IANA-maintained YANG module. > (In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which was > whitespace equivalent to RFC3315 first, and then we amended it) > As I understand it, we would be creating a Registry with IANA Considerations, > and when documents extend the Registry, that IANA writes a new YANG module > (with a new date) for us. > I believe that given that the module gets revised, that we don't have to > worry about enumeration vs leaf/choice/empty. But, if there is some > advantage to doing it the non-enumeration way, it would be good to understand > that. But, we might want to do a WG Consensus call on the differences. We might also want to ask a YANG Doctor to come to the ANIMA WG meeting at the end of the Month, to explain the differences. I would love to know what the problem is (rather than possible solutions to potential problems:-) enum and identity are solutions with different characteristics as others have spelt out. Which is better depends on the problem, how easy it should be to make changes or to prevent people from making changes:-) Likewise involving IANA. They maintain registries which anyone can access. They perform updates, on request, according to the policy of the registry, which is set when the registry is set up and can range from requiring a Standards Track RFC to First Come First Served, depending on how easy you want it to be to make changes. See 'IANA Considerations' RFC for the range of options. And they can turn updates to a registry into an update to a code module (such as an SMI MIB). So the IANA Considerations section in an RFC creates the registry but what it takes to update it varies depending on what they say. What I am missing is how easy or difficult you want it to be to make changes, who will make changes, (IETF only, another SDO, a manufacturer ), what review you want for changes by whom, how frequent changes will be (usually a guess and usually wrong but it helps to have the assumptions about the requirements spelt out) and such like. As an engineer, I do like to know the requirements before working on the design! Tom Petch -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities
Hi Benoit, Thanks for accommodating my suggestions. All resolutions look good to me. I have a preference to hold shipping this document to IETF LC until the instance-data doc is also ready. I think that it will help the IESG review if they have both documents available to review at the same time. I assume that the updates to the instance-data doc are also in progress? Thanks, Rob From: Benoit Claise Sent: 05 July 2021 11:53 To: Rob Wilton (rwilton) ; netmod@ietf.org; draft-ietf-netconf-notification-capabilit...@ietf.org Cc: NetMod WG Chairs Subject: Re: AD review of draft-ietf-netconf-notification-capabilities Hi Rob, Thanks for your detailed review. A new draft version has been posted. URL: https://www.ietf.org/archive/id/draft-ietf-netconf-notification-capabilities-17.txt Status: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-17 See the justifications below. On 6/21/2021 10:45 AM, Rob Wilton (rwilton) wrote: Hi, Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16 Thanks for this draft, sorry for the delay in reviewing. It looks like it is in good shape. I think that most of my comments are minor or cosmetic suggestions to potentially improve the phrasing of the text. 1. Abstract: The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG related system capabilities for servers. The module can be used to report capability information from the server at run-time or implementation- time, per the YANG Instance Data File Format. Suggest "by making use of" rather than "per". DONE. 2. 1. Introduction There is a need to publish this capability information as it is part of the contract between the server and client. Suggest "contract" -> "API contract". DONE 3. There is a need to publish this capability information as it is part of the contract between the server and client. Examples include maximum size of data that can be stored or transferred, information about counters (whether a node supports "on-change" telemetry), etc. Such capabilities are often dependent on a vendor's implementation or the available resources at deployment. Many such capabilities are specific to either the complete system, individual YANG datastores [RFC8342] or specific parts of the YANG schema, or even individual data nodes. It is a goal of this document to provide a common way of representing such capabilities in a format that is: Suggest: maximum -> the maximum "or specific" -> ", specific" DONE 4. o available in identical format both at implementation-time and run- time Suggest: "in an identical", and a period at the end. DONE 5. If the information is not documented in a way available to the NMS designer, but only as instance data from the network node once it is deployed, the NMS implementation will be delayed Suggest: "way available" => "way that is readily available" DONE 6. The network operator needs to plan his management practices and NMS implementation before he even decides to buy the specific network node type. Suggest: "him" -> "their", "he even decides" -> "they decide" DONE 7. Run-time information is needed: Suggest: Run-time capability information is needed: DONE. 8. o to check that capability information provided earlier, at implementation-time is what the publisher has implemented. Suggest: "at implementation-time, is" DONE 9. To find a capability value for a specific data node in a specific datastore the user SHALL: Please clarify that the capability value is selected by the relative path to the datanode defining the capability. i.e., the same name/path must be used both under the system level and per datastore level capabilties. NEW SENTENCE. "When stating a specific capability, the relative path for any specific capability must be the same under the system-capabilities container and under the per-node-capabilities list: the same grouping for defining the capabilities MUST be used. " 10. 2) If the datastore entry is found within that entry, process all per-node-capabilities entries in the order they appear in the list. The first entry that specifies the specific capability and has a node-selector selecting the specific data node defines the capability value. I'm not sure this is required, but perhaps consider adding text to make it clear that longest path matching can be achieved by ordering more specific matches before less specific matches. ADDED "Note that longest path matching
Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities
Hi Rob,
Thanks for your detailed review.
A new draft version has been posted.
URL:https://www.ietf.org/archive/id/draft-ietf-netconf-notification-capabilities-17.txt
Status:https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities
Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-17
See the justifications below.
On 6/21/2021 10:45 AM, Rob Wilton (rwilton) wrote:
Hi,
Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16
Thanks for this draft, sorry for the delay in reviewing. It looks like it is
in good shape.
I think that most of my comments are minor or cosmetic suggestions to
potentially improve the phrasing of the text.
1.
Abstract:
The module "ietf-system-capabilities" provides a placeholder
structure that can be used to discover YANG related system
capabilities for servers. The module can be used to report
capability information from the server at run-time or implementation-
time, per the YANG Instance Data File Format.
Suggest "by making use of" rather than "per".
DONE.
2.
1. Introduction
There is a need to publish this capability information as it is part
of the contract between the server and client.
Suggest "contract" -> "API contract".
DONE
3.
There is a need to publish this capability information as it is part
of the contract between the server and client. Examples include
maximum size of data that can be stored or transferred, information
about counters (whether a node supports "on-change" telemetry), etc.
Such capabilities are often dependent on a vendor's implementation or
the available resources at deployment. Many such capabilities are
specific to either the complete system, individual YANG datastores
[RFC8342] or specific parts of the YANG schema, or even individual
data nodes. It is a goal of this document to provide a common way of
representing such capabilities in a format that is:
Suggest: maximum -> the maximum
"or specific" -> ", specific"
DONE
4.
o available in identical format both at implementation-time and run-
time
Suggest: "in an identical", and a period at the end.
DONE
5.
If the information is
not documented in a way available to the NMS designer, but only as
instance data from the network node once it is deployed, the NMS
implementation will be delayed
Suggest: "way available" => "way that is readily available"
DONE
6.
The network operator needs to plan his
management practices and NMS implementation before he even decides to
buy the specific network node type.
Suggest: "him" -> "their", "he even decides" -> "they decide"
DONE
7.
Run-time information is needed:
Suggest: Run-time capability information is needed:
DONE.
8.
o to check that capability information provided earlier, at
implementation-time is what the publisher has implemented.
Suggest: "at implementation-time, is"
DONE
9.
To find a capability value for a specific data node in a
specific datastore the user SHALL:
Please clarify that the capability value is selected by the relative path
to the datanode defining the capability. i.e., the same name/path must be
used both under the system level and per datastore level capabilties.
NEW SENTENCE.
"When stating a specific capability, the relative path for any specific
capability must be the same under the system-capabilities container and
under the per-node-capabilities list: the same grouping for defining the
capabilities MUST be used. "
10.
2) If the datastore entry is found within that entry, process all
per-node-capabilities entries in the order they appear in the list.
The first entry that specifies the specific capability and has a
node-selector selecting the specific data node defines the
capability value.
I'm not sure this is required, but perhaps consider adding text to make it clear
that longest path matching can be achieved by ordering more specific
matches before less specific matches.
ADDED "Note that longest path matching can be achieved by ordering more
specific matches before less specific ones"
under
list per-node-capabilities {
description
"Each list entry specifies capabilities for the selected
data nodes. The same capabilities apply for the data nodes
in the subtree below the selected nodes.
The system SHALL order the entries according to their
precedence. The order of the entries MUST NOT change unless
the underlying capabilities also change.";
We did NOT add next to "2) If the datastore entry is found within that
entry ..." because that section focuses on the user (as opposed to the
implementer on the server), as mentioned in "To find a capability
Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
> From: Michael Richardson > Sent: Montag, 5. Juli 2021 00:17 > Fries, Steffen wrote: > >> I thought I wrote a really nice ASCII art version of what documents > inherit > from > >> RFC8366. I can't find it in my outbox... I wonder if I nuked the > draft by > mistake. > >> > >> The short of it: > >> RFC8366 -> RFC8995 (voucher-request) > -> constrained-voucher (voucher-request, voucher) > -> brski-async-enroll (voucher-request) > > > Would it make sense to also state the voucher for BRSKI-AE as it also > > uses the voucher and tries to argue for a new assertion type > > (agent-proximity)? > > I am of two feelings here. > On the one hand, it would be IANA proceedurally simpler to include the new > assertion type into the 8366bis document. > > On the other hand, this means having some kind of explanation in RFC8366bis > for the new choice, and that might force a lot of text to enter and get > reviewed. > > Once RFC8366bis is published, then async-enroll can make use of the IANA > Considerations to allocate that new enum value. That won't slow async-enroll > down, because either way, it has to wait for RFC8366bis. Yes true. Having the option doing it via an IANA considerations will be simpler for other drafts like async-enroll extending the assertions in the voucher. > Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses > RFC8366 gets updated when IANA revises the module. I think, it mostly doesn't > matter because none of are generating code from YANG... AT THIS TIME. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
