Re: [netmod] Y34
Ladislav Lhotka <lhotka@nic.cz> Mon, 20 July 2015 17:42 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D701B2CCE for <netmod@ietfa.amsl.com>; Mon, 20 Jul 2015 10:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.061
X-Spam-Level:
X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_210=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EvmJ8pRsIbW for <netmod@ietfa.amsl.com>; Mon, 20 Jul 2015 10:42:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0DE1B2A1C for <netmod@ietf.org>; Mon, 20 Jul 2015 10:42:50 -0700 (PDT)
Received: from [IPv6:2001:67c:370:176:34c3:d2ae:b281:6803] (unknown [IPv6:2001:67c:370:176:34c3:d2ae:b281:6803]) by mail.nic.cz (Postfix) with ESMTPSA id 33990180E5E; Mon, 20 Jul 2015 19:42:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437414169; bh=mOk5e1XhxAPReRMf0M/PbrlSqUzIW5N6U3fhJ6NUWPU=; h=From:Date:To; b=Z2zGkqnEX7oYv5WHYrQqrv1IALAK9QGkEZQ7Jc8ajpn0nIZzfSilE8tXReLEGzcFX RjnoW2vqFN6hXcnGJZrtuBWuD9IbXG0LPtHTYeeiEo1zWmUnRdqJKhXOKL6Op0nN4h SgHlURo5c7wUdP+faLYfqqv8DNTs40yjTaS7YrTA=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHRS-JF8UK+9fQ=yvZy9ttcj3j6oJn0n3Co6f7kB0tpFgA@mail.gmail.com>
Date: Mon, 20 Jul 2015 19:42:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F990644A-4CBE-43D5-AB2B-A20E54A91A65@nic.cz>
References: <m2d1zn0zhm.fsf@dhcp-hotel-wired-13-fe.meeting.ietf.org> <D0153452-D5F5-4E3C-B3D7-7003ACC405EA@nic.cz> <CABCOCHSqbZfKRqGjT1rsphRnw0tYdR3uT=mFvTvJYXMwL3N2uw@mail.gmail.com> <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <CABCOCHRoA9-BP7=OvUGdvXNuowPUty4xy6iai6Q6dVOjD5iGbQ@mail.gmail.com> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <CABCOCHRS-JF8UK+9fQ=yvZy9ttcj3j6oJn0n3Co6f7kB0tpFgA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.2102)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/6dZX2Q6nk2O5wChDMle4Ahl_O2o>
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Y34
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 17:42:52 -0000
> On 20 Jul 2015, at 19:29, Andy Bierman <andy@yumaworks.com> wrote: > > > > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote: > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > > > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> 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 <lhotka@nic.cz> wrote: > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz> 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 > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Acee Lindem (acee)
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Acee Lindem (acee)
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Jonathan Hansford
- Re: [netmod] Y34 - root node Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Acee Lindem (acee)
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Acee Lindem (acee)
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Juergen Schoenwaelder
- Re: [netmod] Y34 - root node Kent Watsen
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Eric Voit (evoit)
- Re: [netmod] Y34 - root node Nadeau Thomas
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Alexander Clemm (alex)
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Juergen Schoenwaelder
- Re: [netmod] Y34 - root node Lou Berger
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Lou Berger
- Re: [netmod] Y34 - root node Ambika Prasad Tripathy (ambtripa)
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Alexander Clemm (alex)
- Re: [netmod] Y34 Robert Varga
- Re: [netmod] Y34 Robert Varga
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Robert Varga