Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements

["Eric Voit (evoit)" <[e-mail]>]

> Ladislav Lhotka, Wednesday, April 06, 2016 8:30 AM
> 
> Martin Bjorklund <[e-mail]> writes:
> 
> > Hi,
> >
> > "Alexander Clemm (alex)" <[e-mail]> 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:[e-mail]] On Behalf Of Ladislav
> >> Lhotka
> >> Sent: Tuesday, April 05, 2016 4:57 AM
> >> To: Martin Björklund <[e-mail]>
> >> Cc: [e-mail]
> >> Subject: Re: [netmod] kw comments on
> >> draft-voit-netmod-yang-mount-requirements
> >>
> >>
> >> > On 05 Apr 2016, at 06:38, Martin Bjorklund <[e-mail]> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Kent Watsen <[e-mail]> 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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod