> On 20 Jul 2015, at 19:29, Andy Bierman <[email protected]> wrote:
>
>
>
> On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <[email protected]> wrote:
>
> > On 20 Jul 2015, at 17:00, Andy Bierman <[email protected]> wrote:
> >
> >
> >
> > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <[email protected]> wrote:
> >
> > > On 20 Jul 2015, at 14:55, Andy Bierman <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > Can you explain why we need 2 broken anyxmls?
> > > (The original and a synonym?) The whole point of
> > > anydata is that it does not have XML cruft in it.
> >
> > Yes, I understand this was your main priority. For implementors using
> > off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
> >
> >
> > yes it is an issue.
> > We need something to model a container full of arbitrary YANG data nodes.
> > This is something that can be applied to the contents of a datastore.
>
> anyxml can do that, too.
>
>
> the WG already decided it can't.
> The extra XML PIs, etc. are not accepted by all servers, remember?
> There is no use for the extra stuff in the datastore.
> I don't see why we need 2 anyxml constructs that are not
> supported by the industry. One is already too many.
I agree, but this is what we are going to have. My proposal was to have just
one with two different names.
>
>
> >
> >
> > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no
> > (YANG) schema available. My only complaint to “anyxml” has always been that
> > it is a misnomer for encodings other than XML.
> >
> > The message encoding on the wire is not the same issue
> > as the contents of a datastore. Our server stores its own
> > internal data structures. XML, JSON, CBOR are just message
> > encoding formats between client and server. The datastore
> > is not encoded in any of these formats.
>
> The payload of anyxml needn’t directly map to a data subtree in the usual
> sense.
>
> that's precisely the difference between anyxml and anydata.
> The anydata node MUST map directly into data subtrees.
If the server doesn’t know the YANG data model at run time (which is possible)
then it cannot do it - for instance, it cannot properly map module names to
namespace URI or handle lists.
>
>
>
> >
> >
> >
> >
> >
> > >
> > > I also don't get the value of a single top-level node called 'device'
> > > that every YANG model on the planet is supposed to augment.
> > > Can you explain why a protocol operation to retrieve the
> > > document root (/) is not sufficient for the top-level node?
> >
> > I don’t intend to defend their model, the more serious problem IMO is that
> > a model for a single device/function may be needed in another device that
> > hosts many virtualised devices/functions of the former type. We don’t have
> > a good solution for this rather typical situation.
> >
> > But a single container called "whatever" provides no such aggregation.
> > You would need a list for that. And the NMS might have multiple
> > layers of hierarchy to represent various aggregations. The NP
> > container called "device" is not helpful for aggregation.
>
> The parent node can be a list as well. The “root” node would be like a mount
> point in a Unix filesystem.
>
>
> Are you saying all data on a device needs to be in a top-level list called
> 'device'
> because an NMS might exist that wants to have the datastores from lots of
> devices?
> As Martin pointed out several times, the NMS can make its own container or
> lists. It does not need the device to mirror its own structure.
As I said, I don’t care that much about the “device” container. What would be
really useful is to have the possibility to do e.g. this:
virtual-node* [name]
name
if:interfaces
...
to support the use case where all virtual nodes are managed by the same
NETCONF/RESTCONF server.
Lada
>
>
>
> Lada
>
> Andy
>
>
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Andy
> > >
> > >
> > >
> > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <[email protected]> wrote:
> > >
> > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > after listening to the presentation of
> > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > > > whether the solution chosen for Y34 is really useful.
> > > >
> > > > The draft states they want to reuse ietf-interfaces but their tree in
> > > > fact is
> > > >
> > > > +--rw device
> > > > +--rw info
> > > > | +--rw device-type? enumeration
> > > > +--rw hardware
> > > > +--rw interfaces
> > > > | +--rw interface* [name]
> > > > | ...
> > > > +--rw qos
> > > >
> > > > So the "interfaces" container is no more a top-level node. There are
> > > > three possible options:
> > > >
> > > > 1. Change the ietf-interfaces module.
> > > > 2. Replicate its contents in another module.
> > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> > > > given data node.
> > > >
> > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
> > > > seems it is not so because it doesn't specify a concrete data model
> > > > that's allowed at a given location.
> > > >
> > > > On the other hand, the only real contribution of "anydata" over "anyxml"
> > > > is that is doesn't permit mixed content in XML, which is IMO not much.
> > > >
> > > > I know Y34 was already closed but I think it is more important to do
> > > > things right before YANG 1.1 becomes an RFC.
> > > >
> > > > What I want to propose is this:
> > > >
> > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but
> > > > keep it for backward compatibility).
> > >
> > > s/Rename/Introduce/
> > >
> > > >
> > > > - Introduce a new statement and data node type, e.g. "root", that will
> > > > extend the schema tree starting from that data node with a precisely
> > > > specified data model. The specification can be same or similar as
> > > > in yang-library.
> > > >
> > > > I believe there are other use cases in the existing modules. For
> > > > example, the ietf-routing module could simply define the data model for
> > > > a single routing instance (i.e. without "routing-instance" list at the
> > > > top), and it can be then used without changes on simple devices, and
> > > > more complex router implementations can graft it as a subtree under
> > > > "routing-instance", "networking-instance" or whatever.
> > > >
> > > > Lada
> > > >
> > > > --
> > > > Ladislav Lhotka, CZ.NIC Labs
> > > > PGP Key ID: E74E8C0C
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
