Hi,
Kent Watsen <kwat...@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
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
