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

> On 05 Apr 2016, at 06:38, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Hi,
> 
> Kent Watsen <kwatsen@juniper.net> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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