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

[Martin Bjorklund <[e-mail]>]

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.


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