Martin Bjorklund <m...@tail-f.com> writes: > Hi, > > "Alexander Clemm (alex)" <a...@cisco.com> wrote: >> Hi, Martin, Lada, >> >> unfortunately I wasn't able to attend the discussion, but I have one >> comment regarding the "definition" vs "implementation" distinction. > > I probably failed to communicate my point clearly. I did not want to > make the distinction in this way. > >> Clearly, peer-mount and alias-mount have a definition component to >> it. > > Yes, absolutely. I don't think I implied that they didn't. > >> 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. > > Yes, this was my point. In Eric's presentation he had "schema mount", > "peer-mount", and "alias-mount" on the same level; all three different > variations of the generic concept "YANG Mount". I think that is > incorrect; we should have a generic "schema mount", with "peer-mount" > and "alias-mount" being specializations of this concept.
I would go even further: schema mount and peer mount are independent and orthogonal (not sure about alias mount - this is probably still something else). That is, I can build a data model with schema mount, and use it for validating a good old local datastore. Conversely, it is IMO possible to apply peer mount and validate the data against a data model that's constructed according to the existing rules. So, even though it may be sometimes beneficial to combine schema mount and peer mount, I believe they can and should be implemented as two independent concepts. A pure schema mount should have no security implications, whereas accessing remote data certainly has some. And accepting a (sub)schema from an external source requires IMO even higher level of trust. Lada > > >> The aspect that I don't think I agree with is that peer-mount and >> alias-mount should be treated merely as an "implementation". > > Again, this is not what I wrote. I wrote that: > > the client doesn't *necessarily* have to know if the the interfaces > data is implemented w/ "peer mount" or some other mechanism. > > [note "necessarily"] > > I agree that *some* clients need to be able to manage mount targets > etc, but not all. > >> 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. > > If the client is fully aware of the alias mount concept, why bother > with it? > > As I have said previously, we (tail-f) have had alias mount > implemented for many years (we call it "symlink"), and we have bad > experiences with all scenarios but the very simplest ones (simple leaf > to leaf alias). And even in this case users get pretty confused by > errors caused by validation that depends on the target leaf. > >> 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. > > I don't understand what you mean. Maybe you can show an example? > > > /martin > > >> >> --- 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 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
