Hi, Martin, Lada, unfortunately I wasn't able to attend the discussion, but I have one comment regarding the "definition" vs "implementation" distinction.
Clearly, peer-mount and alias-mount have a definition component to it. This is why the YANG extensions were defined to define mountpoints. This definition component can be aligned with structural mount, and the goal needs to be to reuse the same. So far, so good. The aspect that I don't think I agree with is that peer-mount and alias-mount should be treated merely as an "implementation". I think I understand where you are coming from - to the user of mounted data, they don't care if there are other "instances" of the same data and how the data they see is populated. That said, I don't think this viewpoint is entirely correct, because there are certain semantics associated with it, and also because there are different implications with regards to mountpoint management which need to be reflected in the model. (For example, for peer-mount, there needs to be information on the remote system.) For the semantics, I think the fact should be captured when mounted data depends on target data. We capture conditions and constraints for semantically accurate models; the fact that the "aliased" data reflects another instance in another subtree is something that sure needs to be captured and understood. For example, without reflecting this relationship, an application might try to set an authoritative subtree/datanode to one value, the mounted version of it to a different value. So, whether or not there is an alias, or a peer, to an instance of data is something that should be reflected in the model. In other words, I don't think you can see the mountpoint and data mounted below it in entire isolation from the rest of the system. Another question concerns what you are actually mounting. In alias-mount, the mounted subtree may actually have been augmented and have other data nodes underneath it. Does the mounting apply to also augmenting data? For structural mount, the answer is clearly "no", but for peer-mount it doesn't have to be. --- Alex -----Original Message----- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka Sent: Tuesday, April 05, 2016 4:57 AM To: Martin Björklund <m...@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements > On 05 Apr 2016, at 06:38, Martin Bjorklund <m...@tail-f.com> wrote: > > Hi, > > Kent Watsen <kwat...@juniper.net> wrote: >> [As a contributor] >> >> Note: this is a -00 document, but only because the draft's name >> changed. In reality this is like a >> draft-voit-netmod-peer-mount-requirements-04. Looking at the diffs, >> there aren't many changes, mostly cleanup and adding the "schema >> mount" concept. That is, the new "yang mount" term is use to cover >> all of "schema mount", "alias mount", and "peer mount". >> >> My comment is mostly high-level. I'm wondering about the need for >> this draft to include schema mount at all. That is, a schema mount >> solution draft is now an adopted WG item, and I'm unsure if the >> authors of that draft are looking to this one to define requirements. >> Perhaps the goal is to define the umbrella term "yang mount", but to >> be honest, I don't really see a need to have a term that spans both >> schema and data mounts. I'm not sure how others feel about this, but >> my thoughts are that we should define terms like: >> >> - scheme-mount >> - data-mount >> - remote data mount (a.k.a. peer mount) >> - local data mount (a.k.a. alias mount) >> >> More so than: >> >> yang-mount >> - scheme-mount >> - alias-mount >> - peer-mount > > Listening to Eric's presentation yesterday, I realized that I have a > slightly different view on these terms. > > I prefer to separate the *schema* (data model) from how things are > implemented. The various proposals for specific implementations (peer Yes, I expressed this opinion already in Yokohama. Moreover, Eliot's presentation indicated that there are use cases in which YANG is used for modelling data outside the context of a management protocol. So IMO it is legitimate to require that even with schema mount it is possible to write a compact specification of the complete schema. Such a schema is static as before, the only change is that we have more flexibility in composing the modules, whereas currently they can be only put side by side. Also, there needn't be any mechanism like peer mount, all data may be local. Perhaps this use case is really different from the more dynamic situation where the server needs to fetch the subschemas at runtime and the data are contributed by an external entity. Lada > mount and alias mount etc) all need a "schema mount" to take of > defining a proper data model. (This was the whole point of defining > structural-mount...) > > For example, suppose we have: > > container logical-devices { > list logical-device { > key name; > ... > yangmnt:mount-point logical-device; > } > } > > With the associated yang-library, a client might learn that > ietf-interfaces is mounted under the "logical-device" mount mount. > > Now, the client knows that there are paths: > > /logical-devices/logical-device/if:interfaces/if:interface > > but the client doesn't necessarily have to know if the the interfaces > data is implemented w/ "peer mount" or some other mechanism. > > > So, in my view, we have: > > schema mount > | > +---- peer mount > +---- alias mount > +---- other cool mount > > > > As a concrete example, peer mount might be used like this (example > taken from draft-clemm-netmod-mount-03): > > import ietf-schema-mount { > prefix yangmnt; > } > import ietf-peer-mount { > prefix pmnt; > } > > ... > > list network-element { > key "element-id"; > leaf element-id { > type element-ID; > } > container element-address { > ... // choice definition that allows to specify > // host name, > // IP addresses, URIs, etc > } > yangmnt:mount-point "interfaces" { > pmnt:target "./element-address"; > pmnt:subtree "/if:interfaces"; > } > ... > } > > > A client that knows about the generic, abstract schema mount can work > with this, without knowing anything of the specific implementation of > peer mount. > > [Actually, since peer mount is just one implementation technique, I'd > prefer to decouple the definition of this implementation detail from > the data model, but that's a different topic.] > > > /martin > > _______________________________________________ > 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
