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

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Apr 2016 23:00:27 +0000

[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

I realize that the full-impact of this change would impact draft-clemm-netmod-mount, but I'd like us to settle on long-term terms as soon as possible.

My other high-level thought is, assuming the schema-mount requirements are removed from this draft, would there really be a need for this requirements draft?  - is it expected to get published or would it be allowed to expire, as soon as the WG adopts draft-clemm-netmod-mount, as then it's purpose would've been served?   I realize that we have a precedent with opstate-reqs, but I might claim that that doc was necessary as we (the WG) really didn't understand the requirements and we had to document them.  In this case, it seems that alias/peer/data-mount has fewer parties involved and, in fact, is partially documenting an existing implementation (ODL).  Maybe my question is, would it make long-term sense to merge the requirements text into draft-clemm-netmod-mount?

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Apr 2016 11:38:22 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> 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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Apr 2016 08:56:53 -0300

> On 05 Apr 2016, at 06:38, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 5 Apr 2016 23:35:21 +0000

Hi, Martin, Lada,

unfortunately I wasn't able to attend the discussion, but I have one comment regarding the "definition" vs "implementation" distinction.  

Clearly, peer-mount and alias-mount have a definition component to it.  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.  

The aspect that I don't think I agree with is that peer-mount and alias-mount should be treated merely as an "implementation".  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.  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.  

--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Tuesday, April 05, 2016 4:57 AM
To: Martin Björklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Apr 2016 09:18:52 +0200 (CEST)

Hi,

"Alexander Clemm (alex)" <[email-masked]> 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

> Subject: Re: [netmod] kw comments on
> draft-voit-netmod-yang-mount-requirements
> 
> 
> 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
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Apr 2016 09:29:55 -0300

> 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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Apr 2016 02:20:19 +0000

> Martin Bjorklund, April 05, 2016 5:38 AM
> 
> Hi,
> 
> Listening to Eric's presentation yesterday, I realized that I have a slightly
> different view on these terms.
> 
> implemented.  The various proposals for specific implementations (peer mount
> and alias mount etc) all need a "schema mount" to take of

Applications will have to know the full path to an object, but might not have to know the full schema of mounted objects.   (i.e., with a path, a data mount access a specific node without mounting the full schema.)  This shouldn't pose any issues as Peer Mount implementation so far have been read-only, and internal constraints within a namespace need not be checked.

> With the associated yang-library, a client might learn that ietf-interfaces is
> mounted under the "logical-device" mount mount.
> 
> 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

My thinking matches more closely to what Kent lays out above:

schema-mount
data-mount
remote data mount   (a.k.a. peer mount)
local data mount        (a.k.a. alias mount)

The value in the term "yang mount" is that it provides a conceptual umbrella to ensure a cohesive syntax across the four valid permutations of the above.  The term itself was never intended to be implementable.

Adding Alex for his thoughts as he has thought through configuration examples more deeply than I have.

Eric

> 
> As a concrete example, peer mount might be used like this (example taken from
> draft-clemm-netmod-mount-03):
> 
> 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
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Apr 2016 02:52:31 +0000

> Ladislav Lhotka, Wednesday, April 06, 2016 8:30 AM
> 
> 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
 
> >> >> 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".
> >> >>
> >> >> 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
> >> > Listening to Eric's presentation yesterday, I realized that I have
> >> > a slightly different view on these terms.
> >> >
> >> 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.
> >>
> >> > 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
> >> >
> >> >
> >> >
> >> > 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
> >> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Apr 2016 08:57:48 +0200

> The value in the term "yang mount" is that it provides a conceptual umbrella to ensure a cohesive syntax across the four valid permutations of the above.  The term itself was never intended to be i…

So why do we need 'local data mount' (aka 'alias mount')? Which
problem does it solve that 'peer mounting' localhost does not solve?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Apr 2016 13:32:35 +0000

> From: Juergen Schoenwaelder, April 08, 2016 2:58 AM
> 
> > The value in the term "yang mount" is that it provides a conceptual umbrella to
> ensure a cohesive syntax across the four valid permutations of the above.  The
> term itself was never intended to be implementable.
> >
> 
> So why do we need 'local data mount' (aka 'alias mount')? Which problem does
> it solve that 'peer mounting' localhost does not solve?

To me it comes down to ease of use for the developer. If the system only allows mounting localhost, why require that parameter in the syntax?   That parameter shouldn't even be available/visible for entry. 

Eric

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 8 Apr 2016 19:02:20 +0000

Hello Juergen

to your question: 
"> So why do we need 'local data mount' (aka 'alias mount')? Which 
> problem does it solve that 'peer mounting' localhost does not solve?"

Yes, you could apply peer mounting to a local host as a special case.  Certainly there is nothing that should prevent that.  However, the distinction is still relevant.  For one, in the peer mounting case, the remote host is considered the authoritative owner, the mounting host is _not_ the authoritative owner.  In alias mount, since it is the same owner, it has authority.  

The fact that in peer mount the local host has no authority means that the use cases primarily targeted involve cases that require visibility of data and support for a data retrieval, read-only view.  One of the concerns that had been raised earlier were the ramifications that transactional behavior and locking etc would have in a distributed scenario.  Given that alias-mount is local, things are simplified and use cases that go beyond pure providing visibility easier to support.  So, alias mounting may be an important special case of peer mounting, but also a simple case.  This is a fact that we would like to leverage.  

In practical terms, alias mount and peer mount can look very similar.  Peer mount involves an additional parameter (to identify the target system), with corresponding additional mountpoint management ramifications.  So, peer mount can in that sense build on top of, or extend, alias mount.  

--- Alex

-----Original Message-----
From: Eric Voit (evoit) 
Sent: Friday, April 08, 2016 6:33 AM
To: Juergen Schoenwaelder <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]; Alexander Clemm (alex) <[email-masked]>; [email-masked]
Subject: RE: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements

> ensure a cohesive syntax across the four valid permutations of the 
> above.  The term itself was never intended to be implementable.
> >
> 

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 9 Apr 2016 10:29:45 +0200

Is the essence of your long text that the difference of alias mount
and local peer mount is:

alias mount = read-write
peer mount = read-only

Is it documented somewhere how writing (including locking) works with
alias mount, how NACM works with alias mount, ...?

/js