> On 6 Mar 2017, at 13:34, t.petch <ie...@btconnect.com> wrote: > > The NETCONF list has also been discussing a charter update, as some of > you will know, and part of that consists of taking into a NETCONF I-D > parts of RFC7950. > > I see a joint agreement as to just which bits of RFC7950 will be elided > as the starting point for this (followed by a revision of RFC7950). > > I am reminded that in the latter days of 6020bis the point was made that > the terminology therein was inconsistent, sometimes using NETCONF XML > and sometimes XML (an inconsistency which has been carried across to > RFC7950). I see the references to NETCONF XML as something of an > oxymoron, a bit like saying 'HTTP jpeg' or 'railroad cow'; they are > different beasts. So I would > /NETCONF XML/XML/ * * > > Having done that, I think that the XML should stay in 7950bis; it is > like having a worked example (which is how many people learn > languages:-) and would be clearer to those steeped in XML than the YANG
Of course, examples of instance data are important but in most cases JSON would be significantly easier to read. 7950bis could also contain examples in both XML and JSON (as RFC 8040 does). > is. Also, removing it generates problems for NETCONF, that the NETCONF > I-D would then have to include XML, YANG, some explanation thereof, > references therefrom and so on. The clean boundary is to keep the XML > in 7950bis and have a NETCONF I-D just describe how that XML is then > wrapped up in a transporting protocol, ditto for any other protocol > although were it not to use XML, then it would also have to define the > use of whatever it is using.. 7950bis should include a much more explicit definition of the conceptual data tree, and specifications for particular encodings of the data tree can be in separate documents. All these documents can IMO stay in NETMOD because they are protocol independent. Each protocol would then choose to support one or more of the encodings. > > The sections such as > > 5.6.4. Announcing Conformance Information in NETCONF > Yes, but I think we need a *data modelling* formalism for specifying a bundle of YANG modules (including schema mount). YANG has currently almost no support for this, so tools often use hello or yang-library data for this purpose. So I would like to have some standard metadata like this, detached from protocols and devices. > 7.5.8. NETCONF <edit-config> Operations > > go but I think that 7950bis still needs to talk about > conceptual operations, such as create/delete/update/; else how can you > discuss ordered-by user? YANG is not a DDL that describes a static, It simply means that the order of entries carries some semantics. In fact, such a property might also be useful in state data. That said, some background context of CRUD and other operations can of course remain. > unchanging set of data but rather one that expects data to be updated so > such > operations are a part of the language. As a matter of fact, almost all formal rules in YANG are about static data. Apart from "ordered-by", probably the only other exception is "config true/false", which could be generalized to the "RW/RO" property. > > Likewise on errors, that 7950bis should still talk about the errors in > generic terms, a consequence of talking about operations, but should > leave the encoding to a transporting protocol. Yes, 7950bis can define appropriate error-app-tags. > > Section 8 is an interesting one. YANG defines itself as a language for > defining RPC so something needs to be said about RPC but will operations > always be performed by RPC? Well, not necessarily! The concept of operations/RPCs/actions and their signatures is sufficiently general, it should IMO stay in some form. Lada > > 7950bis would still need > urn ...netconf > . > Tom Petch > > ----- Original Message ----- > From: "Kent Watsen" <kwat...@juniper.net> > To: "Ladislav Lhotka" <lho...@nic.cz>; "t.petch" <ie...@btconnect.com> > Cc: "Jürgen Schönwälder" <j.schoenwael...@jacobs-university.de>; "NetMod > WG Chairs" <netmod-cha...@ietf.org>; <netmod@ietf.org> > Sent: Wednesday, March 01, 2017 4:56 PM > Subject: Re: [netmod] draft netmod charter update proposal > > >> Hi Lada, >> >> I understand your intention here, but I'm inclined to agree with > others >> that it's better to stick with the term we're using in the documents. >> I'm open to the idea of changing the term used in our RFCs, and I > believe >> that such a change would likely have to begin with the YANG spec, from >> which it could flow into other drafts. With this in mind, I've added > an >> item to the yang-next tracker: >> >> https://github.com/netmod-wg/yang-next/issues/17 >> >> and I plan to revert this change in the charter text. >> >> Thanks, >> Kent >> >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
