Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93
Can we please stop this cross-posting thread? /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
[netmod] Y45 - time to summarize and decide
Hi, over last few days, I contacted the WG members that were active in the recent discussion round concerning Y45 in order to find out what their state of thinking is. Here is the result: | Contributor | Preference | Acceptable| Objections | |--++---+| | Martin Bjorklund | Y45-04 | Y45-05,Y45-03 | Y45-02, DEAD | | Lada Lhotka | Y45-04 | Y45-03,Y45-05 | all others | | Xiang Li | Y45-05 | Y45-04,Y45-03 | Y45-02, DEAD | | Andy Bierman | Y45-03 | | Y45-04, Y45-05 | | Randy Presuhn| Y45-04 | Y45-02| Y45-01, Y45-03, Y45-05 | |--++---+| I am happy to add more opinions should there be more contributors with a clear opinion on Y45. But please speak up quickly (ideally by the beginning of next week, that is May 18th.) So far, it seems there is consensus that there is agreement to address Y45 (that is to not simply declare it dead). And so far, Y45-04 clearly is the strongest candidate. Note that Y45 is the last technical issue waiting to be resolved and it is time to decide and then to move on. /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
[netmod] diffserv model questions
Hi, what is the purpose of the feature policy-template-support in draft-asechoud-netmod-diffserv-model-01.txt? Can I use the model without this feature? I also note that no implementable object is left in ietf-diffserv-policy if I do not support the feature policy-template-support. Is this useful? Is it a bug or a feature to support inline classifier definitions? Is it correct that actions are always 'inline' so to say? Is this a bug or a feature? /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
[netmod] VRFY :45: better conformance mechanism
Hi, after long discussions in physical meetings, virtual meetings, and on the mailing list, I believe we have reached rough consensus to adopt Y45-04 in order to resolve import ambiguities (aka typedef drift and grouping drift) and we will leave it to YANG extensions (to be worked on in the future) to provide means to define explicit conformance requirements (instead of trying to derive conformance requirements from import relationships alone). A recent poll of core contributors on this issue can be found here: http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html Please speak up by Monday 2015-05-25 if you disagree with this proposal and your position is not yet included in the email message pointed to above. For more details, see the issues list available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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] VRFY :45: better conformance mechanism
On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote:
> Hi,
>
> RFC 6020, sec. 7.1.5 has this sentence:
>
>Multiple revisions of the same module MUST NOT be imported.
>
> I expect the new RFC will contain a complete explanation why
> this MUST NOT is wrong and needs to be changed.
> I would expect that multiple implementation examples of this
> approach can be cited, as proof that the new solution already works
> (before it is standardized).
>
The attached yang module compiles using pyang 1.3 and if you replace
yang1:uuid with yang0:uuid, you get an error (as one would expect).
Depending on how your code is organized, the Y45-04 behaviour may fall
out naturally and it takes extra effort to implement the MUST quoted
above. It may be possible to find a second implementation that
actually does not implement this MUST. (Our libsmi code has a problem
with import-by-revision so it is not a candidate unless we implement
this.)
The reason to change the MUST quoted above can certainly be explained.
/js
PS: Yes, pyang is broken wrt. YANG 1.0 since it does not implement
the MUST quoted above.
--
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/>
module aa {
namespace "http://aa.example.com/";;
prefix aa;
import ietf-yang-types {
prefix yang0;
revision-date 2010-09-24;
}
import ietf-yang-types {
prefix yang1;
revision-date 2013-07-15;
}
leaf a {
type yang0:counter32;
}
leaf b {
type yang1:uuid;
}
}___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] diffserv model questions
On Tue, May 19, 2015 at 07:57:26PM +, Aseem Choudhary (asechoud) wrote: > Hi Juergen, > > Please find the replies inline. > > -thanks, > Aseem > > On 5/18/15, 10:20 AM, "Juergen Schoenwaelder" > wrote: > > >Hi, > > > >what is the purpose of the feature policy-template-support in > >draft-asechoud-netmod-diffserv-model-01.txt? Can I use the model > >without this feature? > > > >I also note that no implementable object is left in > >ietf-diffserv-policy if I do not support the feature > >policy-template-support. Is this useful? > > [AC] ietf-diffserv-policy module defines policy as a template. The other > option is to configure & apply it directly under target as defined in > ietf-diffserv-target module. OK, but why is there a feature since this 'policy' is an extension defined in a separate YANG model? > >Is it a bug or a feature to support inline classifier definitions? Is > >it correct that actions are always 'inline' so to say? Is this a bug > >or a feature? > > [AC] Classifier can be defined inline or can be defined as a separate > template and referred in the policy definition. Yes, but is this a bug or a feature? From an implementation perspective, this sounds like extra cost. So what is the benefit of having both options? > All the actions are defined inline. This is the most common use-case. Hm. Why are classifiers and actions treated differently? Perhaps some discussion of the design decisions somewhere in the document would be useful. /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] VRFY :45: better conformance mechanism
On Tue, May 19, 2015 at 09:22:29AM -0700, Andy Bierman wrote: > On Tue, May 19, 2015 at 8:55 AM, Juergen Schoenwaelder > wrote: > > On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> RFC 6020, sec. 7.1.5 has this sentence: > >> > >>Multiple revisions of the same module MUST NOT be imported. > >> > >> I expect the new RFC will contain a complete explanation why > >> this MUST NOT is wrong and needs to be changed. > >> I would expect that multiple implementation examples of this > >> approach can be cited, as proof that the new solution already works > >> (before it is standardized). > >> > > > > The attached yang module compiles using pyang 1.3 and if you replace > > yang1:uuid with yang0:uuid, you get an error (as one would expect). > > A tool that parses the syntax is not really the same > as a server implementation. I do not question the ability > to distinguish 2 different strings as 2 different prefixes. How does the resolution of symbols (typedef and grouping names) at module compile time impact the server implementation? > > Depending on how your code is organized, the Y45-04 behaviour may fall > > out naturally and it takes extra effort to implement the MUST quoted > > above. It may be possible to find a second implementation that > > actually does not implement this MUST. (Our libsmi code has a problem > > with import-by-revision so it is not a candidate unless we implement > > this.) > > > > The reason to change the MUST quoted above can certainly be explained. > > > > So what is the explanation? > Removing a MUST NOT (especially from a 1.1 maintenance release) > is a big deal. I would expect it to be easy to demonstrate that > the original MUST NOT is a bug. > The original MUST NOT makes it expensive to upgrade since it is an all or nothing upgrade mechanism and the only way to ease the pain is that the module author anticipates incremental updates and maintains N different versions of definitions to ease the pain. The NETMOD principle has always been that module readers are first priority, module writers are second priority, and tool implementers are third priority. Yes, Y45-04 is a change for tool implementors (except perhaps tools that failed to implement the MUST NOT) but it is done for a reason. /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] VRFY :45: better conformance mechanism
On Tue, May 19, 2015 at 09:20:52PM +, Kent Watsen wrote: > > > It's unclear to me why Y45-04 is needed at all. Doesn't a newer revision > of a module contain all the same typedefs from before, and thus a module > could import just the more recent revision to get everything it needs? > Why would a module ever have to import an older revision? > > RFC 6020 says "New typedefs, groupings, rpcs, notifications, extensions, > features, and identities may be added." I take this to imply that they > cannot be removed or even renamed. Is this not the case? > The definitions can be changed and Y45 is about making sure that we always know precisely which definition is used - this was called typedef drift and grouping drift. Please check the extensive discussions we had about this plus the I-Ds people wrote about this. I do not think we should restart this discussion once more. /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] VRFY :45: better conformance mechanism
On Wed, May 20, 2015 at 10:51:28AM -0700, Andy Bierman wrote: > The solution is not intuitive at all. The implications of cherry-picking > YANG statements from various revisions of a YANG module are > not well understood. If there are issues that have not been brought up before that we do not understand, please put them on the table. But things need to be concrete, not abstract. > The concept of writing a YANG module so it works with all possible > combinations of all possible back-revisions of imported modules is > not well understood. This is an example of an abstract claim that is difficult to work with. > The question "why can't the module being updated use the latest revision > of an import" is quite legitimate. So is the question "Why can't I determine > what a server implementation is required to support for a given YANG module?" > > The issue title "Better YANG conformance" is misleading because YANG > conformance specificity is actually much worse with this solution. > It's great for vendors who want to interpret for themselves > what conformance means. This is what I wrote: I believe we have reached rough consensus to adopt Y45-04 in order to resolve import ambiguities (aka typedef drift and grouping drift) and we will leave it to YANG extensions (to be worked on in the future) to provide means to define explicit conformance requirements (instead of trying to derive conformance requirements from import relationships alone). I think we concluded from ~1 year of discussions that deriving conformance requirements from import statements does not work. /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] I2RS interim 5/27 10:00am - 11:30am EDT (Webex)
On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: > The I2RS interim is schedule for Wednesdsay 5/27 10:00am – 11:30am. The > interim schedule opens 30 minutes early to allow speakers to check their mike > and make sure there slides are ready. > > > > There are two topics on the agenda: > > > > 1) I2RS Protocol requirements with discussion on the following drafts > > a. > https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ (WG > adoption 5/26 to 6/9/2015) > > b. > http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements > (WG adoption 5/26 to 6/9/2015) > I can't make it to this meeting. My suggestion is to merge the above two I-Ds into one I-D. There is already overlap. It also seems that a. goes quite a bit into solution space, so calling it a requirements document may be a bit of a stretch. (But that said, we need to start talking about solutions since we already have a document full of requirements.) /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] VRFY :45: better conformance mechanism
On Tue, May 19, 2015 at 11:59:31AM +0200, Juergen Schoenwaelder wrote: > Hi, > > after long discussions in physical meetings, virtual meetings, and on > the mailing list, I believe we have reached rough consensus to adopt > Y45-04 in order to resolve import ambiguities (aka typedef drift and > grouping drift) and we will leave it to YANG extensions (to be worked > on in the future) to provide means to define explicit conformance > requirements (instead of trying to derive conformance requirements > from import relationships alone). A recent poll of core contributors > on this issue can be found here: > > http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html > > Please speak up by Monday 2015-05-25 if you disagree with this > proposal and your position is not yet included in the email message > pointed to above. > > For more details, see the issues list available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > I have reviewed the final round of discussion and I have not seen additional comments that strengthen the objection raised by Andy. During the discussion, it was observed by Lada that a YANG 1.1 module using multiple imports by revision can be translated into a set of YANG 1.0 submodules (each using import by revision) resulting in same behaviour, namely that different leafs in the module use different versions of a typedef (or expand from different version of a grouping). I have moved Y45 to the EDIT state (adopted solution Y45-04 with rough consensus). /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] Fwd: Re: Leafref and require-instance=false
RFC 6020 section 9.9: The leafref type is used to reference a particular leaf instance in the data tree. The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances. I think the last statement above already clarifies this, no? /js On Mon, Jun 08, 2015 at 02:08:05PM +0200, Balazs Lengyel wrote: >Hello, >I propose a small clarification to the yang draft as described below. >regards Balazs > Forwarded Message > >Subject: Re: Leafref and require-instance=false > Date: Mon, 8 Jun 2015 13:44:55 +0200 > From: Martin Bjorklund [1] > To: [2]balazs.leng...@ericsson.com > > Balazs Lengyel [3] wrote: > > Hello Martin, > > Any thoughts on this? > > regards Balazs > > > > > > Hello Martin, > > If I have a leafref with require-instance=false which references an > > uint8 with range 1..10, and the leafref contains the value 20, can > > this be a valid configuration? > > As I see it, there is nothing in the draft that says this is not > > allowed. > > > > IMHO this should not be valid. You could add something like: > > "The leafref must have a value that is a possible allowed value for > > the referenced leaf." > > I agree, this makes sense! > > > /martin > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: [4]balazs.leng...@ericsson.com > > References > >Visible links >1. mailto:m...@tail-f.com >2. mailto:balazs.leng...@ericsson.com >3. mailto:balazs.leng...@ericsson.com >4. mailto:balazs.leng...@ericsson.com > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Fwd: Re: Leafref and require-instance=false
On Mon, Jun 08, 2015 at 03:22:11PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > RFC 6020 section 9.9: > > > >The leafref type is used to reference a particular leaf instance in > >the data tree. The "path" substatement (Section 9.9.2) selects a set > >of leaf instances, and the leafref value space is the set of values > >of these leaf instances. > > > > I think the last statement above already clarifies this, no? > > I think this is a stricter constraint that addresses the > "require-instance true" case : possible leafref values are limited to > those that instances of the referenced leaf really have. > > 6020bis should IMO say something like this: > > The "path" substatement (Section 9.9.2) selects a set of leaf > instances. If the "require-instance" property (Section 9.9.3) is set to > "true", the leafref value space is the set of values of these leaf > instances. Otherwise, the leafref value MUST be a valid value of the > data type that is defined for the referenced leaf. This makes sense. /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] anydata
On Wed, Jun 10, 2015 at 09:05:07AM +0200, Ladislav Lhotka wrote: > > It is also important for the JSON encoding - it means there won’t necessarily > be a way for mapping XML-encoded instance to JSON and vice versa. > Because of two different namespace identifiers. So here we go. /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] anydata
On Wed, Jun 10, 2015 at 09:56:51AM +0200, Ladislav Lhotka wrote: > > > On 10 Jun 2015, at 09:22, Juergen Schoenwaelder > > wrote: > > > > On Wed, Jun 10, 2015 at 09:05:07AM +0200, Ladislav Lhotka wrote: > >> > >> It is also important for the JSON encoding - it means there won’t > >> necessarily be a way for mapping XML-encoded instance to JSON and vice > >> versa. > >> > > > > Because of two different namespace identifiers. So here we go. > > Yes, three in fact. Blame XML for this. > No, I am not blaming XML. There are only two namespace identifiers; XML uses a URI, you insist that JSON uses a YANG module name. The fact that these _two_ namespace identifiers are different requires to have YANG modules at hand in order to do a conversion between XML encoded YANG instance data and JSON encoded YANG instance data. This is something created by NETMOD (since JSON does not really have namespaces), not something to blame others for. /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] anydata
On Wed, Jun 10, 2015 at 11:26:38AM +0200, Ladislav Lhotka wrote: > > > On 10 Jun 2015, at 11:01, Juergen Schoenwaelder > > wrote: > > > > On Wed, Jun 10, 2015 at 09:56:51AM +0200, Ladislav Lhotka wrote: > >> > >>> On 10 Jun 2015, at 09:22, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Wed, Jun 10, 2015 at 09:05:07AM +0200, Ladislav Lhotka wrote: > >>>> > >>>> It is also important for the JSON encoding - it means there won’t > >>>> necessarily be a way for mapping XML-encoded instance to JSON and vice > >>>> versa. > >>>> > >>> > >>> Because of two different namespace identifiers. So here we go. > >> > >> Yes, three in fact. Blame XML for this. > >> > > > > No, I am not blaming XML. There are only two namespace identifiers; > > XML uses a URI, you insist that JSON uses a YANG module name. The fact > > that these _two_ namespace identifiers are different requires to have > > YANG modules at hand in order to do a conversion between XML encoded > > YANG instance data and JSON encoded YANG instance data. This is > > something created by NETMOD (since JSON does not really have > > namespaces), not something to blame others for. > > From JSON point of view, the module name is an ideal namespace ID because it > is a YANG identifier. Putting URIs to JSON text is a non-starter, and we have > already discussed this. > > The use of URIs as namespace identifiers and URI-prefix duality in XML has > been recognized as a design mistake by XML creators: > > http://blog.jclark.com/2010/01/xml-namespaces.html > There are odd things in XML, there are odd things in JSON, but this is not our scope. We are only responsible for any odd things we create. The decision that the JSON encoding and the XML encoding of YANG instance data uses different namespace identifiers is the responsibility of this WG. /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] anydata
On Wed, Jun 10, 2015 at 03:04:58PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Jun 10, 2015 at 09:05:07AM +0200, Ladislav Lhotka wrote: > > > > > > It is also important for the JSON encoding - it means there won’t > > necessarily be a way for mapping XML-encoded instance to JSON and > > vice versa. > > > > > > > Because of two different namespace identifiers. So here we go. > > There are other reasons as well, e.g., 42 might be encoded > as: > > "foo": 42 > > or > > "foo": "42" > > or > > "foo": [42] > > or > > "foo": ["42"] > > depending on the data model. > > The JSON encoding process needs the data model. Unless the receiver can be expected to do conversion as needed. (I know Lada does not like that, no need to tell me again.) /js PS: Looking at large numbers and small numbers, the receiver may have to be prepared to do some conversion anyway. -- 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] Thursday's interim
Here is the announcement: The NETCONF Data Modeling Language (netmod) Working Group will host a 2- hour interim meeting on Thursday, June 18, 2015 from 1000-1200 EDT (1400-1600 UTC). The agenda will be to split the 2 hours in half, one hour for each of the the opstate and model-structure drafts. I think the two relevant I-Ds are: http://tools.ietf.org/html/draft-openconfig-netmod-opstate-00 https://tools.ietf.org/html/draft-openconfig-netmod-model-structure-00 It seems that the I-Ds mix both a problem statement and solution(s). I think the first step will be to identify what exactly the problem is and to see whether we can find agreement that the problem is worth fixing. If we manage, we can discuss possible solutions as time allows (there might be more than those mentioned in the I-Ds). I will create a Webex for the meeting later and post it to the NETMOD mailing list. /js On Tue, Jun 16, 2015 at 11:10:05AM -0400, Lou Berger wrote: > Tom, Kent, Jurgen, > > The DT is wondering if you are expecting anything from the DT at the > interim or do you just expect to hear from the draft authors? > > Thanks, > Lou > -- 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] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Wed, Jun 17, 2015 at 01:41:56PM +0200, Ladislav Lhotka wrote: > > > Well, but it is exactly what Kent objected against. It is the requirement to > support “old clients” that causes the trouble here (and elsewhere). If client > A sets “inactive” somewhere, then the datastore semantics will change also > for client B that doesn’t understand “inactive” and may be wondering why the > server ignores his edits. > > I understand (although RFC 6241 doesn’t say it explicitly) that, unlike YANG > extensions, a NETCONF capability advertised by the server can be mandatory > for the client in the sense that it has to understand and honour it. There is no way for a client to tell whether a certain capability URI (it has never seen before) is mandatory to understand or not. In fact, I would say in a proper solution it would be the server would have to close the connection if it finds a client that does not understand its language. And yes, we are on very slippery grounds here. If implementors can create arbitrary cool 'annotations' that break clients that do not understand them, we will loose interoperability. > A conclusion of this may be that it makes no sense to define > annotations through YANG extension after all. On the other hand, I > do see a value of having annotations defined in YANG modules. Without further protocol support to negotiate annotations, I think annotations must be limited to things that can be safely ignored by a client. I have not read the I-D yet but I would expect that it should say something like that. ;-) /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] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Wed, Jun 17, 2015 at 02:34:52PM +0200, Ladislav Lhotka wrote: > > > On 17 Jun 2015, at 13:51, Juergen Schoenwaelder > > wrote: > > > > On Wed, Jun 17, 2015 at 01:41:56PM +0200, Ladislav Lhotka wrote: > >> > >> > >> Well, but it is exactly what Kent objected against. It is the requirement > >> to support “old clients” that causes the trouble here (and elsewhere). If > >> client A sets “inactive” somewhere, then the datastore semantics will > >> change also for client B that doesn’t understand “inactive” and may be > >> wondering why the server ignores his edits. > >> > >> I understand (although RFC 6241 doesn’t say it explicitly) that, unlike > >> YANG extensions, a NETCONF capability advertised by the server can be > >> mandatory for the client in the sense that it has to understand and honour > >> it. > > > > There is no way for a client to tell whether a certain capability URI > > (it has never seen before) is mandatory to understand or not. In fact, > > So it means that, e.g. the annotations from > > https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 > > cannot be safely used by the server even after advertising them via > :conditional-enablement capability. Yes, advertisement is not sufficient. > > Without further protocol support to negotiate annotations, I think > > annotations must be limited to things that can be safely ignored by a > > client. I have not read the I-D yet but I would expect that it should > > say something like that. ;-) > > But it’s not a specific problem of this draft, it would simply mean that > annotations that cannot be ignored cannot be used at all, no matter what. > However, some annotations that have been proposed (and probably used in the > wild) are of that sort. > They cannot be used safely until there is an annotation negotiation mechanism, or as Martin indicated, a way for a client to explicitely enable the functionality associated with certain annotations. /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] follow-up from virtual interim and i2rs discussions
On Tue, Jun 23, 2015 at 12:17:15AM +, Kent Watsen wrote: > > [As an individual contributor] > > Attached are some slides that I put together, with feedback from > Andy and Martin, that attempt to capture a high-level model we can > all agree on. Comments, questions, concerns? I am lost on slide #3. Operational state reflects what the device actually does, I am not sure what 'actualized config' really is. I am also lost on slide #3 and #4 concerning what protocol discovered values (slide #4) are and when they differ from the middle box on slide #3. The difference between counters and statistics is unclear as well. RFC 3535 only distinguished config, operational state, statistics. Why is it hard to provide generic access to counters? Processing the data model easily gives you the query to retrieve all counters (but I am not sure this is operationally a good thing to do anyway; is blindly polling counters really how networks are managed?). What is important I think is that data has different life times. You can have config that is provisioned for interfaces not yet present, you can have an interface operationally active that is not configured. The model in RFC 7223 supports both. Can someone explain using concrete examples what the RFC 7223 model is not supporting well or are we searching for terms to describe what the RFC 7223 model all got right? /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] follow-up from virtual interim and i2rs discussions
On Tue, Jun 23, 2015 at 01:14:40AM -0400, Phil Shafer wrote: [...] > If I were picked terms, I think I'd go something like: > > base config + ephemeral data + defaults => intended state I like intended state way more than intended config. I would change the other two slightly: provisioned config + ephemeral config => intended state > intended state + learned values => actual state In reality it is more like this: intended state + learned values + device properties => actual state In other words, even if you know the intended state and the learned values, you most likely won't be able to predict the actual state precisely without knowing device specific properties. But we likely ignore that nasty part of reality... > actual state + counters => operational state This should be: actual state + statistics => operational state Statistics is largely dominated by counters but not only counters. /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] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: > > This is a notice to start a NETMOD WG last call for the document "JSON > Encoding of Data Modeled with YANG": > > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > > Please indicate your support by Monday June 29, 2015 at 9PM EST. Hi, I have reviewed draft-ietf-netmod-yang-json-04. - I am not sure I agree with the wording in section 3. Why is section 8.3.3 only applicable to XML encoded data? Validation applies to datastores. While constraints are defined using XML-based notations such as XPATH, how the validation is carried out is not defined in the YANG specifications. I guess I actually disagree with the wording in section 3 of the JSON encoding I-D. - It is unclear whether the 'if and only if' on page 4 means that an implementation that generates namespace prefixes that are not strictly needed is violating this I-D. I see the need for a MUST to include the module name if the parent node belongs to a different module. I am not sure why it is necessary to mandate minimal encodings (if that is the idea here). Whatever the answer is, it would be good to use RFC 2119 language. - The reason for the requirement that list keys are encoded first in RFC 6020 is to make it easier to process data in a stream-oriented fashion. If keys can appear anywhere, they might appear at the very end and thus buffering is required in order to process data properly. Is this concern not relevant for the JSON encoding? Perhaps this is not relevant, but then we might also state this explicitly: As a consequence, implementations must be cable to buffer JSON encoded instances in order to locate keys that may appear at the end of a JSON encoded instance. - I think that section 5.5 should say: If the data model for the data in an anydata instance is known, then the data must be encoded following the rules defined in this I-D. In other words, it is not arbitrary JSON with a few constraints but something that matches the JSON encoding rules once the data model is known. - Section 6, I suggest s/mapped/encoded/. - I do not understand 'An "enumeration" value is mapped in the same way as a string except that permitted values are defined by enum statements in YANG.' Perhaps this is simpler: An "enumeration" value is encoded as a JSON string. The allowed string values are the enumeration names assigned by the enum statement in YANG. The representation is identifical to the XML encoding, see sec. 9.6 in [RFC6020bis]. I specifically tried to avoid 'value' in order to avoid confusion with the value YANG statement. - Perhaps remove the reference to XML in section 6.5 from the definition of the encoding rules so that the JSON encoding rules are not tied into the XML encoding rules. It is OK to mention that it is the same. A "bits" value is encoded as a JSON string. Multiple bit names assigned by the bit statement in YANG are encoded as a space-separated string of bit names representing the individual bits that are set. The representation is identifical to the XML encoding, see sec. 9.7 in [RFC6020bis]. - Same as before for section 6.6: A "binary" value is encoded by first encoding the binary value in base64 and encoding the resulting base64-encoded value as a JSON string. The representation is identifical to the XML encoding, see sec. 9.8 in [RFC6020bis]. - I am not sure I understand the argument why [null] is better than null for the empty type. Perhaps it is but the text does not really tell me. - I suggest to remove the reference to 9.13.3 in the definition. In fact, the representation is pretty different since XML uses namespace prefixes while JSON uses module names. (I must admit that I find the JSON representation more readable since it does not require XML namespace context.) - Section 7: So what happens in the rare case of a binary value appearing in a RESTCONF URI? Is the resulting BASE64 value than simply subject to URI escaping rules? I assume this 'rare event' would happen if a list is indexed by a leaf of type binary, no? Are there any other cases? /js PS: Should RFC 6020bis change the section titles "XML Mapping Rules" to "XML Encoding Rules"? I think we really talk about 'encoding', not about 'mapping' and if we agree on this, we should try to be consistent with the terms we use. -- 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] Follow up on the openconfig oper status and the NETMOD interim
On Wed, Jun 24, 2015 at 06:39:44PM +0100, Rob Shakir wrote: > A portion of the operational state date (marked operational: true) > is the set of variables that are not related to state that an > external system can assert the value of — for example, a counter, or > a negotiated protocol timer. Not sure I parse this correctly but it sounds a bit like you make something a static data model property that in reality is a dynamic property of state. Lets take as an example the IP address of an interface. It can be statically configured or it can bee optained dynamically via DHCP. So would you mark this operational true (or operational sometimes) in the data model? /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] Follow up on the openconfig oper status and the NETMOD interim
Anees, does it really make sense to have to track multiple different objects in order to find out which IP address(es) are used by an interface? Perhaps I am old school but I do like the existing design better - one place to find the operationally used state. I rather have additional _metadata_ about where the values are originating from instead of a static marker in a data model that requires to report state in multiple places that than needs to be integrated again to answer simple questions like which IP addresses are used by an interface. Knowing the origin of operational state data is highly useful. Trying to encode that in the design and structure of the data model, however, seems complex, costly, and inefficient. /js On Wed, Jun 24, 2015 at 06:22:28PM -0700, Anees Shaikh wrote: > So the model probably would have this as a choice, right? In one case I > set the mode as STATIC and specify the address (intended and actual config > leaves, marked config: true, and config: false, respectively), and in the > other case I set the interface to DHCP (again intended and actual config), > and the received IP address would be set in an operational state variable > (e.g., dhcp-assigned-address). This last leaf would be marked as > operational:true in our proposal. > > thanks. > -- Anees > > On Wed, Jun 24, 2015 at 4:19 PM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > On Wed, Jun 24, 2015 at 06:39:44PM +0100, Rob Shakir wrote: > > > > > A portion of the operational state date (marked operational: true) > > > is the set of variables that are not related to state that an > > > external system can assert the value of — for example, a counter, or > > > a negotiated protocol timer. > > > > Not sure I parse this correctly but it sounds a bit like you make > > something a static data model property that in reality is a dynamic > > property of state. Lets take as an example the IP address of an > > interface. It can be statically configured or it can bee optained > > dynamically via DHCP. So would you mark this operational true (or > > operational sometimes) in the data model? > > > > /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 > > -- 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] Follow up on the openconfig oper status and the NETMOD interim
On Thu, Jun 25, 2015 at 12:29:13AM -0700, Anees Shaikh wrote: > hi Juergen, > > I don't believe it involves tracking anything beyond what you would need to > track however the model is structured. You would want to know when your > static IP is applied and being used, or you would want to know what IP > address was assigned by the DHCP server. Our approach collects this > information in one consistent place (in terms of paths) independent of how > one wants to compose the models. I guess don't understand what you mean > by it requires reporting and integrating state data from multiple places. > > I really don't see where the extra complexity and cost you mention is > coming from. Is the addition of some nodes in the data model so costly? > For whom? A model writer? I think the design pattern for writing models > in this way actually is pretty straightforward (having written several > reasonably complex models now). For a human model reader? Perhaps the > disconnect is that our perspective is coming from trying to build > operational software systems that consume the models without having to > write unnecessary model-specific code that just propagates more complexity > into the NMS. The problem with your approach is that you are assigning semantics to where information is located in the data model. You can only do this once. While have N different locations where IP addresses are listed might answer one operationally relevant question, it makes other opertionally relevant questions harder. If you continue with your approach, you will start replicating data multiple times to address different operationally relevant question. And this simply does not scale, clearly not with standards in mind. I like to understand: - what are the additional semantics in the data model (e.g., machine readable information that helps to understand static model relationships) - what is the meta data you like to have and that you might want to filter on in order to retrieve data in meaningful ways I am having a hard time to believe that encoding semantics in the naming structure is a proper and workable solution. /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] extended datastores slide
On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierman wrote: > > I prepared 1 slide (based on Kent's slide). > I am trying to understand the types of data > and how they are identified in YANG and conceptually > separated for protocol access. > I do not understand the 'config ephemeral' on the left side. I think it is the implementation (or its configuration) that decides which data models also exist in the ephemeral data store. /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] [i2rs] extended datastores slide
On Thu, Jun 25, 2015 at 01:02:28PM -0400, Susan Hares wrote: > Juergen: > > Where would you put the "config ephemeral"? > Perhaps this is not needed. /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] Action from Today's Interim Meeting
On Thu, Jun 25, 2015 at 12:51:49PM -0400, Nadeau Thomas wrote: > > First, can the folks that presented slides today (Acee and Anees) > please send their slides to the list here. Preferred mode is a URL to a place > where the slides exist so we don’t fill everyones’ boxes with PPTs. 8) Preferred place is the IETF meetings material manager. Simply send the slides to me and I will upload them. /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] Action from Today's Interim Meeting
On Thu, Jun 25, 2015 at 07:10:46PM +, Acee Lindem (acee) wrote: > Hi Juergen, > I’m attaching the Model Structure slides for upload. Thanks, uploaded: https://www.ietf.org/proceedings/interim/2015/06/25/netmod/slides/slides-interim-2015-netmod-14-0.pdf /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] Action from Today's Interim Meeting
On Thu, Jun 25, 2015 at 03:09:31PM -0700, Anees Shaikh wrote: > Here are the opstate slides -- thanks Juergen. > Thanks. Uploaded to the archive: https://www.ietf.org/proceedings/interim/2015/06/25/netmod/slides/slides-interim-2015-netmod-14-1.pdf /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] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Mon, Jun 15, 2015 at 10:49:32PM +, Kent Watsen wrote: > > This is a notice to start a NETMOD WG last call for the document "Defining > and Using Metadata with YANG": > > https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01 > > Please indicate your support by Monday June 29, 2015 at 9PM EST. Hi, I have reviewed draft-ietf-netmod-yang-metadata-01 and I have a couple of comments. - I would prefer if the terminology would be streamlined. Currently, the I-D sometimes uses "metadata", sometimes "annotation", sometimes "metadata annotation". If these terms all mean the same, then I suggest we settle on a single term. Furthermore, the YANG statement 'annotation' is defined in the module 'ietf-metadata'. I am not sure whether there is a specific reasoning behind this. - In order to group YANG modules together that define YANG extensions and nothing else, does it make sense to call them 'ietf-yang-'? - I am having problems with the examples presented in the Introduction. The 'deactivating a subtree' annotation requires a negotiation mechanism to be robust. The usage of attributes in the is more a protocol specification detail. Do you suggest that annotations would be used to define them? If so, how? I think there needs to be text in section 1 that distinsuishes between annotations that are harmless (because they can be ignored) and annotations that require annotation negotiation in order to be used. - Why is the type statement optional for annotations? This seems to be inconsistent with the YANG rules. - The definition of 'inactive' on page 6 is kind of confusing. The text says the presence of the annotation deactives a data node. If so, why is the type of the annotation a boolean? - The text about advertisements is not clear. I think a server advertising annotation A not only commits to comply to this I-D but also to the semantics of the annotations A. I note that there is no mechanism to scope annotations - a server either support annotations for all data models it implements or none. Is this correct? Furthermore, if a module M defines annotation A and it contains also other definitions, then I can't implement M without implementing A system wide? That is, it is advisable to define annotations in their own separate modules in order to preserve flexibility, no? - Does the presence of an annotation impact the JSON encoding rules that control when a module name prefix is needed or not? I assume the answer is 'no' but it is not clear from the text. - s/whose the/whose/ - bump the copyright year to 2015 /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] Y35: allow empty in union
On Wed, Jun 24, 2015 at 12:16:55PM +0200, Martin Bjorklund wrote:
> Hi,
>
> Currently we have an inconsistency in
> draft-ietf-netmod-rfc6020bis-05. With Y35, we allow type empty in
> unions. But section 7.8.2 says:
>
>A leaf that is part of the key can be of any built-in or derived
>type, except it MUST NOT be the built-in type "empty".
>
> This means that this is legal:
>
> typedef my-empty {
> type union {
> type empty;
> }
> }
>
> list foo {
> key id;
> leaf id {
> type my-empty;
> }
> ...
> }
>
> I suggest we allow type empty also in keys:
>
> NEW:
>
>A leaf that is part of the key can be of any built-in or derived
>type.
And my understanding is that the list foo defined above will never
have an instance, correct? I assume decent compilers will continue to
create warnings when they can decide that a list will never have any
instances. (And yes, there are other ways to construct such lists, so
I am OK with removing a constraint preventing a specific case of such
useless lists.)
/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] Y35: allow empty in union
On Sun, Jun 28, 2015 at 05:11:28PM +0200, Martin Bjorklund wrote:
> Andy Bierman wrote:
> > On Sun, Jun 28, 2015 at 7:16 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Wed, Jun 24, 2015 at 12:16:55PM +0200, Martin Bjorklund wrote:
> > > > Hi,
> > > >
> > > > Currently we have an inconsistency in
> > > > draft-ietf-netmod-rfc6020bis-05. With Y35, we allow type empty in
> > > > unions. But section 7.8.2 says:
> > > >
> > > >A leaf that is part of the key can be of any built-in or derived
> > > >type, except it MUST NOT be the built-in type "empty".
> > > >
> > > > This means that this is legal:
> > > >
> > > > typedef my-empty {
> > > > type union {
> > > > type empty;
> > > > }
> > > > }
> > > >
> > > > list foo {
> > > > key id;
> > > > leaf id {
> > > > type my-empty;
> > > > }
> > > > ...
> > > > }
> > > >
> > > > I suggest we allow type empty also in keys:
> > > >
> > > > NEW:
> > > >
> > > >A leaf that is part of the key can be of any built-in or derived
> > > >type.
> > >
> > > And my understanding is that the list foo defined above will never
> > > have an instance, correct? I assume decent compilers will continue to
> > > create warnings when they can decide that a list will never have any
> > > instances. (And yes, there are other ways to construct such lists, so
> > > I am OK with removing a constraint preventing a specific case of such
> > > useless lists.)
> > >
> > >
> > I think the list can have 1 instance.
>
> Yes.
>
OK. I guess RFC 6020 section 9.11.2. confused me. Is the lexical
representation not simply an empty string? I mean, it seems that
would be as valid as
or am I confused? And in JSON it would be this?
"foo": [
{
"id": [null]
}
]
/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
...
> import t {
> prefix t; // note: no revision-date
> }
> ...
> }
>
> module b {
> ...
> import t {
> prefix t;
> revision-date 2015-01-01;
> }
> ...
> }
>
> module c {
> ...
> import t {
> prefix t;
> revision-date 2015-02-02;
> }
> ...
> }
>
> module t {
> ...
> revision 2015-02-02;
> revision 2015-01-01;
> ...
> }
>
> Now the server lists in ietf-yang-library:
>
> modules:
> module:
> name: t
> revision: 2015-01-01;
> conformance: false
> module:
> name: t
> revision: 2015-02-02;
> conformance: false
>...
>
> A client downloads all modules from the server. Now, how can the
> client tell which revsion of "t" was used to implement "a"?
>
> I can se two solutions:
>
> 1. Just list one revision of "t" - the one used to implement module
> "a" (and any other module that imports "t" w/o revision).
>
> There really is no reason to list the other revsion of "t".
>
> 2. List both revisions of "t", but mark the one that is used to
> implement module "a" in some way.
Note that you can have two modules importing t without a revision and
the two modules may use different versions of t. If so, then it seems
the indexing we have is right since you may need to list multiple
revisions of t. If the requirement is to announce which version of t
has been used by module a, then it seems you need to kind of list the
imports with the revisions actually used in the data model, no?
> > > > This module should not care how many revisions of each module
> > > > are listed. This is the full YANG library, not a message.
> > >
> > > The whole point of this module is to replace the message! It
> > > first came up in RESTCONF, and we want to use it also in NETCONF in
> > > order to have one single way to do YANG module advertisement
> > > regardless of protocol.
> > >
> > > There is already the schema list in ietf-netconf-monitoring that gives
> > > you the full set of modules and submodules used in a server.
> > >
> > >
> >
> > We already discussed relation to the schema list and decided to ignore it.
> > The whole point of this library is to provide the full list of YANG modules
> > and submodules on the device.
> >
> > I strongly object to changing this module.
> > IMO it is quite clear how to fill in the list of modules.
>
> Yes it is clear. I argue that it the information is provides is not
> sufficient to solve the advertisement problem.
/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] Y35: allow empty in union
On Mon, Jun 29, 2015 at 05:40:22PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >And my understanding is that the list foo defined above will never > >have an instance, correct? I assume decent compilers will continue to > >create warnings when they can decide that a list will never have any > >instances. (And yes, there are other ways to construct such lists, so > >I am OK with removing a constraint preventing a specific case of such > >useless lists.) > > Doesn't removing the prohibition require us to accept such nonsense? > I am not afraid of nonsense in data models since nonsense will not be implemented. I would leave it to compiler writers to warn about nonsense constructions a compiler can detect without requiring a statement in the language definition trying to prohibit nonsense. There are many ways to define degenerated lists in YANG; ruling out one of them does not help that much and it creates inconsistencies - why is one way to define a degenerated list forbidden but the others are legal? /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] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Mon, Jun 29, 2015 at 03:22:55PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Jun 15, 2015 at 10:49:32PM +, Kent Watsen wrote: > >> > >> This is a notice to start a NETMOD WG last call for the document "Defining > >> and Using Metadata with YANG": > >> > >> https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01 > >> > >> Please indicate your support by Monday June 29, 2015 at 9PM EST. > > > > Hi, > > > > I have reviewed draft-ietf-netmod-yang-metadata-01 and I have a couple > > of comments. > > Thanks, my replies are inline. > > > > > - I would prefer if the terminology would be streamlined. Currently, > > the I-D sometimes uses "metadata", sometimes "annotation", sometimes > > "metadata annotation". If these terms all mean the same, then I > > suggest we settle on a single term. Furthermore, the YANG statement > > 'annotation' is defined in the module 'ietf-metadata'. I am not sure > > whether there is a specific reasoning behind this. > > In my interpretation, metadata is a more general term, i.e. metadata of an > instance document may consist of multiple (different) annotations. This is one possible explanation. I am fine if this is spelled out clearly so that readers understand how the words are used. > That said, it should be possible to get rid of the "metadata" term, and > change the module name e.g. to "ietf-annotation-extension" > > > > > - In order to group YANG modules together that define YANG extensions > > and nothing else, does it make sense to call them 'ietf-yang-'? > > Such a convention, if it is agreed upon, IMO belongs to 6087bis. Moreover, > ietf-yang-types > doesn't fit this pattern. Yes, not an extension in the strict sense but still a rather standard extension of basic types. I would find ietf-yang-* nice to list all "basic" yang modules but then I am not religious about it either (ietf-yang-annotation would be a concrete proposal). > >is more a protocol specification detail. Do you > > suggest that annotations would be used to define them? If so, how? > > I haven't thought about this particular use, although it probably won't > be any worse than "get-filter-element-attributes" extension in the > "ietf-netconf" module. Again, I prefer to pick a less controversial example. One can of course debate whether 'type' and 'select' (this is what get-filter-element-attributes defines) are generic annotations. I would not think so. > > I think there needs to be text in section 1 that distinsuishes > > between annotations that are harmless (because they can be ignored) > > and annotations that require annotation negotiation in order to be > > used. > > I am not sure there is a good and absolute definition of "harmless", it > depends on the context. For example, if DSDL mapping ignores the > extension, then no instance document containing *any* XML attributes (no > matter how benign) can ever be successfully validated with the generated > RELAX NG schema. > > I agree it is a problem but IMO it comes down to the (wrong) assumption > that a client is free to cherry-pick arbitrary parts of the data model > advertised by the server, without even telling the server which parts were > chosen/omitted. I do not understand the last paragraph. Anyway, for me, the fact that it is difficult to define "harmless" seems to underpin the need for discussion. It is not even clear to me whether a generic NETCONF client is required to preserve any attributes it receives. For annotations that are purely maintained by the NC server (e.g. the timestamp of the last modification), this is not an issue. For anything that is client provided, this is not at all clear and if an annotation changes server behaviour or the interpretation of the data, this clearly requires some sort of agreement that both endpoints know what they are doing. > > Furthermore, if a module M defines annotation A and it contains also > > other definitions, then I can't implement M without implementing A > > system wide? That is, it is advisable to define annotations in their > > own separate modules in order to preserve flexibility, no? > > Not sure, it depends on what this text in 6020(bis) really means: > >If a YANG compiler does not support a particular extension, which >appears in a YANG module as an unknown-statement (see Section 13), >the entire unknown-statement MAY be ignored by the compiler. > > I would assume that ser
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > Hi Juergen, > > thank you for the review. > > Juergen Schoenwaelder writes: > > > On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: > >> > >> This is a notice to start a NETMOD WG last call for the document "JSON > >> Encoding of Data Modeled with YANG": > >> > >> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >> > >> Please indicate your support by Monday June 29, 2015 at 9PM EST. > > > > Hi, > > > > I have reviewed draft-ietf-netmod-yang-json-04. > > > > - I am not sure I agree with the wording in section 3. Why is section > > 8.3.3 only applicable to XML encoded data? Validation applies to > > datastores. While constraints are defined using XML-based notations > > You are right that this section shouldn't talk about XML-encoded data, > i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath > operates on the abstract, logical structure of an XML document, …". > > So I think a datastore needs to be represented, at least conceptually, > as XML infoset. > > > such as XPATH, how the validation is carried out is not defined in > > the YANG specifications. I guess I actually disagree with the > > I don't think this is true. YANG spec doesn't say how "must" and "when" > statements are evaluated, and relies on XPath. RFC 6020: When a datastore is validated, all "must" constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated. [...] Also note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator on the device. How the evaluation is done in practice is an implementation decision. > > wording in section 3 of the JSON encoding I-D. > > What specifically? Do you have any suggestions for changes? The problem is that RFC 6020 talks about datastore validation, not about validation of a specific serialization. Hence, it does not matter whether the data was XML or JSON (or CBOR or whatnext) encoded - once the data is in the datastore, datastore validation takes place. One way to implement this is to serialize everything to XML and then to use XML gear to do the validation. But this implementation strategy is not required. > > - It is unclear whether the 'if and only if' on page 4 means that an > > implementation that generates namespace prefixes that are not > > strictly needed is violating this I-D. I see the need for a MUST to > > Yes, that's the intention. Why is it unclear? > > > include the module name if the parent node belongs to a different > > module. I am not sure why it is necessary to mandate minimal > > encodings (if that is the idea here). Whatever the answer is, it > > would be good to use RFC 2119 language. > > Revision -02 used 2119 terms but there were objections against it: > > https://mailarchive.ietf.org/arch/msg/netmod/xXS0uSKKu83qBQVCJ_CYmdsavUc > > In fact, YANG spec also states syntax rules without using 2119 keywords, > for example "Each identifier starts with an uppercase or lowercase ASCII > letter or an underscore character, …", it doesn't say that it MUST NOT > start with anything else. If the goal is to define a strict implementation requirement, then I think using RFC 2119 language is the preferred choice in the IETF. I think the debate back then was whether it is reasonable to declare an implementation that fails to produce minimal encodings as violating the spec. How does it break a receiver if I send a redundant module name? Your change of the MUST to 'if and only if' did cosmetics but it did not address the concern raised. > > - The reason for the requirement that list keys are encoded first in > > RFC 6020 is to make it easier to process data in a stream-oriented > > fashion. If keys can appear anywhere, they might appear at the very > > end and thus buffering is required in order to process data > > properly. Is this concern not relevant for the JSON encoding? > > This cannot be required as long as our aim is interoperability of > implementations based on off-the-shelf JSON parsers, hence I_JSON. RFC > 7493 states it clearly: "The order of object members in an I-JSON > message does not change the meaning of an I-JSON message." > > > Perhaps this is not relevant, b
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Tue, Jun 30, 2015 at 01:44:11PM +0200, Ladislav Lhotka wrote: > >> > - Does the presence of an annotation impact the JSON encoding rules > >> > that control when a module name prefix is needed or not? I assume > >> > the answer is 'no' but it is not clear from the text. > >> > >> Bullet #1 in sec. 4.2 says this. > > > > I did not find the two bullets clear enough. The second bullet says: > > > >2. Namespaces of metadata annotations are encoded in the same way as > >namespaces of YANG data node instances, see > >[I-D.ietf-netmod-yang-json]. > > > > This leaves it up for interpretation whether this means just the > > syntax or whether this also refers to the rules when namespaces must > > be included. The first bullet did not help me to understand this > > For annotations in JSON, the namespace ID (module name) must always be > included in their name, and annotations are essentially leaves so they > cannot participate in any "namespace switching". And bullet #1 says > encoding of other nodes is unaffected by the presence of annotations. > > > either, hence I asked the question. I love to have more explicit text, > > perhaps even an example (if I have two annotations 'a' and 'b' defined > > in one module and another annotation 'c' defined in a second module > > together with a leaf 'd', what are the possible namespace combinations > > I will get if I reorder the annotations?). > > I don't understand. Do you mean reordering within a single "metadata object"? > The order of its members is irrelevant, and all members must have an > explicit namespace. OK. /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
Writing as technical contributor...
On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
> Hi,
>
> Here's a short summary, and then some questions for the WG.
>
> The ietf-yang-library module is designed to serve two purposes:
>
> 1. A protocol-independent advertisement mechanism for YANG 1.1
> modules.
>
> 2. A list of the YANG modules stored in a server.
>
>
> Q1. Do you agree with these goals?
I primarily care about goal 1.
> Q2. Should this module be designed to work with both YANG 1.0 and
> YANG 1.1 servers - i.e., should it have yang-version 1.1 or not?
>
> If it should not be defined using YANG 1.1, why is this module
> special?
I assume this module will sooner or later be YANG 1.1 anyway.
> Q3. Should the /modules/module list be designed to store both YANG
> 1.0 and YANG 1.1 modules?
Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.
> Q4. Consider these modules, which both import foo without revision:
>
>module a { ... import foo; ... }
>module b { ... import foo; ... }
>
> Do we require a server that implements both a and b to use the
> same revision of foo?
>
> If the answer is yes, we need to indicate the default revision
> that the server uses in the model:
>
>container modules {
> ...
> list module {
>...
>leaf default-revision {
> type boolean;
> default false;
> description
>"Indicates that this revision is used by the server if
> this module is imported without a specific revision
> date.";
>}
> }
>}
>
> If the answer is no, note that this puts an implementation burden
> on the client. A client cannot simply download all listed
> modules, and load/compile/process them as one set.
>
> If the anwser is no, I propose that we extend the module as such:
>
>container modules {
> ...
> list module {
>...
>list imported-without-revision {
> key "name revision";
> ...
>}
> }
>}
>
> A server could then list:
>
>
> a
> 2015-01-01
>
> foo
> 2002-02-02
>
>
>
> b
> 2015-01-01
>
> foo
> 2001-01-01
>
>
I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.
/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] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > >> Hi Juergen, > >> > >> thank you for the review. > >> > >> Juergen Schoenwaelder writes: > >> > >> > On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: > >> >> > >> >> This is a notice to start a NETMOD WG last call for the document "JSON > >> >> Encoding of Data Modeled with YANG": > >> >> > >> >> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >> >> > >> >> Please indicate your support by Monday June 29, 2015 at 9PM EST. > >> > > >> > Hi, > >> > > >> > I have reviewed draft-ietf-netmod-yang-json-04. > >> > > >> > - I am not sure I agree with the wording in section 3. Why is section > >> > 8.3.3 only applicable to XML encoded data? Validation applies to > >> > datastores. While constraints are defined using XML-based notations > >> > >> You are right that this section shouldn't talk about XML-encoded data, > >> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath > >> operates on the abstract, logical structure of an XML document, …". > >> > >> So I think a datastore needs to be represented, at least conceptually, > >> as XML infoset. > >> > >> > such as XPATH, how the validation is carried out is not defined in > >> > the YANG specifications. I guess I actually disagree with the > >> > >> I don't think this is true. YANG spec doesn't say how "must" and "when" > >> statements are evaluated, and relies on XPath. > > > > RFC 6020: > > > >When a datastore is validated, all "must" constraints are > >conceptually evaluated once for each data node in the data tree, and > >for all leafs with default values in use (see Section 7.6.1). If a > >data node does not exist in the data tree, and it does not have a > >default value, its "must" statements are not evaluated. > > > >[...] > > > >Also note that the XPath expression is conceptually evaluated. This > >means that an implementation does not have to use an XPath evaluator > >on the device. How the evaluation is done in practice is an > >implementation decision. > > Yes, but the result must be guaranteed to be the same as if an XPath 1.0 > processor is used, otherwise it makes really no sense. > > > > >> > wording in section 3 of the JSON encoding I-D. > >> > >> What specifically? Do you have any suggestions for changes? > > > > The problem is that RFC 6020 talks about datastore validation, not > > about validation of a specific serialization. Hence, it does not > > matter whether the data was XML or JSON (or CBOR or whatnext) encoded > > - once the data is in the datastore, datastore validation takes > > place. One way to implement this is to serialize everything to XML and > > then to use XML gear to do the validation. But this implementation > > strategy is not required. > > We have no explicit concept of a metamodel for datastores but IMO the > fact that we evaluate XPath expressions on top of it implies that the > datastore must be (congruent to) restricted XML infoset. Section 5 (Data > Model) is a crucial part of XPath spec, and it is XML. The YANG language does not require that XPath is used. It says that XPath is conceptually evaluated. Should the text in an encoding document not be consistent with that? > > > >> > - It is unclear whether the 'if and only if' on page 4 means that an > >> > implementation that generates namespace prefixes that are not > >> > strictly needed is violating this I-D. I see the need for a MUST to > >> > >> Yes, that's the intention. Why is it unclear? > >> > >> > include the module name if the parent node belongs to a different > >> > module. I am not sure why it is necessary to mandate minimal > >> > encodings (if that is the idea here). Whatever the answer is, it > >> > would be good to use RFC 2119 language. > >> > >> Revision -02 used 2119 terms but there were objections against it: > >> > >> https://mailarchive.ietf.org/arch/msg/netmod/xXS0uSKKu83qBQVCJ_CYmdsavUc > >> > >>
Re: [netmod] Y35: allow empty in union
On Tue, Jun 30, 2015 at 10:00:11AM -0400, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >I am not afraid of nonsense in data models since nonsense will not be
> >implemented. I would leave it to compiler writers to warn about
> >nonsense constructions a compiler can detect without requiring a
> >statement in the language definition trying to prohibit nonsense.
> >There are many ways to define degenerated lists in YANG; ruling out
> >one of them does not help that much and it creates inconsistencies -
> >why is one way to define a degenerated list forbidden but the others
> >are legal?
>
> This really isn't the way standards work, right? "gcc" can warn when
> I do something like "int foo(){ return 0; return 1;}" but it can't
> decide that it's invalid or refuse to generate a .o file for it.
> I can choose to tighten gcc's restrictions with -W flags, but when
> code compiles under gcc and doesn't under clang, when one or the
> other isn't implementing the C standard.
I don't get it. I do not think the C standard says the example above
is invalid C. It is perhaps pointless C or likely a coding error but
as long as the semantics are clear, things are well defined.
> Past that, allowing pointless constructs like this allows users
> to make mistakes that might not be warned by their tool chain,
> and the earlier an error is caught, the lower it's cost.
>
> Worse, allowing pointless constructs like this means that the
> probability of some nitwit using it quickly approaches 1, at
> which point tool chains that barf on it will need to start
> supporting it.
You can achieve the same pointless construct in many other ways.
Trying to enumerate all of them is tricky and it is very easy to make
mistakes.
> I'm not asking us to make pointless constructs like "leaf foo {must foo==0;}"
> but empty keys it truly pointless. Making it illegal is a benefit
> to the enitre YANG world and not doing so it a pointless expense.
I guess it is subjective where to draw the line. Disallowing empty in
a key but at the same time allowing the example Martin presented shows
that the line is really somewhat arbitrary.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: > > > On 30 Jun 2015, at 15:39, Juergen Schoenwaelder > > wrote: > > > > On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: > >> > >>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > >>>> Juergen Schoenwaelder writes: > >>>> > >>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > >>>>>> Hi Juergen, > >>>>>> > >>>>>> thank you for the review. > >>>>>> > >>>>>> Juergen Schoenwaelder writes: > >>>>>> > >>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: > >>>>>>>> > >>>>>>>> This is a notice to start a NETMOD WG last call for the document > >>>>>>>> "JSON Encoding of Data Modeled with YANG": > >>>>>>>> > >>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >>>>>>>> > >>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM EST. > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. > >>>>>>> > >>>>>>> - I am not sure I agree with the wording in section 3. Why is section > >>>>>>> 8.3.3 only applicable to XML encoded data? Validation applies to > >>>>>>> datastores. While constraints are defined using XML-based notations > >>>>>> > >>>>>> You are right that this section shouldn't talk about XML-encoded data, > >>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath > >>>>>> operates on the abstract, logical structure of an XML document, …". > >>>>>> > >>>>>> So I think a datastore needs to be represented, at least conceptually, > >>>>>> as XML infoset. > >>>>>> > >>>>>>> such as XPATH, how the validation is carried out is not defined in > >>>>>>> the YANG specifications. I guess I actually disagree with the > >>>>>> > >>>>>> I don't think this is true. YANG spec doesn't say how "must" and "when" > >>>>>> statements are evaluated, and relies on XPath. > >>>>> > >>>>> RFC 6020: > >>>>> > >>>>> When a datastore is validated, all "must" constraints are > >>>>> conceptually evaluated once for each data node in the data tree, and > >>>>> for all leafs with default values in use (see Section 7.6.1). If a > >>>>> data node does not exist in the data tree, and it does not have a > >>>>> default value, its "must" statements are not evaluated. > >>>>> > >>>>> [...] > >>>>> > >>>>> Also note that the XPath expression is conceptually evaluated. This > >>>>> means that an implementation does not have to use an XPath evaluator > >>>>> on the device. How the evaluation is done in practice is an > >>>>> implementation decision. > >>>> > >>>> Yes, but the result must be guaranteed to be the same as if an XPath 1.0 > >>>> processor is used, otherwise it makes really no sense. > >>>> > >>>>> > >>>>>>> wording in section 3 of the JSON encoding I-D. > >>>>>> > >>>>>> What specifically? Do you have any suggestions for changes? > >>>>> > >>>>> The problem is that RFC 6020 talks about datastore validation, not > >>>>> about validation of a specific serialization. Hence, it does not > >>>>> matter whether the data was XML or JSON (or CBOR or whatnext) encoded > >>>>> - once the data is in the datastore, datastore validation takes > >>>>> place. One way to implement this is to serialize everything to XML and > >>>>> then to use XML gear to do the validation. But this implementation &g
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: > >> > >> > On 30 Jun 2015, at 15:39, Juergen Schoenwaelder > >> > wrote: > >> > > >> > On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: > >> >> > >> >>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder > >> >>> wrote: > >> >>> > >> >>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > >> >>>> Juergen Schoenwaelder writes: > >> >>>> > >> >>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > >> >>>>>> Hi Juergen, > >> >>>>>> > >> >>>>>> thank you for the review. > >> >>>>>> > >> >>>>>> Juergen Schoenwaelder writes: > >> >>>>>> > >> >>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: > >> >>>>>>>> > >> >>>>>>>> This is a notice to start a NETMOD WG last call for the document > >> >>>>>>>> "JSON Encoding of Data Modeled with YANG": > >> >>>>>>>> > >> >>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >> >>>>>>>> > >> >>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM EST. > >> >>>>>>> > >> >>>>>>> Hi, > >> >>>>>>> > >> >>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. > >> >>>>>>> > >> >>>>>>> - I am not sure I agree with the wording in section 3. Why is > >> >>>>>>> section > >> >>>>>>> 8.3.3 only applicable to XML encoded data? Validation applies to > >> >>>>>>> datastores. While constraints are defined using XML-based notations > >> >>>>>> > >> >>>>>> You are right that this section shouldn't talk about XML-encoded > >> >>>>>> data, > >> >>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath > >> >>>>>> operates on the abstract, logical structure of an XML document, …". > >> >>>>>> > >> >>>>>> So I think a datastore needs to be represented, at least > >> >>>>>> conceptually, > >> >>>>>> as XML infoset. > >> >>>>>> > >> >>>>>>> such as XPATH, how the validation is carried out is not defined in > >> >>>>>>> the YANG specifications. I guess I actually disagree with the > >> >>>>>> > >> >>>>>> I don't think this is true. YANG spec doesn't say how "must" and > >> >>>>>> "when" > >> >>>>>> statements are evaluated, and relies on XPath. > >> >>>>> > >> >>>>> RFC 6020: > >> >>>>> > >> >>>>> When a datastore is validated, all "must" constraints are > >> >>>>> conceptually evaluated once for each data node in the data tree, and > >> >>>>> for all leafs with default values in use (see Section 7.6.1). If a > >> >>>>> data node does not exist in the data tree, and it does not have a > >> >>>>> default value, its "must" statements are not evaluated. > >> >>>>> > >> >>>>> [...] > > The text you substituted here with an ellipsis is actually quite > important for this discussion because it defines the context for XPath > evaluation (together with section 6.4), in particular the data tree on > which every XPath expression is evaluated. It is clear that the data > tree can also comprise state data, notification content or RPC > input/output, i.e. not only datastore content as you keep saying. > > Terms like "context node" refer to the XPath data model as described in > sec. 5 of the XPath spec: > > http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model > > (and section 6.4 in RFC 6020 says it explicitly). > > We need to know, at least conceptually, how to construct the XPath data > tree from JSON text. For example, it has to be clear that leaf-list > entries encoded as a JSON array appear as sibling nodes in the data > tree, otherwise a "must" constraint specified for the leaf-list won't > work correctly. I don't think this is anyhow evident and IMO it has to > be addressed. This is the purpose of section 3 in > draft-ietf-netmod-yang-json-04. > > Would it help if "validation" is replaced with "XPath evaluation" > throughout this section? No. I continue to believe (a) a datastore is validated and not an XML infoset (or something like that) and (b) that the evaluation of "must" constraints is conceptual. JSON is an encoding. It remains unclear why you think that the JSON encoding has any impact of what happens with a datastore. /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] YANG-JSON Encoding review comments
On Wed, Jul 01, 2015 at 09:48:31AM +0200, Ladislav Lhotka wrote: > > I would rather have: > > > > > > > > > > "bar": ""; > > > > There have already been several ultra-long discussions about this in the > NETMOD mailing list. The stance taken by this draft is that anyxml is > just some data for which the schema is not known (in advance), or the > schema is not YANG. The only requirement is that the document containing > anyxml instance must remain valid for the given encoding. So JSON string > may also be anyxml content but it's not limited to that. > > I believe this is a natural extension of the purpose that anyxml played > when XML was the only encoding, and it can be used in the same way for > other encodings that may be defined in the future, such as CBOR. The > only problem, for me at least, is that it is a misnomer. The WG settled this debate and there is no point in trying to start it again. The bottom line is that anyxml remains defined as it has been defined in RFC 6020 and that it is RECOMMENDED to use anydata for anything that is can be modelled in YANG since anyxml. /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] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: > > > On 01 Jul 2015, at 09:21, Juergen Schoenwaelder > > wrote: > > > > On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder writes: > >> > >>> On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: > >>>> > >>>>> On 30 Jun 2015, at 15:39, Juergen Schoenwaelder > >>>>> wrote: > >>>>> > >>>>> On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder > >>>>>>> wrote: > >>>>>>> > >>>>>>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > >>>>>>>> Juergen Schoenwaelder writes: > >>>>>>>> > >>>>>>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > >>>>>>>>>> Hi Juergen, > >>>>>>>>>> > >>>>>>>>>> thank you for the review. > >>>>>>>>>> > >>>>>>>>>> Juergen Schoenwaelder > >>>>>>>>>> writes: > >>>>>>>>>> > >>>>>>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> This is a notice to start a NETMOD WG last call for the document > >>>>>>>>>>>> "JSON Encoding of Data Modeled with YANG": > >>>>>>>>>>>> > >>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >>>>>>>>>>>> > >>>>>>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM EST. > >>>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. > >>>>>>>>>>> > >>>>>>>>>>> - I am not sure I agree with the wording in section 3. Why is > >>>>>>>>>>> section > >>>>>>>>>>> 8.3.3 only applicable to XML encoded data? Validation applies to > >>>>>>>>>>> datastores. While constraints are defined using XML-based > >>>>>>>>>>> notations > >>>>>>>>>> > >>>>>>>>>> You are right that this section shouldn't talk about XML-encoded > >>>>>>>>>> data, > >>>>>>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: > >>>>>>>>>> "XPath > >>>>>>>>>> operates on the abstract, logical structure of an XML document, …". > >>>>>>>>>> > >>>>>>>>>> So I think a datastore needs to be represented, at least > >>>>>>>>>> conceptually, > >>>>>>>>>> as XML infoset. > >>>>>>>>>> > >>>>>>>>>>> such as XPATH, how the validation is carried out is not defined in > >>>>>>>>>>> the YANG specifications. I guess I actually disagree with the > >>>>>>>>>> > >>>>>>>>>> I don't think this is true. YANG spec doesn't say how "must" and > >>>>>>>>>> "when" > >>>>>>>>>> statements are evaluated, and relies on XPath. > >>>>>>>>> > >>>>>>>>> RFC 6020: > >>>>>>>>> > >>>>>>>>> When a datastore is validated, all "must" constraints are > >>>>>>>>> conceptually evaluated once for each data node in the data tree, and > >>>>>>>>> for all leafs with default values in use (see Section 7.6.1). If a > >>>>>>>>> data node does not exist in the data tree, and it does not have a >
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Sat, Jul 04, 2015 at 08:32:04AM +0200, Ladislav Lhotka wrote:
>
> >
> > Consider this definition:
> >
> > rpc foo {
> > input {
> > leaf x {
> > type uint8;
> > must ". = ../y";
> > }
> > leaf y {
> > type string;
> > }
> > }
> > }
> >
> > Then what's the result of conceptual XPath evaluation for this RPC
> > request?
> >
> > Just because you can construct a pathological
> > case comparing strings and numbers doesn't
> > mean anything.
>
> Pathological?? Don’t forget that uint64 numbers are encoded as strings in
> JSON. Moreover, comparisons of two nodesets are *always* performed on string
> values, even if both have numeric types in YANG.
>
> >
> > Use "number(foo) < number(bar)" to ensure that
> > numeric comparisons are done correctly.
> >
If this +1 != "1" needs fixing, I think it needs fixing in the YANG
specification. For datastores, things are kind of handled since RFC
6020 says:
Note that since all leaf values in the data tree are conceptually
stored in their canonical form (see Sections 7.6 and 7.7), any XPath
comparisons are done on the canonical value.
For notifications, this is kind of handled as well:
When a NETCONF server sends data, it MUST be in the canonical form.
And of course, we expect the server to only send notifcations that are
valid anyway.
For RPCs, the obvious things to do would be to require that XPATH
evaluation of RPC arguments also takes place on the canonical
representation of values.
/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 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". /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 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
[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/> --- Begin Message --- 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
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 06, 2015 at 08:16:32AM -0700, Andy Bierman wrote: > > > 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. But this assumes that there is a single revision that has been used by all imports. Are we sure this will be true for all implementations? Benoit just posted some numbers - OpenDaylight Lithim shipped with 473 YANG modules, about 155 YANG modules that can be extracted in I-Ds for the upcoming IETF, and other SDOs are on their way as well to produce YANG modules. If I assume that products will in a couple of years implement hundreds of YANG modules, do we believe that imports without revision can all be kept at a specific revision throughout the whole system? > 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. It seems to be a trade-off. If a vendor manages to manage his software very well, then 'default-revision=true' may do its job. If not, then we have no standard way to find out what was actually implemented. So we have the following scenarios: a) Import by revision de-factor disappears. Problem disappears. b) Import by revision does not disappear. 1) Vendor manages to keeps all modules aligned to a single revision, then 'default-revision=true' works. 2) Vendor does not manage to keep all modules aligned to a single revision (btw, this can also be forced on the vendor by modules from differnet SDOs), then we apparently need additional complexity to report what precisely was implemented. One option out could be to strongly recommend a), to provide the 'default-revision=true' possibility, to provide b.2) as a feature for systems where 'default-revision=true' is not workable. /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] Interface Extensions YANG draft
gt; >https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ > > > >Any comments or feedback is appreciated. > > > >Potential points of interest/discussion may be: > > - Is it acceptable to define standard YANG for features that are not > > backed by any formal standard if they are commonly implemented? > > - We've tried to restrict the leaves to just the interface types (using > > when if:type = ...) that the configuration applies to rather than > > adding them to all interfaces. Feedback would be welcome on whether > > this approach is a good idea/maintainable. > > - For MTU, I've defined two different MTU leaves because devices > > program interface MTU in different ways based on whether the configured > > MTU value includes the L2 header overhead or not. Is this a reasonable > > approach? > > > >Thanks, > >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 -- 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] Interface Extensions YANG draft
On Mon, Jul 13, 2015 at 03:43:59PM +0100, Robert Wilton wrote: > Hi Juergen, > > If I understand your comment correctly, this would imply that you have a > separate interface representing the basecaps independently from the > interface itself. As far as I know this isn't widely done even if it > supported by ifStack. Whatever basecaps are... > More naturally it feels that the interface layering is more useful to > represent LAG interfaces or VLAN sub-interfaces, which can be done, but > section 3.3 Interface Layering from YANG Interface Management indicates > that the layering attributes are read only, so you still need separate > configuration leaves to set up the parent<->child relationship. See Appendix C in RFC 7223 how this was envisioned to be done. /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] Y34
device” container. What would be > really useful is to have the possibility to do e.g. this: > > virtual-node* [name] > name > if:interfaces > ... > > to support the use case where all virtual nodes are managed by the same > NETCONF/RESTCONF server. > > Lada > > > > > > > > > Lada > > > > Andy > > > > > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > > > Hi, > > > > > > > > > > after listening to the presentation of > > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > > > fact is > > > > > > > > > > +--rw device > > > > > +--rw info > > > > > | +--rw device-type? enumeration > > > > > +--rw hardware > > > > > +--rw interfaces > > > > > | +--rw interface* [name] > > > > > | ... > > > > > +--rw qos > > > > > > > > > > So the "interfaces" container is no more a top-level node. There are > > > > > three possible options: > > > > > > > > > > 1. Change the ietf-interfaces module. > > > > > 2. Replicate its contents in another module. > > > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > > > given data node. > > > > > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > > > > seems it is not so because it doesn't specify a concrete data model > > > > > that's allowed at a given location. > > > > > > > > > > On the other hand, the only real contribution of "anydata" over > > > > > "anyxml" > > > > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > > > > > > > I know Y34 was already closed but I think it is more important to do > > > > > things right before YANG 1.1 becomes an RFC. > > > > > > > > > > What I want to propose is this: > > > > > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" > > > > > (but > > > > > keep it for backward compatibility). > > > > > > > > s/Rename/Introduce/ > > > > > > > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > > > > extend the schema tree starting from that data node with a precisely > > > > > specified data model. The specification can be same or similar as > > > > > in yang-library. > > > > > > > > > > I believe there are other use cases in the existing modules. For > > > > > example, the ietf-routing module could simply define the data model > > > > > for > > > > > a single routing instance (i.e. without "routing-instance" list at the > > > > > top), and it can be then used without changes on simple devices, and > > > > > more complex router implementations can graft it as a subtree under > > > > > "routing-instance", "networking-instance" or whatever. > > > > > > > > > > Lada > > > > > > > > > > -- > > > > > Ladislav Lhotka, CZ.NIC Labs > > > > > PGP Key ID: E74E8C0C > > > > > > > > > > ___ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > > ___ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34
On Tue, Jul 21, 2015 at 09:16:46AM +0200, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 23:00, Juergen Schoenwaelder > > wrote: > > > > Lada, > > > > Y34 is closed and I have not seen any new argument here that indicates > > we made a major mistake with the resolution of Y34. As such, Y34 > > remains closed. > > Of course, I was expecting this reaction. I think I did present *some* > arguments, and I am leaving it to others to judge whether they are relevant > or not. Even if it was a minor mistake, it is IMO still worth fixing. > > > > > If you want to discuss new ideas to relocate or "symlink" data models, > > please do so in a separate thread. (And no, we do not accept new > > issues for YANG 1.1 either at this point in time.) > > It’s not about symlinks in the data tree but rather about a method for > combining schemas that is complementary to “augment” - pull versus push. > > There is sufficient evidence that it was one of the use cases for “anydata”, > e.g. in configlets. The gap in “anydata” definition for similar use cases is > that it cannot specify a schema for its contents. > Lada, you can't simply 'mount' a data model into a different place. Think about paths in must or when expressions, or think about paths contraints in leafrefs etc. And Y34 was not trying to solve this problem, so this discussion is IMHO under a misleading subject line. /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] Dual mode validators needed
On Tue, Jul 21, 2015 at 04:56:48PM +0200, Balazs Lengyel wrote: >Hello, >It must be possible to chose for validator tools whether I want to >validate according to Y1.0 or Y1.1. Why? A data model that says version 1.1 should be validated according to YANG 1.1 rules and a data model that says version 1 (or does not declare a version at all) will be validated according to YANG 1.0 rules. /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
[netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items
This is the summary of the discussion of YANG 1.1 issue Y60 at the IETF 93 meeting in Prague: - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which will of course be interpreted according to the YANG 1.0 rules). - The YANG 1.1 RFC will not obsolete RFC 6020. (RFC 6020 may be retired when all published YANG 1.0 data models have been converted to YANG 1.1.) - The title should be made less NETCONF specific (and the same applies to the Abstract and the Introduction). This will not affect the NETCONF specific examples that are used throughout the text. - The IANA considerations text copied from RFC 6020 will be removed from the YANG 1.1 specification. - The IETF will not run a transition process to retire YANG 1.0; it is assumed that this will happen naturally anyway eventually. - The NETMOD WG recommends that the IETF will publish only YANG 1.1 modules as RFCs once the YANG 1.1 RFC has been published. Action items: - AB to check whether there are any loopholes. - JS to schedule virtual interim meetings to handle review comments. /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] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific
On Sat, Jul 25, 2015 at 05:26:16PM -0700, Andy Bierman wrote: > Hi, > > The WG should decide what it means for YANG to not > be NETCONF-specific. Why does YANG define extensions > to NETCONF operations (like insert)? IMO the normative text > about NETCONF should not be in the YANG RFC. > So what is your proposal? /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] new YANG 1.1 Issue Y61: I2RS support
On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > Hi, > > I would like to open another issue for YANG 1.1, > because I don't want to have 1.1 and then 1.2 right away. > The NETMOD WG should evaluate the different ways to > support ephemeral state, based on Jeff's draft. > The NETMOD WG did spent almost a full day face-to-face interim meeting time in September 2014 on this and now we have a requirements I-D plus a solution proposal that does not directly match what was discussed back then. It is my understanding that the solution discussed in September 2014 does not require changes to YANG 1.1. I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG 1.1 is gating other specifications and I am not interested to hold everything off (including RESTCONF) because of I2RS. There are many other customers of YANG 1.1 beyond I2RS. /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] YANG 1.1 Y60 IETF 93 discussion summary and action items
On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bierman wrote: > On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > This is the summary of the discussion of YANG 1.1 issue Y60 at the > > IETF 93 meeting in Prague: > > > > - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which > >will of course be interpreted according to the YANG 1.0 rules). > > I am not convinced this will be a good idea. > Obviously the compiler has to restrict 1.0 modules to 1.0 syntax, > but the corner-case semantics that have been clarified in 1.1 > SHOULD be followed if a 1.1 module imports 1.0, even for augment. > Please provide concrete examples what breaks if we allow to import YANG 1.0 modules (using 1.0 semantics). > If this is the case then I think the "restconf-media-type" hack > should be a real YANG statement. The reason it is an extension > is because YANG is NETCONF-only. A real statement > could support augments and deviations. > > Just removing a sentence from the abstract is not going to fix all > NETCONF-specific details in YANG. (Just ask Lada ;-) It is > not going to make YANG correct for RESTCONF. Please provide concrete examples where YANG is incorrect for RESTCONF. > YANG will need to be modified for I2RS anyway. YANG 1.1 took > too long, and now I2RS is ready. I strongly object to the idea > of starting on 1.2 while 1.1 is still unpublished. Nobody proposed to work on YANG 1.2. > > - The IANA considerations text copied from RFC 6020 will be removed > >from the YANG 1.1 specification. > > Does this mean that YANG 1.1 will have a normative reference to RFC 6020? > Or are the references to the IANA registries? Joel (AD) said this will all be OK. I had my doubts but he said it is no problem since the registry now exists and won't go away anyway even if RFC 6020 goes historic. Please check the recording. /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] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific
Any are concrete actionable proposals? /js On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: > > > On 26 Jul 2015, at 02:26, Andy Bierman wrote: > > > > Hi, > > > > The WG should decide what it means for YANG to not > > be NETCONF-specific. Why does YANG define extensions > > to NETCONF operations (like insert)? IMO the normative text > > about NETCONF should not be in the YANG RFC. > > > > This is essentially what I proposed in Berlin (IETF 87): > > http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod > > (first item in Open mike section). > > Another thing that I realized only recently is that some properties that are > inherent to the conceptual data tree are defined in “XML Mapping” sections. > > I think most YANG concepts and statements can be defined in terms of data > tree properties. Separate documents would then define different encodings, > and “profiles” for management protocols. > > It would need massive changes in 6020bis text though. > > Lada > > > > > Andy > > > > > > > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] new YANG 1.1 Issue Y61: I2RS support
On Sun, Jul 26, 2015 at 12:53:41PM +0200, Ladislav Lhotka wrote: > > What might be a new task for YANG is to define general syntax for identifying > different trees and inter-tree references. > This is not the time to add new features to YANG 1.1. /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] new YANG 1.1 Issue Y61: I2RS support
On Sun, Jul 26, 2015 at 04:17:26AM -0700, Andy Bierman wrote: > On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I would like to open another issue for YANG 1.1, > > > because I don't want to have 1.1 and then 1.2 right away. > > > The NETMOD WG should evaluate the different ways to > > > support ephemeral state, based on Jeff's draft. > > > > > > > The NETMOD WG did spent almost a full day face-to-face interim meeting > > time in September 2014 on this and now we have a requirements I-D plus > > a solution proposal that does not directly match what was discussed > > back then. It is my understanding that the solution discussed in > > September 2014 does not require changes to YANG 1.1. > > > > I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG > > 1.1 is gating other specifications and I am not interested to hold > > everything off (including RESTCONF) because of I2RS. There are many > > other customers of YANG 1.1 beyond I2RS. > > Yeah, it's too bad so many drafts are waiting on YANG. > Support for I2RS got started but never finished. > I care more about the costs of deploying tools and the extra complexity > on readers, who need to know all the versions of YANG. > The proposed solution changes one of the most important statments > in YANG. Harding something to do as an afterthought. I do not think there is agreement on any solution yet. I heard also about vendors implementing ephemeral state solutions that do not require any changes to YANG (and that seem to be more inline with what was discussed in September 2014). > It should not take that long because the NETCONF WG (same people) > have been spending almost all f2f and virtual interim time on I2RS. > The YANG doctors concluded that ephemeral state > was a general feature and not NETCONF specific. > > The problem with using YANG extensions for important protocol features > is that the YANG spec says these statements MAY be completely skipped > by a tool implementation. This is not acceptable for ephemeral state > (or operational state either). I do not know what is to be addressed for operational state. /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] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific
Lada, there won't be any decision as long as there is not a concrete actionable proposal to be discussed. Such a proposal does not have to be 'complete rewrite' but it needs to be a detailed list of what would have to change so that it is possible to assess such a proposal. /js On Sun, Jul 26, 2015 at 01:06:54PM +0200, Ladislav Lhotka wrote: > > > On 26 Jul 2015, at 12:55, Juergen Schoenwaelder > > wrote: > > > > Any are concrete actionable proposals? > > Start rewriting 6020bis, but only if we decide to go that way - it is a > difficult decision. I will be slightly in favor of doing so. > > Lada > > > > > /js > > > > On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: > >> > >>> On 26 Jul 2015, at 02:26, Andy Bierman wrote: > >>> > >>> Hi, > >>> > >>> The WG should decide what it means for YANG to not > >>> be NETCONF-specific. Why does YANG define extensions > >>> to NETCONF operations (like insert)? IMO the normative text > >>> about NETCONF should not be in the YANG RFC. > >>> > >> > >> This is essentially what I proposed in Berlin (IETF 87): > >> > >> http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod > >> > >> (first item in Open mike section). > >> > >> Another thing that I realized only recently is that some properties that > >> are inherent to the conceptual data tree are defined in “XML Mapping” > >> sections. > >> > >> I think most YANG concepts and statements can be defined in terms of data > >> tree properties. Separate documents would then define different encodings, > >> and “profiles” for management protocols. > >> > >> It would need massive changes in 6020bis text though. > >> > >> Lada > >> > >>> > >>> Andy > >>> > >>> > >>> > >>> > >>> ___ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> ___ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- 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] new YANG 1.1 Issue Y61: I2RS support
On Sun, Jul 26, 2015 at 11:17:19AM -0700, Andy Bierman wrote: > > I know there is not agreement on the solution yet. Exactly. And hence talking about YANG 1.2 is simply confusing. > That is why it is an open issue. I2RS does not have to present NETMOD WG > with a solution (even though they did present an acceptable solution). If you mean duplication of data models and data model specific merge rules then I have trouble to believe this is desriable nor does it seem to reflect what other proprietary ephemeral datastore implementations do. > In order for I2RS to have the YANG validation rules that meet its > use-cases, new text is needed. This text needs to be associated > with data-nodes. > > I like the proposed solution of config=true,ephemeral,false > because I know none of the existing text inadvertently applies > to ephemeral nodes. I would prefer to have ephemeral datastore support as an extension; not all uses of YANG (perhaps even a big majority) require to describe ephemeral datastores. > I do not think YANG is fully specified wrt/ datastores because > operational state and ephemeral nodes are not separated. > An ephemeral datastore (and perhaps operational datastore) > are needed to solve this problem. But depending on the solution selected, this may not require any changes to YANG 1.1. /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] I-D Action: draft-ietf-netmod-entity-02.txt
On Wed, Mar 08, 2017 at 02:48:15PM +, Bogaert, Bart (Nokia - BE) wrote: > Hi, > > > If we pick the former, it will not be possible to configure a > > component with a system controlled parent (unless you also add the > > system controlled parent to the configuration). > > [Bart Bogaert] Is there a reason to only have this parent in the state > > tree and not in the config tree? > > I am not sure I understand the question. Suppose the config tree is empty, > and the system boots and populates the state tree with all detected > harwdare. Next, a client would like to pre-provision a module in a chassis > that exists in state. If the leafref is to the config tree, the client > would have to create both the chassis and the module in the config tree, > since the leafef would otherwise fail to validate. > > [Bart Bogaert] Ok, so you are looking for a solution that refers to an entry > in the state tree. I always thought that one could not refer from config to > state but it seems I misunderstood this since this is exactly what you are > proposing. > > > If we pick the latter you will not get any validation (since it has to > > be require-instance false). > > > > It is fine w/ me to change the type string to a leafref of the former > type. > > Correction: I am fine with changing the string to a leafref to state. > > > [Bart Bogaert] If we leave it as a string it would mean that an > > external application would have to check whether the value of the > > string actually corresponds to a component that should exist (in the > > case of a non-system-controlled parent)? > > So are you ok with a leafref to state? > > [Bart Bogaert] Since that seems possible this would solve the problem. I'm > checking this with our people. Are you discussing leafref to a config false node with require instance false? I am not sure this is valid YANG. /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] stable reference for tree diagram notation
On Wed, Mar 08, 2017 at 09:15:48AM -0800, Andy Bierman wrote: > Suggested Text: > > OLD: > >If YANG tree diagrams are used, then a sub-section explaining the >YANG tree diagram syntax MUST be present, containing the following >text: > > A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is > defined in [RFC]. > > NEW: > >If YANG tree diagrams are used, then a sub-section explaining the >YANG tree diagram syntax MUST be present, explaining the symbols >in the diagram. The actual text will depend on the version of >the YANG tree diagram syntax used in the document. > I think we can allow both and leave it to the document author. Either the author uses a well known tree format and refers to its definition or the author usees a not yet well known tree format and then it has to be defined inline: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, explaining the symbols used in the tree diagram. This sub-section can either explain the tree diagram format inline or it can refer to an external specification of the tree diagram format that is used. A specification using the tree diagram format defined in this document may simply state: The meaning of the symbols in these diagrams is defined in [RFC]. The way bigger issue I think is how to make sure that the text in this sub-section is actually inline with the tree diagram itself since it is easy for this to get out of sync (I admit that I generally do not read the tree diagram blurb and I would not be surprised if people cut'n'paste tree diagram blurbs). In other words, what we may want is a short label _in_ the tree format itself that uniquely identifies the format and is generated by the tool producing the tree format. pyang -f tree --tree-RFCWXYZ foo.yang format: RFCWXYZ module: foo I personally would trust such an inline label way more than any tree diagram sections because the label is likely created by the tool that created the diagram. We have seen I-Ds where the tree diagram is out of sync with the YANG definitions. Perhaps the idea to have tools for checking tree diagrams is not that far fetched. (Even though I first thought the idea of checking tree diagrams is somewhat ridiculous.) /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] stable reference for tree diagram notation
On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote: > > This way, reader can focus more quickly on the diffs, but also this > likely mimics what happened in reality (start with `pyang -f tree` > and then manually edit from there). What do you think? > Manually edited tree diagrams? I hope not. Perhaps we should have text saying that tree diagrams are expected to be generated by tools and that they are expected to be consistent with the model (and hence they need to be updated with every change, hence usage of tools is a damn good idea). [I thought this is obvious but perhaps this is not.] /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] rfc 6087bis - stress importance of instance examples
On Wed, Mar 08, 2017 at 05:40:44PM +, Kent Watsen wrote: > > > >> I think we should encourage authors to write examples. > > > > +1 And also encourage authors to validate the examples > > using their favorite YANG instance validation tool. > > > Please note this from the latest 6087bis update: > >4.12. Module Usage Examples > >Each specification that defines one or more modules SHOULD contain >usage examples, either throughout the document or in an appendix. >This includes example XML instance document snippets to demonstrate >the intended usage of the YANG module(s). > > and I already wrote this: > > Nice addition, but should it say something about JSON, in addition to XML? > Perhaps that, unless there is a reason to only pick one encoding, examples > should be split between the two? - just throwing it out there to see if > this is > something we might want to recommend...thoughts? > > https://mailarchive.ietf.org/arch/msg/netmod/dOpSYzM_J05Sdmgt-MyYmqJIUz0 > I think the purpose of section 4.12 is to encourage people to check that their definitions lead to reasonable instance documents. It is easy to choose identifiers in the schema that look reasonable in the schema but horrible in instance documents. The purpose of the examples should in general not be to showcase that YANG can have different instance representation formats. I would leave it to the WG to decide whether they prefer examples in JSON or XML. In LMAP, I once had examples in both XML and JSON and that was not useful (lots of additional pages with no real added value). All that said, you likely end up naming things slightly different depending on whether you look primarily at a JSON encoded instance document or an XML encoded instance document. But I do not care much as long as identifiers are reasonably consistent. /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
[netmod] security considerations boilerplate updates to cover RESTCONF
Hi, this came up during IESG processing of a YANG module - is there a new security guideline boilerplate text covering RESTCONF? This was briefly discussed on the yang-doctors but somehow the discussion stopped because RESTCONF was not published yet at that time. I think this affects draft-ietf-netmod-rfc6087bis-12.txt. draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read online documents - why do we need several points? I think some are also not working. Ideally, there should be a single stable URL. /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] draft netmod charter update proposal
On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > That said different people including Netconf WG co-chairs think the DS > concept document is Informational in nature and should be published as an > Informational concept to be used in and adopted for the needs in diverse > protocol WGs. This is as I think also important to avoid an overlapping > between NETCONF and NETMOD charters. The current datastore draft includes concrete YANG idenity definitions for datastores and origins and these definitions better be standards track. /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] security considerations boilerplate updates to cover RESTCONF
On Wed, Mar 15, 2017 at 08:10:22PM +0100, Benoit Claise wrote: > I like the "YANG based management protocols" part I think 'YANG based' is not needed (and to some extend even incorrect) and I would spell out 'network management' instead of 'management': The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. /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] security considerations boilerplate updates to cover RESTCONF
On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: > Latest proposal: > > The YANG module defined in this document is designed to be accessed > via network management protocols such as NETCONF [RFC6241] or > RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport > layer, > and mandatory-to-implement secure transport is Secure Shell (SSH) > [RFC6242], > while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement > secure > transport is Transport Layer Security (TLS) [RFC5246]. Picking wording from Section 12 of RFC 8040 to replace your second sentence I get this: The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. /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] augment and if-feature
On Thu, Mar 16, 2017 at 09:54:14AM +, Robert Wilton wrote: > In short, I think that if-feature statements work better if they act on the > given node and all descendant nodes, regardless of which module those > descendants are defined in. I think there is something important here. The augment does not really make a difference. What seems to be the root of the issue is whether an if-feature on say a container or list applies down the hierarchy. RFC 7950 is not very specific about this. It only says: The "if-feature" statement makes its parent statement conditional. Of course, if a container or list is conditional, then everything inside will only exist if the feature is supported, so I think it is reasonable to assume that the if-feature applies down the hierarchy but this is not explicitly stated (but it seems to be the only reasonable way to implement this). Anyway, once we have clarified this, the augment behaviour falls out of this. That said, as a service to readers, it might still be useful to repeat the if-feature definition in augmenting modules but this would purely be a service to the readers, not something that is required by the language itself. /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] Combining if-feature statements
On Thu, Mar 16, 2017 at 10:04:56AM +, Robert Wilton wrote: > YANG nodes can have multiple if-feature statements. Its not entirely > obvious to me how if-feature statements combine for a given node. I presume > that a node is supported if all if-feature statements on the node are valid. > Is this the correct interpretation? yes /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] security considerations boilerplate updates to cover RESTCONF
On Thu, Mar 16, 2017 at 12:48:34PM +, Kent Watsen wrote: > > A couple comments: > > 1) drilling down on the mandatory-to-implement NC/RC protocols >is somewhat missing the point. The important bit is that >*all* protocols transporting YANG-modeled data *only* have >secure transport layers. More specifically, YANG-modeled >data may be transported over other protocols (e.g., coap), >and also one of the protocols have an insecure transport >protocol (e.g., it doesn't much help to talk about HTTPS >being mandatory-to-implement if RESTCONF allowed HTTP). RESTCONF says MUST use TLS. Making an open ended statement about security properties of unknown protocols sounds risky. > 2) just stating that there are secure transport layers still >isn’t sufficient, as these protocols must also require >mutual authentication in order to be secure, and for >statements regarding NACM to make sense. The text I posted >before had a statement like this in it. > > I'm beginning to become a fan of the idea of defining a generic > "Requirements for Protocols Transporting YANG-modeled Data" > document - that would not only discuss security aspects, but > also generic protocol operations, that documents like NC, RC, > CoAP, etc. can point to...and even YANG (RFC 7950), rather than > pointing directly at NETCONF as it does today... Keep in mind that I2RS believes in a requirement for cleartext transport protocols. Perhaps this never makes it through the IESG but so far it was not possible to stop this... /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] security considerations boilerplate updates to cover RESTCONF
On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote: > > > > Keep in mind that I2RS believes in a requirement for cleartext > > transport protocols. Perhaps this never makes it through the IESG but > > so far it was not possible to stop this... > > > > This is solely for notifications that can be sent, just as IPFIX > information may > be sent unencrypted. Those requirements are in > draft-ietf-i2rs-protocol-security-requirements-17 > <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>, > which is in the RFC Editor queue. > The new features are priority, an opaque secondary identifier, and an insecure protocol for read-only data constrained to specific standard usages. The optional insecure transport can only be used restricted set of publically data available (events or information) or a select set of legacy data. Data passed over the insecure transport channel MUST NOT contain any data which identifies a person. I think your statement that it is only for notifications is wrong. The fact that some data ships in a notification does not mean the data is not sensitive. Furthermore, I think we all meanwhile know that IPFIX data is highly sensitive if you have the right context information (so the analogy is flawed). And what the heck is a 'select set of legacy data'? SEC-REQ-06: An I2RS agent receiving an I2RS message over an insecure transport MUST confirm that the content is suitable for transfer over such a transport. An agent can't decide this. It is the context information that often decides whether a piece of information is sensitive or not. So the only decision an agent can do is to only allow messages with empty content over an insecure transport. The I2RS architecture defines three scopes: read, write, and notification scope. Insecure data can only be used for read scope and notification scope of "non-confidential data". I understand that the IESG approved the security requirements. I do not know why the security ADs did let this pass - perhaps since the document is just about requirements and they will look closer at a solution and then ask questions what 'non-confidentail' data' is, what a 'select set of legacy data' is, or how an agent confirms that the content of messages is suitable for an insecure transport. Anyway, this does not belong here, the point I wanted to make is simply that Kent's assumption that a protocol transporting YANG defined data is always protecting the data is not true from the viewpoint of the I2RS proponents. Thanks for confirming this. /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] draft netmod charter update proposal
On Fri, Mar 17, 2017 at 02:22:43PM +0100, Mehmet Ersue wrote: > I think YANG identities should be standardized with 7950bis. Why? These identities are not specific to the YANG language itself. /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] some comments on revised-datastores-01
On Sun, Mar 19, 2017 at 06:11:35PM +, Kent Watsen wrote: > > Wait, I think you're mixing things up. I'm not talking about using YANG > Library to identify which datastores a module can be accessed in, so much as > knowing which datastores are implemented in the first place. > > For instance, assuming the "ephemeral" datastore example example in the > draft, a client knows a server implements it because ietf-ds-ephemeral is > listed in YANG Library. And so it is with all dynamic datastores, but not > so for built-in (non-dynamic) datastores (e.g. intended) because there isn't > a module to advertise for them (yet). > Obviously, relying on module names does not work if a module defines multiple datastores. So either the set of datastores is identified from reading the whole yang-library list or we provide a separate list (and I think we should provide a separate list). /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] some comments on revised-datastores-01
On Sun, Mar 19, 2017 at 07:49:05PM +, Kent Watsen wrote: > > > Obviously, relying on module names does not work if a module defines > > multiple datastores. So either the set of datastores is identified > > from reading the whole yang-library list or we provide a separate list > > (and I think we should provide a separate list). > > It seems okay for more than one datastore to be represented by a single > module. Presumably the set of them come together as a package (all or none), > right? This could be a datastore-designer decision to make. > > For instance, I2RS talks about priority-ordered planes of glass, so maybe > they have a single "ietf-ds-ephemeral" module defining a package of > datastores like: plane-1, plane-2, ... plane-8. > > Yes, we could have a separate explicit list, but it'd be nice if we could > reuse what we have... > Sorry, overloading is bad. The definition of an identity does in general not mean an implementation of an identity. /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] some comments on revised-datastores-01
On Mon, Mar 20, 2017 at 02:05:09PM +, Kent Watsen wrote: > > Why are you mentioning identities here? Yes, the module defines > identities, but that is beside the point to what I'm saying. I'm > only discussing the module (e.g. ietf-i2rs-solution) showing up > in YANG Library and using the age-old logic of, if the server > advertises it, then it means that it supports it, which in this > case means that it supports all the datastores defined by the > module. > But this logic is already broken for the datastores defined in the revised datastores document. It defines an identity for startup but not all systems implement startup. End of proof. /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] some comments on revised-datastores-01
On Mon, Mar 20, 2017 at 02:28:53PM +, Kent Watsen wrote: > > > But this logic is already broken for the datastores defined in the > > revised datastores document. It defines an identity for startup but > > not all systems implement startup. End of proof. > > Ha ha, yes professor. But recall this started as a discussion regarding > what to do for the new dynamic datastores (not built-in datastores) and > then someone said maybe we should support other datastores too. I'm not > sure we need to do this but, if we did, then we could create modules for > them (i.e., ietf-startup). > I believe this is the wrong direction, even if we rewrite the module in the revised datastores document and split it into multiple modules. A simple list of implemented datastores is cheap. It is flexible. It does not require explanations and rules how definitions must be split into modules that finally must be remembered and checked still in 5-10 years from now. I firmly believe that these types of 'optimizations' lead to creeping complexity down the road. Lets not create CLRs how modules must be structued, named, etc. /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] draft netmod charter update proposal
On Fri, Mar 17, 2017 at 04:33:24PM +0100, Ladislav Lhotka wrote: > > I don't think that config true/false is necessarily tied to a particular set > of datastores, it can be generalized to RW/RO. > I do not agree that config true/false just means read write and I certainly do not want semantics of statements to be changed. It is easy to create new statements if needed. /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] draft netmod charter update proposal
On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: > > The revised-datastores draft changes the semantics of "configuration data" - > for example, the definition from RFC 6241 clearly won't apply to the > "running" datastore in the new datastore model. Why would that be the case? > So a new definition of configuration data will probably be needed, and this > implicitly changes the semantics of the "config" statement. > YANG defines the config statement as follows: The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration are part of configuration datastores. I do not think it is the intend of the revised datastore model as written down in the I-D to change this. > BTW, we use rw/ro in tree diagrams. Which is a mis-nomer (tree diagrams were inherited from the SNMP world and somehow the rw/ro distinction was kept even though it is technically wrong). There are more details here, I will start a separate thread for this. Note that the diagrams in the revised datastore ID make a clear distinction between ct/cf and rw/ro. In particular, the ID notes that ct object may be rw in one datastore but ro in a different datastore. /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
[netmod] tree diagrams - flags
Hi,
if we want to standardize tree diagrams, we may want to take a more
critical look at them, in particular the flags (that were created
ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help
says:
is one of:
rw for configuration data
ro for non-configuration data
-x for rpcs and actions
-n for notifications
This is (a) incomlete and (b) somewhat confusing since ct does not
equate to readwrite. I am attaching a sample yang file and here is the
output pyang 1.7.1 produces:
module: tree-sample
+--rw config-true-container
| +--rw param? string
+--ro config-false-container
| +--ro value? string
+--rw inline-action
| +---x action
| + oops? string
| +---w input
| | +---w in? string
| +--ro output
|+--ro out? string
+--rw inline-notification
+---n notification
+ duration? string
rpcs:
+---x rpc
+---w input
| +---w in? string
+--ro output
| +--ro out? string
+--ro oops? string
notifications:
+---n notification
+--ro boom? string
I think a better usage of two letter flags would have been this (since
it more naturally aligns with what the YANG definition says):
is one of:
ct for configuration data
cf for non-configuration data
x- for rpcs and actions
xi for rpc or action input
xo for rpc or action output
n- for notifications
nt for notification tree (this is I think the term 7950 uses)
module: tree-sample
+--ct config-true-container
| +--ct param? string
+--cf config-false-container
| +--cf value? string
+--ct inline-action
| +--x- action
| +--xi input
| | +--xi in? string
| +--xo output
|+--xo out? string
+--ct inline-notification
+--n- notification
+--nt duration? string
rpcs:
+--x- rpc
+--xi input
| +--xi in? string
+--ro output
+--xo out? string
notifications:
+--n- notification
+--nt boom? string
(And I think the oops leafs should have triggered an error.)
/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/>
module tree-sample {
yang-version 1.1;
prefix "tree";
container config-true-container {
leaf param { type string; }
config true;
}
container config-false-container {
leaf value { type string; }
config false;
}
container inline-action {
action action {
leaf oops { type string; }
input {
leaf in { type string; }
}
output {
leaf out { type string; }
}
}
}
container inline-notification {
notification notification {
leaf duration { type string; }
}
}
rpc rpc {
input {
leaf in { type string; }
}
output {
leaf out { type string; }
}
leaf oops { type string; }
}
notification notification {
leaf boom { type string; }
}
}
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] draft netmod charter update proposal
On Tue, Mar 21, 2017 at 10:59:11AM +0100, Ladislav Lhotka wrote: > > If the "config" statement really carried some protocol-specific semantics > that isn't meaningful for all potential uses of YANG, it would be better to > remove it from core YANG and define it as an extension that would be > mandatory for configuration protocols that need it. > YANG exists because we wanted to describe and manage configurations. And some people still want to do this. I understand that you want to turn YANG into a general purpose data modeling language. But I am not sure this is consensus. As of today, config true means what is defined in RFC 6020 and RFC 7950. /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] tree diagrams - flags
On Tue, Mar 21, 2017 at 11:36:29AM +0100, Martin Bjorklund wrote:
> > I think a better usage of two letter flags would have been this (since
> > it more naturally aligns with what the YANG definition says):
> >
> >is one of:
> > ct for configuration data
> > cf for non-configuration data
> > x- for rpcs and actions
> > xi for rpc or action input
> > xo for rpc or action output
> > n- for notifications
> > nt for notification tree (this is I think the term 7950 uses)
>
> I'm fine with this, but perhaps use "no" for notification data - "t"
> means "true" in "ct".
I once had nd (notification data) but then in the last moment moved
to nt since 7950 uses the term notification tree...
> Also, in a grouping like this:
>
> grouping my-grouping {
> leaf param { type string; }
> }
>
> pyang prints this as:
>
> my-grouping
> + param? string
>
> i.e., w/o any flags.
>
This makes sense, it just needs to get documented...
> > (And I think the oops leafs should have triggered an error.)
>
> They did. To stderr.
Oops, my fault.
/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] tree diagrams - flags
On Tue, Mar 21, 2017 at 01:01:58PM +0100, Ladislav Lhotka wrote: > > > On 21 Mar 2017, at 12:50, Robert Wilton wrote: > > > > > > So I am suggesting perhaps just having: > > > > is one of: > > c for configuration data > > x for rpcs and actions > > n for notifications > > > > module: tree-sample > > +--c config-true-container > > | +--c param? string > > +--- config-false-container > > | +-- value? string > > +--c inline-action > > | +--x- action > > | +--x input > > | | +--x in? string > > | +--x output > > |+--x out? string > > +--c inline-notification > > +--n notification > > +--n duration? string > > I think the "x" and "n" is only needed next to the name of > rpc/action/notification. So my version would be: > > is one of: > c for configuration data > x for rpcs and actions > n for notifications > > module: tree-sample > +--c config-true-container > | +--c param? string > +--- config-false-container > | +--- value? string > +--c inline-action > | +--x action > | +--- input > | | +--- in? string > | +--- output > |+--- out? string > +--c inline-notification > +--n notification > +--- duration? string > Single character flags work for me as well. Since I have modules with pretty complex RPC inputs (more than a single page in RFC formatting), I think it is useful to be able to see that one is still starting at an RPC input tree and not a regular data tree or a notification tree. So I tend to like Rob's proposal a bit more. /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] tree diagrams - flags
On Tue, Mar 21, 2017 at 04:55:18PM +0100, Ladislav Lhotka wrote: > > > > > Single character flags work for me as well. Since I have modules with > > pretty complex RPC inputs (more than a single page in RFC formatting), > > I think it is useful to be able to see that one is still starting at > > an RPC input tree and not a regular data tree or a notification tree. > > Even with long RPC parameter lists the indentation should make it obvious > what belongs where. Another option might be to label every input parameter > with "xi" or "i" and output with "xo"/"o", and remove the "input" and > "output" nodes. This would make the output shorter and narrower. > I wrote multiple pages - indentation is difficult to follow over page boundaries. > > So I tend to like Rob's proposal a bit more. > > Note however that Rob's proposal doesn't distinguish input and output > parameters, all are labelled with "x". > I know. At least I know I am still in an rpc/action definition. But yes, some of this may be personal preference. /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] uses and augment
On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> I've got a couple of questions about the interaction of "uses" and
> "augment". I hope that these have straightforward answers that the old
> hands can tell me easily enough.
>
> 1. Augmenting a grouping
>
> I notice that "augment" is not allowed to target a "grouping", despite
> that naively seems to be an operation that a module designer might like
> to do. I expect that there is a reason why this is not allowed.
>
> For example:
>
> module foo {
>...
>grouping target {
> leaf address {
>type inet:ip-address;
>description "Target IP address.";
> }
> leaf port {
>type inet:port-number;
> description "Target port number.";
> }
>}
> }
>
> module bar {
>...
>import foo {
>...
>}
>augment "/foo:target" {
> leaf new-leaf {
>type string;
> }
>}
> }
>
> module baz {
>...
>import foo {
>...
>}
>container main {
> uses foo:target;
>}
> }
>
> giving an effective schema:
>
>container main {
> leaf address {
>type inet:ip-address;
>description "Target IP address.";
> }
> leaf port {
>type inet:port-number;
> description "Target port number.";
> }
> leaf new-leaf {
>type string;
> }
>}
This is not at all clear. You only import 'foo' - so why would the
augment of /foo:target (which is not exactly defined either) done in
'bar' apply to uses foo:target in baz? In short, it is unclear where
the augmentation of the grouping applies and where not. Augments are
restricted to things that have a well defined name in the data tree
because this makes it clear what is being augmented. One would have to
create additional language constructs to make augmentations of
groupings work.
/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] uses and augment
On Thu, Mar 23, 2017 at 08:50:48PM -0400, Dale R. Worley wrote: > Martin Bjorklund writes: > >> I notice that "augment" is not allowed to target a "grouping", despite > >> that naively seems to be an operation that a module designer might like > >> to do. I expect that there is a reason why this is not allowed. > > > > There were lots of debate over this one when we first designed YANG. > > The main reason for not allowing this is that it can easily have > > unintended consequences. Module A uses a grouping G b/c it fits the > > purpose. Later someone augments G with some nodes; at this point it > > is not at all clear that the additional nodes are suitable for module > > A. > > True... But assuming that the grouping G has clean semantics, it > corresponds to some facility in the device, which in some way or another > appears in multiple places in the device's data model. And a module > that augments G adds semantics about that facility, and would only be > implemented by a device for which the facility uniformly has that > additional semantics. So it would be suitable for every place where the > grouping is used. But this is an assumption and it is not generally true. [...] > But what I'm considering is a modification of > the grouping which implicitly applies to all "uses" of that grouping -- > because you don't want to have duplicate declarations of the added nodes > in every place the grouping is used. There may be cases where this may appear useful but I see also cases where people will get largely suprised by the result if such wildcard augmentations would be possible. > > Augments are restricted to things that have a well defined name in the > > data tree because this makes it clear what is being augmented. One > > would have to create additional language constructs to make > > augmentations of groupings work. > > It's clear that *groupings* have well-defined names, because "uses" > statements can refer to them. I wrote 'name in the data tree' and I meant 'name in the schema tree' (sorry). Augments apply to something that has a name in the schema tree, groupings do not have that. The "grouping" statement is not a data definition statement and, as such, does not define any nodes in the schema tree. > RFC 7950 section 7.13 isn't particularly > clear about how the argument string of the statement is to be > interpreted, but going back over 7950, I'm getting the idea that the > names of groupings are not descendant-schema-nodeid's, that is, named > based on where the grouping statement sits in the syntactic hierarchy, > but are in a separate namespace which is flat regarding equality and > inequality comparisons, but has elaborate scoping rules regarding which > groupings are visible in which locations. Yes. > OK, that clarifies why you can't apply "augment" to a grouping -- > groupings (and thus the things defined within them) don't have names > that can be expressed by descendant-schema-nodeid's. Yes. This is how things were defined. /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] System management YANG model
On Tue, Apr 04, 2017 at 10:09:01AM +, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hi, > > When looking at the system time management part of this model I notice that > for ntp only a config true section is foreseen. But assume that we learn at > run-time the NTP server (e.g. using DHCP), there is no config false data > part to reflect what has been learned dynamically. Storing this in the > config true part does not seem to be correct to me since this might get lost > because of a copy-config action (in case a NC client never configured > something there). Are we not missing a server-list in the state data? > Yes, but the good news is that the revised datastore architecture solves this issue without requiring any changes to the model. ;-) /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] System management YANG model
On Tue, Apr 04, 2017 at 10:49:34AM +, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > On Tue, Apr 04, 2017 at 10:09:01AM +, Bogaert, Bart (Nokia - BE/Antwerp) > wrote: > > Hi, > > > > When looking at the system time management part of this model I notice > > that for ntp only a config true section is foreseen. But assume that > > we learn at run-time the NTP server (e.g. using DHCP), there is no > > config false data part to reflect what has been learned dynamically. > > Storing this in the config true part does not seem to be correct to me > > since this might get lost because of a copy-config action (in case a > > NC client never configured something there). Are we not missing a > server-list in the state data? > > > > Yes, but the good news is that the revised datastore architecture solves > this issue without requiring any changes to the model. ;-) > > [Bart Bogaert] Ok, but there is no NC server implementing this yet so this > means that everybody needs to solve it in their way if this is needed now? > Doesn't this raise an interop issue if different approaches are taken? There is not standard yet to report an NTP server learned say via DHCP. Reporting a dynamically learned NTP server is simply not part of the system model - so yes you can't expect interoperability for this. I doubt that the system model will be changed to add a specific state object for this given the direction we are moving to. /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] WG adoption poll draft-lhotka-netmod-yang-markup-00
On Thu, Apr 13, 2017 at 08:13:50AM +0200, Ladislav Lhotka wrote: > > If you want to ignore the extension proposed by this draft in your tools, you > are free to do so. Other people may want to use this extra information. > As a human, I can't ignore markup thrown at my eyes. /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] RFC7952 annotation to identify leaf encryption/hashing format
RFC 7952 says:
4. Annotations sent by a server should not break clients that don't
support them.
If the client is expected to understand which hash function has been
used to generate a hash value, then I think the hash function should
be communicated as proper YANG data and not as metadata.
/js
On Mon, May 22, 2017 at 05:16:36PM +, Sterne, Jason (Nokia - CA/Ottawa)
wrote:
> Hi all,
>
> Does anyone see any reasons why RFC7952 annotations couldn't/shouldn't be
> used to identify the encryption/hashing format of an encrypted/hashed leaf ?
>
> There are a number of approaches out there for encrypted/hashed leafs (e.g.
> RFC7317 crypt-hash which encodes the hash function by prepending $x$ to the
> password, using multiple leafs for the value/algorithm, etc).
>
> These are leafs that can be typically written in cleartext or
> encrypted/hashed format, but return only an encrypted/hashed format when
> retrieved from a device.
>
> I think RFC7952 annotation could also be used as an approach to this problem.
>
> Annotation definition:
>
> md:annotation hash-format {
>type enumeration {
> enum md5l
> enum sha-256
> ...
>}
> }
>
> An 'auth-key' leaf that is hashed:
>
>
> QsdsEWfjKAowjjhQHHslJSHHll
>
>
>
> Regards,
> Jason
>
> Note - I don't believe this statement in section 9 would point anyone away
> from using annotations for encryption/hashing information (since the
> encrypted leafs are data nodes): "It is RECOMMENDED that security-sensitive
> or privacy-sensitive data be modeled as regular YANG data nodes rather than
> annotations."
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Question on intefaces-state model
On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > We have a question regarding the statistics container as defined in the > interfaces-state model. This container defines one mandatory leaf > (discontinuity-time) while all other leafs are optional. What is the > rationale behind this leaf being mandatory and not an optional field? > > It does not make a lot of sense to return a discontinuity-time value and no > counters if none of the counters are relevant for a specific interface. > > Another alternative could be to add, via a deviation, a when clause to the > container indicating for which ifType(s) the container is (or is not) > present. But that would lead to not supporting the IETF interfaces model to > the full extent. > The discontinuity-time is relevant for _any_ counter associated with an interface, regardless whether the counter is defined in the interfaces model or elsewhere. I have a hard time to imagine an interface that has zero counters. /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] Clarification Question on draft-dsdt-nmda-guidelines-01
Hi, the typical -state tree consists of config false nodes and hence it represents operational state. This is not a transitioning period question, this is how -state trees were designed. Note also that the applied configuration is part of the operational state in NMDA - for config true objects, there is no difference between the applied configuration value and the operationally used value - they are the same. /js On Tue, Jun 13, 2017 at 07:53:32PM +, Xufeng Liu wrote: > During discussing the adoption of this guidelines, a question came up w.r.t. > the semantics of the non-NMDA "-state" module during the transitioning period: > > What kind of state do the leaves in the "-state" module represent? The > applied configuration or the actually used operational data? > Since only of the two types can be represented, what is the guideline to > model the other type? > > Thanks, > - Xufeng -- 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] Question on intefaces-state model
On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote: > > Returning zero values here is not useful, in fact it is misleading. I think > that if a server doesn't have a value to return for a particular node it is > much better to return nothing than to return a false value. +1. It took us years to kill this attitude in SNMP land. Saying a counter is zero and never changes is largely misleading if you actually have no such counter. It is easy to waste hours of expensive engineering time by given people fake counters. /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] XPath questions about revised datastores
Andy,
section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses
the XPath context. An xpath expression in a config-false container
will resolve to the operational state.
/js
On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote:
> Hi,
>
> I don't know if getting rid of /foo-state is such a great idea,
> especially wrt/ counters and other objects that are not
> related to intended config vs. applied config.
>
> Q1) how does a client know the difference between an auto-generated
> foo-state.yang and a real foo-state.yang? Seem like a YANG extension
> is needed to flag an auto-generated foo-state.yang
>
> Q2) How does XPath reference an operational node if the /foo-state
> subtree has been moved to the /foo config subtree?
>
> module foo {
>
> container foo {
> leaf stat-collect-type {
> type enumeration {
>enum stat-set1;
>enum stat-set2;
> }
>}
> }
>
> container foo-state {
> config false;
> leaf stat-collect-type {
> type enumeration {
>enum stat-set1;
>enum stat-set2;
> }
>}
>container stat-set1 {
> when "../stat-collect-type = 'stat-set1'";
> ...
>}
>container stat-set2 {
> when "../stat-collect-type = 'stat-set2'";
> ...
>}
> }
> }
>
> In this example, there is a request stat collect type /foo/stat-collect-type
> and there is an operational value (what the server/device is capable
> of collecting -- e.g. client requests stat-set2 knowing the server
> will change it to stat-set1 if set2 not supported)
>
> So if /foo-state is folded into /foo (because that is the intent -- to get
> rid of this extra stat-collect-type leaf), then how do the when-stmts
> get applied to the operational value instead of the configured value?
> The same issue applies if the when-stmts are within an augment-stmt
>
> WANT:
>
> augment /foo-state {
> when "stat-collect-type = 'stat-set1'";
> container stat-set1 {
>...
> }
> }
>
> RD Provides:
>
> augment /foo {
> when "stat-collect-type = 'stat-set1'";
> container stat-set1 {
>config false;
>...
> }
> }
>
> There is no way to use when-stmt to reference the operational value.
> This is a rather common usage of the when-stmt, so it should not
> be removed if RD is used.
>
>
>
> Andy
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
