Re: [netmod] Regarding IPR on draft-verdt-netmod-yang-solutions-03
No, I am not aware of any IPR that applies to this draft. > On Mar 2, 2020, at 2:13 PM, Lou Berger wrote: > > > Authors, Contributors, WG, > > As part of preparation for WG Adoption: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > We note that all DT members are listed as contributors. If you contributed > to the document please respond. Alternatively, please feel free to state > that you didn't materially contribute to the draft and would like your name > removed from the contribution section (and moved to acknowledgments after WG > adoption). > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. > > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NetMod WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > ___ > 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
Re: [netmod] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-schema-comparison-00
Thanks to Benoit for pointing out … No, I am not aware of any IPR that applies to this draft. Cheers. > On Mar 2, 2020, at 2:13 PM, Lou Berger wrote: > > > Authors, Contributors, WG, > > As part of preparation for WG Adoption: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > We note that all DT members are listed as contributors. If you contributed > to the document please respond. Alternatively, please feel free to state > that you didn't materially contribute to the draft and would like your name > removed from the contribution section (and moved to acknowledgments after WG > adoption). > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. > > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NetMod WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > ___ > Netmod-ver-dt mailing list > netmod-ver...@ietf.org > https://www.ietf.org/mailman/listinfo/netmod-ver-dt ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Regarding IPR on draft-ietf-netmod-geo-location-04
Authors, Contributors, WG, As part of the WGLC, are you aware of any IPR that applies to draft-ietf-netmod-geo-location? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NetMod WG Chairs PS Please include all listed in the headers of this message in your response. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] WGLC: draft-ietf-netmod-geo-location-04
This message begins an almost two-week WGLC for draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the NETMOD sessions). Here is a direct link to the HTML version of the draft: https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04 Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Objections, concerns, and suggestions are also welcomed at this time. Thank you, NETMOD Chairs ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Secdir last call review of draft-ietf-netmod-factory-default-14
Reviewer: Stephen Kent Review result: Has Issues SECDIR review of draft-ietf-netmod-factory-default-14 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This is a very brief document- only 9 pages (ignoring notes that are to be removed before publication)! It is a proposal for a YANG data model that will allow clients to reset a server to its factory default settings. It also defines a “factory-default” datastore that enables a client to determine the values for the default settings for a server. The datamodel is said to conform to the architecture defined in RFC 8342. RFC 8342, and RFC 7950, define the terms used in this document, and the terminology Section (1.1) cites these RFCs when enumerating these terms. This reader would prefer to have the definitions replicated here for the nine terms in question. Only one additional term is defined in this document, the factory-default datastore. The acronym “RPC” (remote procedure call) is not expanded upon first use. The description of how to effect a factor-reset RPC, in Sections 2 & 3 seems pretty thorough, and includes appropriate comments about security-relevant data, e.g., private keys and certificates. I an not familiar enough with YANG to evaluate the module definition in Section 4. Section 6, Security Considerations, calls for use of SSH (RFC 6242) with NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current, citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC 4253 for a description of SSH. 4253 is a very much out of date document; the integrity and key management algorithms in the original RFC have been updated 3 times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all outdated. This discussion of SSH security for use with NETCONF, based on the one citation, seems to be inconsistent with current IETF crypto guidelines. This is a problem that the net management area should address before this document is approved. The discussion of how a factory-reset RPC may isolate a device, is good, as is the warning about not relying on this RPC to prevent recovery of security-sensitive data from NV storage. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption of versioning design team docs
Lou and Netmod: As a monitoring DT-member and contributor to the requirements I support the adoption of this set of documents below. I have reviewed the final version of each of these modules. These document are a necessary base work to be able to handle versioning for configuration. It is especially helpful when the protocol (like BGP) have different features that may be revised. As the WG continues to refine this work, I hope you will consider the needs of the BGP configuration. Cheers, Sue Hi, We'd like to start a two week adoption call for the set of documents described below by Rob. To be specific, this includes 1) draft-verdt-netmod-yang-solutions-03 2) draft-verdt-netmod-yang-module-versioning-01 3) draft-verdt-netmod-yang-semver-01 4) draft-rwilton-netmod-yang-packages-03 5) draft-wilton-netmod-yang-ver-selection-02 6) draft-verdt-netmod-yang-schema-comparison-00 The adoption call ends in two weeks, on March 16. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] FW: New Version Notification for draft-ietf-netmod-yang-instance-file-format-08.txt
Hello, New version is available. Thanks for the comments, especially for Juergen's contribution. Main changes: - Moved compatibility into appendix - Made support of ietf-yang-library mandatory if inline-content- schema is supported - Renamed yid-version to format-version as "yid" can be regarded as a racial slur. Changed format to date of the YANG module - Removed section about XML attributes - Other WGLC related changes Regards Balazs -Original Message- From: internet-dra...@ietf.org Sent: 2020. március 9., hétfő 18:14 To: Balázs Lengyel ; Benoit Claise Subject: New Version Notification for draft-ietf-netmod-yang-instance-file-format-08.txt A new version of I-D, draft-ietf-netmod-yang-instance-file-format-08.txt has been successfully submitted by Balazs Lengyel and posted to the IETF repository. Name: draft-ietf-netmod-yang-instance-file-format Revision: 08 Title: YANG Instance Data File Format Document date: 2020-03-09 Group: netmod Pages: 27 URL: https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-08 Abstract: There is a need to document data defined in YANG models when a live server is not available. Data is often needed already at design or implementation time or needed by groups that do not have a live running server available. 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. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat smime.p7s Description: S/MIME cryptographic 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-08.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-08.txt Pages : 27 Date: 2020-03-09 Abstract: There is a need to document data defined in YANG models when a live server is not available. Data is often needed already at design or implementation time or needed by groups that do not have a live running server available. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
On Mon, Mar 09, 2020 at 04:17:40PM +, Balázs Lengyel wrote: > See BALAZS4 below > > -Original Message- > From: Juergen Schoenwaelder > Sent: 2020. március 9., hétfő 10:44 > To: Balázs Lengyel > Subject: Re: [netmod] WG Last Call: > draft-ietf-netmod-yang-instance-file-format-06 > > > > -Original Message- > > > From: Schönwälder, Jürgen > > > Sent: 2020. február 12., szerda 10:07 > > > Subject: [Not Scanned] - Re: [netmod] WG Last Call: > > > draft-ietf-netmod-yang-instance-file-format-06 > > > > > > > - Is it necessary to describe P2 in terms of (presumably) NETCONF > > > > operations? I would prefer to have the document written in a > > > > protocol agnostic style. Perhaps simply drop "similar to the > > > > response of a operation/request". > > > > BALAZS: This is a reference both to NETCONF and RESTCONF. It was > > > > explicitly asked for by other reviewers. > > > > > > Well, then the correct wording would be "similar to the response of > > > a NETCONF operation or the RESTCONF response to a GET method > > > invocation on the (unified) datastore resource". Sounds complex and > > > I still prefer the text to be agnostic to specific operations - in > > > particular since and the unified datastore have their > > > limitations. The format is simply reusing the already defined data > > > model encoding formats, i.e., the format has nothing to do with the > > operations used to retrieve the data. So I suggest: > > > > > >P2 Instance data shall reuse existing encoding rules for > > >YANG defined data. > > > > > > There is no need to refer to specific protocol operations. > > > BALAZS: I will use both of your texts. That is the most common > > > question I > > > get: Will this use the same format as a get-reply? People like to > > > think in terms of a specific easy-to-grasp function instead of a > > > non-descript set of "existing" rules. Existing means you need to > > > understand X number of RFCs, while just looking up a get-reply is > > > easy. It is not precise, but IMHO that's how people think. > > > > If you write "reuse existing encoding rules", then actually fewer > > documents need to be understood. And operations have additional issues > > in how they interact with 'datastores', so they may even be misleading > > and I rather have the standards precise (and minimal normative > dependencies). > > BALAZS3: Sorry, I don't fully understand your point. What would you > > like in P2? > > The text now is: > > P2 Instance data shall reuse existing encoding rules for YANG > >defined data. Its format will be similar to the response of a > >NETCONF operation or the RESTCONF response to a GET method > >invocation on the (unified) datastore resource. > > It refers to existing rules as you asked for and also says" similar" > > to a get response, using phrasing from your email on 2020-02-12. > > Are you OK with this? Or how would you like to change it? > > What I proposed above: > >P2 Instance data shall reuse existing encoding rules for >YANG defined data. > > Your additional sentence is simply wrong. Instance data from lets say > with _not_ be 'similar' to the response of a NETCONF > operation or the RESTCONF response to a GET method invocation on the > (unified) datastore resource. The same holds true for instance data from > . > BALAZS4: I would like to keep the second part of the sentence. > 4+ people asked me explicitly to state this similarity during the > development of the draft. While your methodical and somewhat abstract way of > thinking has greatly helped me/us in many cases, IMHO other people often > think in the terms of examples and in recognizing known similar > methodology. As the we use the same encoding rules for get replies and for > instance data, IMHO they are similar even if instance data allows some > additions/omissions. (People liked/requested this statement, even though > "similar" is a rather subjective term.) > Anyway it is only included in the introduction part, so while it helps some > people, it should not cause problems with the precise definition of the > format. On your request I already removed a similar statement from the > normative parts. What the sentence says is unclear or plain wrong in a number of valid use cases (depends on how one understands the word "similar") and thus this sentence is misleading and asking for trouble down the road. I fully understand the value of examples but here we define what is called a 'basic principle' - and a basic principle that is not quite correct for all use cases sounds like a bad idea to me. If you want to write an example after the principles that is identifiable as an example, I am fine with that. As the sentence is worded right now as part of a 'basic principle', I am having an issue with the it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
See BALAZS4 below -Original Message- From: Juergen Schoenwaelder Sent: 2020. március 9., hétfő 10:44 To: Balázs Lengyel Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 > > -Original Message- > > From: Schönwälder, Jürgen > > Sent: 2020. február 12., szerda 10:07 > > Subject: [Not Scanned] - Re: [netmod] WG Last Call: > > draft-ietf-netmod-yang-instance-file-format-06 > > > > > - Is it necessary to describe P2 in terms of (presumably) NETCONF > > > operations? I would prefer to have the document written in a > > > protocol agnostic style. Perhaps simply drop "similar to the > > > response of a operation/request". > > > BALAZS: This is a reference both to NETCONF and RESTCONF. It was > > > explicitly asked for by other reviewers. > > > > Well, then the correct wording would be "similar to the response of > > a NETCONF operation or the RESTCONF response to a GET method > > invocation on the (unified) datastore resource". Sounds complex and > > I still prefer the text to be agnostic to specific operations - in > > particular since and the unified datastore have their > > limitations. The format is simply reusing the already defined data > > model encoding formats, i.e., the format has nothing to do with the > operations used to retrieve the data. So I suggest: > > > >P2 Instance data shall reuse existing encoding rules for > >YANG defined data. > > > > There is no need to refer to specific protocol operations. > > BALAZS: I will use both of your texts. That is the most common > > question I > > get: Will this use the same format as a get-reply? People like to > > think in terms of a specific easy-to-grasp function instead of a > > non-descript set of "existing" rules. Existing means you need to > > understand X number of RFCs, while just looking up a get-reply is > > easy. It is not precise, but IMHO that's how people think. > > If you write "reuse existing encoding rules", then actually fewer > documents need to be understood. And operations have additional issues > in how they interact with 'datastores', so they may even be misleading > and I rather have the standards precise (and minimal normative dependencies). > BALAZS3: Sorry, I don't fully understand your point. What would you > like in P2? > The text now is: > P2 Instance data shall reuse existing encoding rules for YANG >defined data. Its format will be similar to the response of a >NETCONF operation or the RESTCONF response to a GET method >invocation on the (unified) datastore resource. > It refers to existing rules as you asked for and also says" similar" > to a get response, using phrasing from your email on 2020-02-12. > Are you OK with this? Or how would you like to change it? What I proposed above: P2 Instance data shall reuse existing encoding rules for YANG defined data. Your additional sentence is simply wrong. Instance data from lets say with _not_ be 'similar' to the response of a NETCONF operation or the RESTCONF response to a GET method invocation on the (unified) datastore resource. The same holds true for instance data from . BALAZS4: I would like to keep the second part of the sentence. 4+ people asked me explicitly to state this similarity during the development of the draft. While your methodical and somewhat abstract way of thinking has greatly helped me/us in many cases, IMHO other people often think in the terms of examples and in recognizing known similar methodology. As the we use the same encoding rules for get replies and for instance data, IMHO they are similar even if instance data allows some additions/omissions. (People liked/requested this statement, even though "similar" is a rather subjective term.) Anyway it is only included in the introduction part, so while it helps some people, it should not cause problems with the precise definition of the format. On your request I already removed a similar statement from the normative parts. > > > - Why MUST XML attributes be ignored, why is there no text about > > > unknown JSON data, 'attributes' (or annotations)? What should > > > implementations generally do about unknown elements, attributes, > > > objects, arrays, ...)? Why are we specific about only one specific > > > case? > > > BALAZS: Generally we want to allow users/creators to decorate the > > > data with additional information, that is not standardized. Like > > > YANG extensions these may be useful, but at least should not > > > cause > problems. > > > XML attributes are often used as meta-data and I was asked to list > > > them specifically. > > > > > I do not understand why there are specific rules for XML encodings > > but not equivalent JSON rules. It looks like either the XML rules > > are not needed or equivalent JSON rules are missing if the XML rules > > are needed or there
Re: [netmod] Adoption of versioning design team docs
I support adoption of the design team work as well. Thanks, Acee On 3/9/20, 11:10 AM, "netmod on behalf of Ladislav Lhotka" wrote: I support the adoption of the entire document set. Lada Lou Berger writes: > Hi, > We'd like to start a two week adoption call for the set of documents described below by Rob. To be specific, this includes > 1) draft-verdt-netmod-yang-solutions-03 > 2) draft-verdt-netmod-yang-module-versioning-01 > 3) draft-verdt-netmod-yang-semver-01 > 4) draft-rwilton-netmod-yang-packages-03 > 5) draft-wilton-netmod-yang-ver-selection-02 > 6) draft-verdt-netmod-yang-schema-comparison-00 > > The adoption call ends in two weeks, on March 16. > > Please voice your support or objections on list. While we prefer to adopt as a set, objections on specific documents are acceptable. > > Netmod Chairs > > On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote: > >> Netmod chairs, >> >> The version selection draft draft-wilton-netmod-yang-ver-selection-02 is now posted. With that, the YANG versioning design team would like to please request you make an WG adoption call for these documents. >> >> The updated full list is: >> >> 1) draft-verdt-netmod-yang-solutions-03 >>- Solution overview, updated since 106 to cover updates to version selection and schema comparison drafts. >> >> 2) draft-verdt-netmod-yang-module-versioning-01 >>- Base module versioning solution, unchanged from the version presented at 106. >> >> 3) draft-verdt-netmod-yang-semver-01 >>- YANG Semantic version numbers, unchanged from the version presented at 106. >> >> 4) draft-rwilton-netmod-yang-packages-03 >>- YANG packages draft, updated since 106 >> >> 5) draft-wilton-netmod-yang-ver-selection-02 >>- Version selection, updated since 106, as per notes below >> >> 6) draft-verdt-netmod-yang-schema-comparison-00 >>- Schema comparison tooling, unchanged from the version presented at 106. >> >> The main changes to the version selection draft are: >>- We have tried to simplify the model, but at the same time give servers more flexibility about how they implement version selection and what it can be used for. E.g. if the server wants to allow a client to choose between different schema versions, but require that all clients use the same schema version, that is now possible >>- The draft explicitly disallows schema-selection happening mid-session >>- The solution allows the server to require clients to configure schema-sets before they are used >>- The solution provides more information about which schema-sets are compatible with each other >> >> Regards, >> Rob >> >> > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption of versioning design team docs
I support the adoption of the entire document set. Lada Lou Berger writes: > Hi, > We'd like to start a two week adoption call for the set of documents > described below by Rob. To be specific, this includes > 1) draft-verdt-netmod-yang-solutions-03 > 2) draft-verdt-netmod-yang-module-versioning-01 > 3) draft-verdt-netmod-yang-semver-01 > 4) draft-rwilton-netmod-yang-packages-03 > 5) draft-wilton-netmod-yang-ver-selection-02 > 6) draft-verdt-netmod-yang-schema-comparison-00 > > The adoption call ends in two weeks, on March 16. > > Please voice your support or objections on list. While we prefer to adopt as > a set, objections on specific documents are acceptable. > > Netmod Chairs > > On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote: > >> Netmod chairs, >> >> The version selection draft draft-wilton-netmod-yang-ver-selection-02 is now >> posted. With that, the YANG versioning design team would like to please >> request you make an WG adoption call for these documents. >> >> The updated full list is: >> >> 1) draft-verdt-netmod-yang-solutions-03 >>- Solution overview, updated since 106 to cover updates to version >> selection and schema comparison drafts. >> >> 2) draft-verdt-netmod-yang-module-versioning-01 >>- Base module versioning solution, unchanged from the version presented >> at 106. >> >> 3) draft-verdt-netmod-yang-semver-01 >>- YANG Semantic version numbers, unchanged from the version presented at >> 106. >> >> 4) draft-rwilton-netmod-yang-packages-03 >>- YANG packages draft, updated since 106 >> >> 5) draft-wilton-netmod-yang-ver-selection-02 >>- Version selection, updated since 106, as per notes below >> >> 6) draft-verdt-netmod-yang-schema-comparison-00 >>- Schema comparison tooling, unchanged from the version presented at 106. >> >> The main changes to the version selection draft are: >>- We have tried to simplify the model, but at the same time give servers >> more flexibility about how they implement version selection and what it can >> be used for. E.g. if the server wants to allow a client to choose between >> different schema versions, but require that all clients use the same schema >> version, that is now possible >>- The draft explicitly disallows schema-selection happening mid-session >>- The solution allows the server to require clients to configure >> schema-sets before they are used >>- The solution provides more information about which schema-sets are >> compatible with each other >> >> Regards, >> Rob >> >> > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-solutions-03
"No, I'm not aware of any IPR that applies to this draft" https://tools.ietf.org/html/draft-verdt-netmod-yang-solutions-03#section-3 o Balazs Lengyel o Benoit Claise o Ebben Aries o Jason Sterne o Joe Clarke o Juergen Schoenwaelder o Mahesh Jethanandani o Michael (Wangzitao) o Qin Wu o Reshad Rahman o Rob Wilton o Susan Hares o Wu Bo Regards, B. Authors, Contributors, WG, As part of preparation for WG Adoption: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. We note that all DT members are listed as contributors. If you contributed to the document please respond. Alternatively, please feel free to state that you didn't materially contribute to the draft and would like your name removed from the contribution section (and moved to acknowledgments after WG adoption). If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NetMod WG Chairs PS Please include all listed in the headers of this message in your response. ___ Netmod-ver-dt mailing list netmod-ver...@ietf.org https://www.ietf.org/mailman/listinfo/netmod-ver-dt . ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-schema-comparison-00
Hi Lou, "No, I'm not aware of any IPR that applies to this draft" Note: there are more contributors. See https://tools.ietf.org/html/draft-verdt-netmod-yang-schema-comparison-00#section-8 o Balazs Lengyel o Benoit Claise o Bo Wu o Ebben Aries o Jason Sterne o Joe Clarke o Juergen Schoenwaelder o Mahesh Jethanandani o Michael Wang o Qin Wu o Reshad Rahman o Rob Wilton regards, Benoit. Authors, Contributors, WG, As part of preparation for WG Adoption: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. We note that all DT members are listed as contributors. If you contributed to the document please respond. Alternatively, please feel free to state that you didn't materially contribute to the draft and would like your name removed from the contribution section (and moved to acknowledgments after WG adoption). If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NetMod WG Chairs PS Please include all listed in the headers of this message in your response. ___ Netmod-ver-dt mailing list netmod-ver...@ietf.org https://www.ietf.org/mailman/listinfo/netmod-ver-dt . ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption of versioning design team docs
Support. Regards, B. As a contributor/DT-member I support the adoption of this set of documents. *From:*netmod *On Behalf Of *Lou Berger *Sent:* Monday, March 2, 2020 5:30 PM *To:* NETMOD Group *Cc:* netmod-cha...@ietf.org *Subject:* [netmod] Adoption of versioning design team docs Hi, We'd like to start a two week adoption call for the set of documents described below by Rob. To be specific, this includes 1) draft-verdt-netmod-yang-solutions-03 2) draft-verdt-netmod-yang-module-versioning-01 3) draft-verdt-netmod-yang-semver-01 4) draft-rwilton-netmod-yang-packages-03 5) draft-wilton-netmod-yang-ver-selection-02 6) draft-verdt-netmod-yang-schema-comparison-00 The adoption call ends in two weeks, on March 16. Please voice your support or objections on list. While we prefer to adopt as a set, objections on specific documents are acceptable. Netmod Chairs On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote: Netmod chairs, The version selection draft draft-wilton-netmod-yang-ver-selection-02 is now posted. With that, the YANG versioning design team would like to please request you make an WG adoption call for these documents. The updated full list is: 1) draft-verdt-netmod-yang-solutions-03 - Solution overview, updated since 106 to cover updates to version selection and schema comparison drafts. 2) draft-verdt-netmod-yang-module-versioning-01 - Base module versioning solution, unchanged from the version presented at 106. 3) draft-verdt-netmod-yang-semver-01 - YANG Semantic version numbers, unchanged from the version presented at 106. 4) draft-rwilton-netmod-yang-packages-03 - YANG packages draft, updated since 106 5) draft-wilton-netmod-yang-ver-selection-02 - Version selection, updated since 106, as per notes below 6) draft-verdt-netmod-yang-schema-comparison-00 - Schema comparison tooling, unchanged from the version presented at 106. The main changes to the version selection draft are: - We have tried to simplify the model, but at the same time give servers more flexibility about how they implement version selection and what it can be used for. E.g. if the server wants to allow a client to choose between different schema versions, but require that all clients use the same schema version, that is now possible - The draft explicitly disallows schema-selection happening mid-session - The solution allows the server to require clients to configure schema-sets before they are used - The solution provides more information about which schema-sets are compatible with each other Regards, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption of versioning design team docs
As a contributor/DT-member I support the adoption of this set of documents. From: netmod On Behalf Of Lou Berger Sent: Monday, March 2, 2020 5:30 PM To: NETMOD Group Cc: netmod-cha...@ietf.org Subject: [netmod] Adoption of versioning design team docs Hi, We'd like to start a two week adoption call for the set of documents described below by Rob. To be specific, this includes 1) draft-verdt-netmod-yang-solutions-03 2) draft-verdt-netmod-yang-module-versioning-01 3) draft-verdt-netmod-yang-semver-01 4) draft-rwilton-netmod-yang-packages-03 5) draft-wilton-netmod-yang-ver-selection-02 6) draft-verdt-netmod-yang-schema-comparison-00 The adoption call ends in two weeks, on March 16. Please voice your support or objections on list. While we prefer to adopt as a set, objections on specific documents are acceptable. Netmod Chairs On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote: Netmod chairs, The version selection draft draft-wilton-netmod-yang-ver-selection-02 is now posted. With that, the YANG versioning design team would like to please request you make an WG adoption call for these documents. The updated full list is: 1) draft-verdt-netmod-yang-solutions-03 - Solution overview, updated since 106 to cover updates to version selection and schema comparison drafts. 2) draft-verdt-netmod-yang-module-versioning-01 - Base module versioning solution, unchanged from the version presented at 106. 3) draft-verdt-netmod-yang-semver-01 - YANG Semantic version numbers, unchanged from the version presented at 106. 4) draft-rwilton-netmod-yang-packages-03 - YANG packages draft, updated since 106 5) draft-wilton-netmod-yang-ver-selection-02 - Version selection, updated since 106, as per notes below 6) draft-verdt-netmod-yang-schema-comparison-00 - Schema comparison tooling, unchanged from the version presented at 106. The main changes to the version selection draft are: - We have tried to simplify the model, but at the same time give servers more flexibility about how they implement version selection and what it can be used for. E.g. if the server wants to allow a client to choose between different schema versions, but require that all clients use the same schema version, that is now possible - The draft explicitly disallows schema-selection happening mid-session - The solution allows the server to require clients to configure schema-sets before they are used - The solution provides more information about which schema-sets are compatible with each other Regards, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] WG Last Call of CORECONF drafts: draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01
It took us a long time to get the four CORECONF drafts in sync, but now we are ready for WGLC. This starts a working group last call for — draft-ietf-core-yang-cbor-12 — draft-ietf-core-sid-11 — draft-ietf-core-comi-09 — draft-ietf-core-yang-library-01 ending on 24:00 UTC on Tuesday, March 31, 2020. (This includes some extra time for the IETF week and for cross-WG coordination.) This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater YANG/NETCONF/RESTCONF family. We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or RESTCONF, feel free to discuss that on netmod instead. Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. (Minor issues such as typos can also be sent to the authors.) If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been. (To reviewers and authors:) If you are aware of any patent claims that might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help. Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06
On Fri, Mar 06, 2020 at 12:01:47PM +, Balázs Lengyel wrote: > Hello Jurgen, > See answers below as "BALAZS3". I am putting them into the -08 revision this > weekend. > One general comment: > As partial data sets are allowed, it is not always necessary to indicate if > a feature is not supported. > E.g. If you have an instance dataset for ietf-system, which does not include > authentication data, > you do not care whether the feature authentication is supported or not. > Similarly if the deviation does not impact your particular instance data > items, you might not care to specify it. > Regards Balazs > > -Original Message- > From: Schönwälder, Jürgen > Sent: 2020. február 19., szerda 11:17 > To: Balázs Lengyel > Cc: Kent Watsen ; NETMOD Working Group > > Subject: Re: [netmod] WG Last Call: > draft-ietf-netmod-yang-instance-file-format-06 > > On Thu, Feb 13, 2020 at 01:40:13PM +, Balázs Lengyel wrote: > > See below as BALAZS2. > > > > -Original Message- > > From: Schönwälder, Jürgen > > Sent: 2020. február 12., szerda 10:07 > > Subject: [Not Scanned] - Re: [netmod] WG Last Call: > > draft-ietf-netmod-yang-instance-file-format-06 > > > > > - Is it necessary to describe P2 in terms of (presumably) NETCONF > > > operations? I would prefer to have the document written in a > > > protocol agnostic style. Perhaps simply drop "similar to the > > > response of a operation/request". > > > BALAZS: This is a reference both to NETCONF and RESTCONF. It was > > > explicitly asked for by other reviewers. > > > > Well, then the correct wording would be "similar to the response of a > > NETCONF operation or the RESTCONF response to a GET method > > invocation on the (unified) datastore resource". Sounds complex and I > > still prefer the text to be agnostic to specific operations - in > > particular since and the unified datastore have their > > limitations. The format is simply reusing the already defined data > > model encoding formats, i.e., the format has nothing to do with the > operations used to retrieve the data. So I suggest: > > > >P2 Instance data shall reuse existing encoding rules for > >YANG defined data. > > > > There is no need to refer to specific protocol operations. > > BALAZS: I will use both of your texts. That is the most common > > question I > > get: Will this use the same format as a get-reply? People like to > > think in terms of a specific easy-to-grasp function instead of a > > non-descript set of "existing" rules. Existing means you need to > > understand X number of RFCs, while just looking up a get-reply is > > easy. It is not precise, but IMHO that's how people think. > > If you write "reuse existing encoding rules", then actually fewer documents > need to be understood. And operations have additional issues in how they > interact with 'datastores', so they may even be misleading and I rather have > the standards precise (and minimal normative dependencies). > BALAZS3: Sorry, I don't fully understand your point. What would you like in > P2? > The text now is: > P2 Instance data shall reuse existing encoding rules for YANG >defined data. Its format will be similar to the response of a >NETCONF operation or the RESTCONF response to a GET method >invocation on the (unified) datastore resource. > It refers to existing rules as you asked for and also says" similar" to a > get response, using phrasing from your email on 2020-02-12. > Are you OK with this? Or how would you like to change it? What I proposed above: P2 Instance data shall reuse existing encoding rules for YANG defined data. Your additional sentence is simply wrong. Instance data from lets say with _not_ be 'similar' to the response of a NETCONF operation or the RESTCONF response to a GET method invocation on the (unified) datastore resource. The same holds true for instance data from . > > > - Why MUST XML attributes be ignored, why is there no text about > > > unknown JSON data, 'attributes' (or annotations)? What should > > > implementations generally do about unknown elements, attributes, > > > objects, arrays, ...)? Why are we specific about only one specific > > > case? > > > BALAZS: Generally we want to allow users/creators to decorate the > > > data with additional information, that is not standardized. Like > > > YANG extensions these may be useful, but at least should not cause > problems. > > > XML attributes are often used as meta-data and I was asked to list > > > them specifically. > > > > > I do not understand why there are specific rules for XML encodings but > > not equivalent JSON rules. It looks like either the XML rules are not > > needed or equivalent JSON rules are missing if the XML rules are > > needed or there should be an explanation why the different encodings > > lead to different results (which is operationally rather surprising). > > BALAZS2:XML
