> Ladislav Lhotka, Wednesday, April 06, 2016 8:30 AM > > 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.
Peer Mount implementations have been read-only (so far). It would be good to avoid requiring the transactional requirements for write and therefore the needs to bring in and validate with the schema. Such a requirement would be very heavy-weight for use with remote systems. It might not even be possible if those remote systems have access control permissions which don't permit visibility against objects used for such validations. > 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. Read-only access control objects should be easier for a sub-schema rather a full schema. For remote system access we already need these security elements for a get, hopefully we are not requiring anything new when we insert the peer mount abstraction. Eric > 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
