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

[Ladislav Lhotka <[e-mail]>]

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.

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:[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