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 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.. The sections such as 5.6.4. Announcing Conformance Information in NETCONF 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, unchanging set of data but rather one that expects data to be updated so such operations are a part of the language. 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. 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! 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 > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod