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

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

> Martin Bjorklund, April 05, 2016 5:38 AM
> 
> 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...)

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.

> 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

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