Re: [netmod] Y45-04 and ietf-yang-library
On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server.; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO SHOULD use latest is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). This sounds like lets pretend the world is simple so we have less work to do. No -- YANG currently says if there is no revision date then the implementation can use any revision, Exactly - any revision. This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. Did I say all imports? No. I think a server should announce which revision was picked to resolve imports without a revision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y45-04 and ietf-yang-library
On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server.; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO SHOULD use latest is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). This sounds like lets pretend the world is simple so we have less work to do. No -- YANG currently says if there is no revision date then the implementation can use any revision, This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. /js Andy -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] YANG Models Required for Managing CPE Devices
Hi, while there is a lot of YANG activity outside this WG that usually does not get echoed here (which is goodness since we can't really track everything here), I thought this one deserves some recognition here because it provides a good overview of what we have, what is ongoing, and what is missing for managing a CPE using YANG data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ---BeginMessage--- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Models Required for Managing Customer Premises Equipment (CPE) Devices Authors : Ian Farrer Qi Sun Sladjana Zoric Mikael Abrahamsson Filename: draft-faq-anima-cpe-yang-profile-00.txt Pages : 13 Date: 2015-07-06 Abstract: This document collects together the YANG models necessary for managing a NETCONF-enabled Customer Premises Equipment (CPE) device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-faq-anima-cpe-yang-profile/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-faq-anima-cpe-yang-profile-00 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/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---End Message--- ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Interim Meeting Minutes June 25, 2015
These are the preliminary notes from the interim meeting on June 25, 2015. I am still awaiting notes from Ignas who also took meeting minutes before I post the official minutes. If there are any comments/corrections to what I have below, please post here as soon as possible. —Tom NETMOD Virtual Interim Meeting (June 25, 2015) * Participants - Acee (AC) - Alia Atlas - Andy Bierman - Anees Shaikh - Aseem Choudhary - Balazs Lengyel - Benoit Claise - Clyde Wildes - Dan Romascanu - Einar - Giles - Ignas Bagdonas - Jason Sterne (JS) - Kent Watsen - Mahesh Jethanandani - Marcus - Martin Bjorklund - Phil Shafer - Qin Wu - Robert Wilton - Sam Aldrin - Susan Hares - Tarek Saad - Tom Nadeau - Vishnu Pavan Beeram - Xufeng Liu - Yingzhen Qu Meeting starting (10:06am ET) Agenda: - Agenda Bashing - draft-openconfig-netmod-opstate-00 - draft-openconfig-netmod-model-structure-00 Anees Presenting Going over terminology based on slides exchanged over e-mail. Applied/actual configuration should not be fetched when a yet to be defined get-oper is defined. In other words, get operational should fetch only protocol negotiated values and counters. This would require a flag other than config = false to be defined. - KW: is the applied/actual having the value auto? - AS: yes - KW: would the term distributed be better? - AS: no - JS: how far do we need to go to consider a config node applied? (e.g., distributed systems) - AS: systems will differ, what matters is what they perceive to be applied - SH: where would ephemeral state be catured? - AS: it's not captured in this model, but makes sense to view as intended config that is not persisted - MB: where would interfaces configured by system (not user-configured) be captured in this model? - AS: should be part of intended config - MB: so system should update intended config to capture/add these additional nodes - M?: should show up in applied config (not intended) - MB: so applied config can contain more than just intended config... - AB: applied state a child of indended state? - MB: right, since parent is config=true - RW: given interfaces MAY have config, then an unconfigured interface (line card plugged in) still takes default config, no? - AS: makes sense that there are some default config values applied to it, just not from intended config - SH: ephemeral operational state goes into operational state too? - AS: yes - AB: proposal about data organization, but there is a yang statement too - AS: no, proposal has both. - AB: Disagree duplicating data-model nodes, scales better to use datastores [KW: Juergen made same point on list] - AS: - MB: agree that should be possible to use w/o NC, but datastores aren't NC-specific either [witness RC] - TN: isn't this the same thing? - two option: decorate model vs add an operation - BL: protocol option better, as otherwise it would grow the saize of the model greatly - AS: putting it into the model (data structure) can be simpler - MB: is 9/10 follow model-structure, but 10th doesn't, even though valid YANG, the whole thing falls down - AB: overloading names could cause conflict - e.g., an address book's State value - AS: may not be important to standardize models at this stage, without much much operational experience, not too much value in existing models - BC: do we have people that want to work on an optional proposal? [no one steps forward] Moving on to model-structure draft (10:58am ET) - Anees presenting - MB: how is putting a device node under arbitrary parent? - AS: useful anchor point, not stricly necessary but very useful and don't see anything harmful in it - AB: adds more payload to every message in every protocol - AS: don't understand payload comment - AB: adds string to instance-identifier - BL: ex: alarm, the length of the instance-identifier is an important point - MB: what's the point of having top-level /device, why not just /? - PS: more than that... i missed it - AS: so bring up everything one level would be better? - MB: yes - AS: yeah, i agree - AA: what is the argument behind having /device? - string length? - AB: no value - AS: thought a single anchor would be useful - BC: regardless of single anchor, is there agreement of having any common anchor points? - AB: likes catalog part - BC: likes it too, who would organize it? - KW: like catalog too, but thinks the catalog should also contain transformation to/from lower-level models - AS: agrees that there can be a multiplicity of top-level models - TN: this may need to be an informational draft Moving on to Meta-Model Structure slides (Acee presenting) - JS: re: logical network level, should different logical routers have different NETCONF sessions? - AC: sounds like an SNMP like solution - SH: why policy under each
[netmod] Open Config Options
One of the actions from the last Interim meeting was to have both sides of the issues around the open config approach to create at least slides/textual bullet points for use during our discussion in Praha so we can come to a conclusion around the final issues. We need these slides/bullet points to be listed on the list here and continue the discussion here BEFORE the Praha meeting. I’d like to ask Anees and Rob to write up their side of the story. As I recall Juergen, Kent, Martin and Andy were the most vocal around the other side of things, so I would like to ask them to write up their side of things. Can you all please confirm your acceptance of this action and a target for when you will post the issues? —Tom ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Open Config Options
Hi, Nadeau Thomas tnad...@lucidvision.com wrote: One of the actions from the last Interim meeting was to have both sides of the issues around the open config approach to create at least slides/textual bullet points for use during our discussion in Praha so we can come to a conclusion around the final issues. We need these slides/bullet points to be listed on the list here and continue the discussion here BEFORE the Praha meeting. I’d like to ask Anees and Rob to write up their side of the story. As I recall Juergen, Kent, Martin and Andy were the most vocal around the other side of things, so I would like to ask them to write up their side of things. Can you all please confirm your acceptance of this action and a target for when you will post the issues? We have posted our thoughts in this draft: https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Open Config Options
thats a good start. lets please discuss the merits and pros/cons vs the open cconfig proposal. On Jul 6, 2015, at 3:59 PM, Martin Bjorklund m...@tail-f.com wrote: Hi, Nadeau Thomas tnad...@lucidvision.com wrote: One of the actions from the last Interim meeting was to have both sides of the issues around the open config approach to create at least slides/textual bullet points for use during our discussion in Praha so we can come to a conclusion around the final issues. We need these slides/bullet points to be listed on the list here and continue the discussion here BEFORE the Praha meeting. I’d like to ask Anees and Rob to write up their side of the story. As I recall Juergen, Kent, Martin and Andy were the most vocal around the other side of things, so I would like to ask them to write up their side of things. Can you all please confirm your acceptance of this action and a target for when you will post the issues? We have posted our thoughts in this draft: https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Open Config Options
fantastic! On Jul 6, 2015, at 4:14 PM, Anees Shaikh aasha...@google.com wrote: We've posted a new version of our draft: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 It includes a section on the issues that were raised and our observation/comment. It also adds a detailed section on terminology based on the interim calls, and updates the operational requirements with further details. thanks. -- Anees On Mon, Jul 6, 2015 at 12:59 PM, Martin Bjorklund m...@tail-f.com wrote: Hi, Nadeau Thomas tnad...@lucidvision.com wrote: One of the actions from the last Interim meeting was to have both sides of the issues around the open config approach to create at least slides/textual bullet points for use during our discussion in Praha so we can come to a conclusion around the final issues. We need these slides/bullet points to be listed on the list here and continue the discussion here BEFORE the Praha meeting. I’d like to ask Anees and Rob to write up their side of the story. As I recall Juergen, Kent, Martin and Andy were the most vocal around the other side of things, so I would like to ask them to write up their side of things. Can you all please confirm your acceptance of this action and a target for when you will post the issues? We have posted our thoughts in this draft: https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] UML to YANG mapping
Hello Netmod! https://tools.ietf.org/html/draft-mansfield-netmod-uml-to-yang-00 has been posted. This draft is attempting to open a discussion on how best to translate from a UML model to a YANG model. If you are interested in such things, please take a look at the content, but please pay particular attention to where the draft is missing content. The authors would like to hear from experts on how to interpret the various UML artefacts in order to help provide guidelines on how to leverage UML as a part of a model-driven development lifecycle. A note about the format of the draft. I write using the XML template. There are .jpeg image files that are included in some artwork tags. I used the rfc2629xslt tool to translate to HTML and then to PDF (so that the image files are included). I then submitted the TXT, XML, and PDF (there is no option upload the HTML in the submit tool). So, the only version of the draft that shows the image files is the PDF (because the HTML file was generated from the TXT file). I know this isn't the group to discuss how to get the formats to work out (I'll work on that), but I wanted the readers to know where to find the image files for this -00 draft. Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Open Config Options
We've posted a new version of our draft: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 It includes a section on the issues that were raised and our observation/comment. It also adds a detailed section on terminology based on the interim calls, and updates the operational requirements with further details. thanks. -- Anees On Mon, Jul 6, 2015 at 12:59 PM, Martin Bjorklund m...@tail-f.com wrote: Hi, Nadeau Thomas tnad...@lucidvision.com wrote: One of the actions from the last Interim meeting was to have both sides of the issues around the open config approach to create at least slides/textual bullet points for use during our discussion in Praha so we can come to a conclusion around the final issues. We need these slides/bullet points to be listed on the list here and continue the discussion here BEFORE the Praha meeting. I’d like to ask Anees and Rob to write up their side of the story. As I recall Juergen, Kent, Martin and Andy were the most vocal around the other side of things, so I would like to ask them to write up their side of things. Can you all please confirm your acceptance of this action and a target for when you will post the issues? We have posted our thoughts in this draft: https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] I-D Action: draft-ietf-netmod-rfc6087bis-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename: draft-ietf-netmod-rfc6087bis-04.txt Pages : 52 Date: 2015-07-06 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-04 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
[netmod] YANG Packages draft
Hi, I submitted a new draft for defining YANG packages. http://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt IMO this could be useful for organizing YANG modules. It may also be applicable for CoMI, by allowing a tiny number of packages to be advertised to the client, instead of a relatively large number of modules. Andy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] I-D Action: draft-ietf-netmod-syslog-model-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : SYSLOG YANG model Author : Clyde Wildes Filename: draft-ietf-netmod-syslog-model-04.txt Pages : 21 Date: 2015-07-06 Abstract: This document describes a data model for Syslog protocol which is used to convey event notification messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-04 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
[netmod] Number of YANG models these days
Dear all, Just after the IETF draft submission deadline today, here are the latest numbers: Number of correctly extracted YANG models from IETF drafts: 155 Number of YANG models in IETF drafts that passed compilation without warnings: 58/155 Number of YANG models in IETF drafts that passed compilation with warnings: 35/155 Number of all YANG models in IETF drafts (example, badly formatted, etc. ): 253 Happy to see that more and more YANG models compile without any errors/warnings. Recently (June 25th), the opendaylight shipped in first release: Lithium Number of YANG models in Hydrogen release: 117 Number of YANG models in Helium release: 220 Number of YANG models in Lithium release: 473 The numbers keep increasing. It should not be a surprise for anybody. Regards, Benoit ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y45-04 and ietf-yang-library
On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server.; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO SHOULD use latest is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). This sounds like lets pretend the world is simple so we have less work to do. No -- YANG currently says if there is no revision date then the implementation can use any revision, Exactly - any revision. This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. Did I say all imports? No. I think a server should announce which revision was picked to resolve imports without a revision. But it could be any revision. A imports B.1 imports C D imports B.4 imports C E imports F imports G imports C Can we agree on all imports without a revision fixed in the data model? C can be imported many times without revision. Yes. Any import in the chain can be with out without a revision date. Yes. IMO SHOULD use latest revision of C advertised is best because the latest revision is generally the most correct and supports the most product features. But I thought the goal was to know precisely what a device implements, not what it _could_ implement. If the import of C really depends on specific revisions of some typedefs, groupings, etc. then import by revision MUST be used everywhere in the dependency chain (C and all its imports). If no revision-stmt is present the server can pick whatever revision it wants. If this is a problem, then fix this problem, don't add some complex monitoring requirements for servers to implement and clients to process. Let's make import-by-revision mandatory if import-without-revision is a such a problem. If the data model leaves it open, then indeed the implementor can choose. What is wrong with reporting what was chosen? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y45-04 and ietf-yang-library
On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server.; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO SHOULD use latest is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). This sounds like lets pretend the world is simple so we have less work to do. No -- YANG currently says if there is no revision date then the implementation can use any revision, Exactly - any revision. This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. Did I say all imports? No. I think a server should announce which revision was picked to resolve imports without a revision. But it could be any revision. A imports B.1 imports C D imports B.4 imports C E imports F imports G imports C Can we agree on all imports without a revision fixed in the data model? That's not what the RFC 6020 says (not sure about bis) C can be imported many times without revision. Yes. Any import in the chain can be with out without a revision date. Yes. IMO SHOULD use latest revision of C advertised is best because the latest revision is generally the most correct and supports the most product features. But I thought the goal was to know precisely what a device implements, not what it _could_ implement. If the import of C really depends on specific revisions of some typedefs, groupings, etc. then import by revision MUST be used everywhere in the dependency chain (C and all its imports). If no revision-stmt is present the server can pick whatever revision it wants. If this is a problem, then fix this problem, don't add some complex monitoring requirements for servers to implement and clients to process. Let's make import-by-revision mandatory if import-without-revision is a such a problem. If the data model leaves it open, then indeed the implementor can choose. What is wrong with reporting what was chosen? If there is just a leaf that says 'default-revision=true' like I proposed, then no problem. If I have to reproduce the entire imports/include-imports tree with filled in revision dates, then this is overkill, too much memory/data, and it is a problem. /js Andy -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] presentations for ietf 93
The NETMOD working group is meeting twice for IETF 93 in Prague: Monday: 18:50-19:50 (1 hour) Tuesday: 15:20-17:20 (2 hours) If you would like to request a time-slot for a presentation at IETF 93, please reply by Friday, July 10th with the following information: 1) Draft title 2) Presenter name 3) Requested duration Requests for slots with discussion on the mailing list are given priority. Please start a discussion on your draft now if needed. Thanks, Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-06.txt
Hi, This version addresses Y45, except that it may need to be aligned with any data model changes in ietf-yang-library. There is now one remaining issue, Y60, that has to do with coexistence with YANG 1.0. Please see https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-61 /martin internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename: draft-ietf-netmod-rfc6020bis-06.txt Pages : 196 Date: 2015-07-06 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-06 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y45-04 and ietf-yang-library
On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server.; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO SHOULD use latest is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). This sounds like lets pretend the world is simple so we have less work to do. No -- YANG currently says if there is no revision date then the implementation can use any revision, Exactly - any revision. This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. Did I say all imports? No. I think a server should announce which revision was picked to resolve imports without a revision. But it could be any revision. A imports B.1 imports C D imports B.4 imports C E imports F imports G imports C C can be imported many times without revision. Any import in the chain can be with out without a revision date. IMO SHOULD use latest revision of C advertised is best because the latest revision is generally the most correct and supports the most product features. If the import of C really depends on specific revisions of some typedefs, groupings, etc. then import by revision MUST be used everywhere in the dependency chain (C and all its imports). If no revision-stmt is present the server can pick whatever revision it wants. If this is a problem, then fix this problem, don't add some complex monitoring requirements for servers to implement and clients to process. Let's make import-by-revision mandatory if import-without-revision is a such a problem. /js Andy -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
