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

[Martin Bjorklund <[e-mail]>]

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