Re: [netmod] YANG schema mount - any early implementations?

2018-07-20 Thread Juergen Schoenwaelder
On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote: > > I understand that the schema mount proposal is still effectively in a > state of flux, but are there any publicly visible implementations or > deployments of a NETCONF or RESTCONF server that those interested could > experiment with

[netmod] "iana" in yang modules' name/namespace/prefix

2018-07-20 Thread Martin Vigoureux
Hello As part of a recent IESG review (of draft-bfd-yang) a point came up on the use of "iana" in yang modules' name/namespace/prefix. This is typically used in the case where the module refers to an IANA maintained registry. However, the point raised was that the name of the registry operator

[netmod] Thoughts on draft-clemm-netmod-nmda-diff

2018-07-20 Thread Joe Clarke
I just had a chance to finish reading this. The in-person meeting group seems to strongly support this work, and I agree. Coming from a serviceability standpoint, I find this might serve as a precursor to a VCS-like "blame log". Would it be reasonable to include identifiers as to who (or what) m

[netmod] clarifications for draft-clemm-netmod-nmda-diff

2018-07-20 Thread Sterne, Jason (Nokia - CA/Ottawa)
Hi all, One thing that we should probably clarify in the diff draft is that a comparison to the operational datastore is not expected to be an atomic snapshot.. As the diff function walks through the nodes, some of the operational nodes may change value while the diff is underway. I believe

Re: [netmod] "iana" in yang modules' name/namespace/prefix

2018-07-20 Thread Acee Lindem (acee)
Hi Martin, I would prefer not using "reg" since it will always be an abbreviation for a machine language register to me. I'd favor using "registry" in the module name and the more cryptic "reg" in the module prefix. Thanks, Acee On 7/20/18, 9:46 AM, "netmod on behalf of Martin Vigoureux" w

Re: [netmod] "iana" in yang modules' name/namespace/prefix

2018-07-20 Thread Juergen Schoenwaelder
On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote: > As part of a recent IESG review (of draft-bfd-yang) a point came up on the > use of "iana" in yang modules' name/namespace/prefix. > This is typically used in the case where the module refers to an IANA > maintained registry. How

Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

2018-07-20 Thread Qin Wu
Add two additional thoughts, (1) I hope NMDA datastore can be used to compare one datastore at two different timepoints, so I am not sure source and target defined in the model are enough to support this case. (2) NMDA Base events defined in (https://tools.ietf.org/html/draft-wu-netconf-base-not

Re: [netmod] "iana" in yang modules' name/namespace/prefix

2018-07-20 Thread Mahesh Jethanandani
Sent from my iPhone > On Jul 20, 2018, at 10:40 AM, Juergen Schoenwaelder > wrote: > >> On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote: >> >> As part of a recent IESG review (of draft-bfd-yang) a point came up on the >> use of "iana" in yang modules' name/namespace/prefix.

[netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

2018-07-20 Thread Andy Bierman
Hi, I strongly object to requirement 3.1: 3.1 The solution MUST provide a mechanism to allow servers to support existing clients in a backward compatible way. This is not what servers do today at all. They provide only one version of an implemented module, as specified in RFC

Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

2018-07-20 Thread Juergen Schoenwaelder
My understanding is that the MUST puts a requirement on the solution and the rest is an "allow servers", i.e., something that servers may want to do. (I was against using RFC 2119 keywords in the first place for this document.) /js On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote: > H

Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

2018-07-20 Thread Juergen Schoenwaelder
On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote: > Hi, > > I strongly object to requirement 3.1: > > > 3.1 The solution MUST provide a mechanism to allow servers to > support existing clients in a backward compatible way. > > > > This is not what servers do today