Re: [netmod] Y34
Lou Berger <lberger@labn.net> Mon, 27 July 2015 00:51 UTC
Return-Path: <lberger@labn.net>
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 CE60E1A8AC8 for <netmod@ietfa.amsl.com>; Sun, 26 Jul 2015 17:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ziY_DeA1yA7D for <netmod@ietfa.amsl.com>; Sun, 26 Jul 2015 17:51:13 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id E55031A8AE3 for <netmod@ietf.org>; Sun, 26 Jul 2015 17:51:12 -0700 (PDT)
Received: (qmail 21666 invoked by uid 0); 27 Jul 2015 00:51:10 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 27 Jul 2015 00:51:10 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id xJX21q00R2SSUrH01JX5Xe; Mon, 27 Jul 2015 00:31:10 -0600
X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=iEhmfDb7q88A:10 a=-NfooI8aBGcA:10 a=vQEP83iCr2YA:10 a=zOBTXjUuO1YA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=xskcdSivAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=Yx1QUpVTdxQn7yjD8d4A:9 a=r2jBWgr86mXuoFFh:21 a=Fd06OBNT_8VVjzpo:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=6k9Ilfv6AqDcV5tVJLAA:9 a=ycAKzIVwgTpvFgKL:21 a=btN7zV2LdX08VH87:21 a=a4aXaKcMd8q79A7V:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=izpoXznO5Kirv/tsgmHVdv6i5YvOuLCR6yeNOYryTRg=; b=YbmjggY0xMQT7P5etRqBQgb4048NYqwpVPGRDvovSe0ll7JpjBAKyPi7IBSifiOXjbOe5L0lePZ1QE07zD7JM2frzaI3llk1iCo+kbTP54DZmEOO63l7Fm6f2fO8r2vc;
Received: from [172.56.37.4] (port=26572 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from <lberger@labn.net>) id 1ZJWJq-0000NM-MN; Sun, 26 Jul 2015 18:31:03 -0600
From: Lou Berger <lberger@labn.net>
To: Andy Bierman <andy@yumaworks.com>, "Acee Lindem (acee)" <acee@cisco.com>
Date: Sun, 26 Jul 2015 20:31:01 -0400
Message-ID: <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <CABCOCHSm=VCMqoMJRAstV-FwZqkitKVoAjkVMGHxKcKB_RdpGQ@mail.gmail.com>
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> <F990644A-4CBE-43D5-AB2B-A20E54A91A65@nic.cz> <20150720210041.GA17614@elstar.local> <D1D917F8.29821%acee@cisco.com> <CABCOCHSm=VCMqoMJRAstV-FwZqkitKVoAjkVMGHxKcKB_RdpGQ@mail.gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------14ecceb7beb5e16281843597be8"
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.37.4 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ozzcNimxh_Nhqhv4l4BMoPddHWA>
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, 27 Jul 2015 00:51:17 -0000
Andy, Have you thought through implications / possibilities for existing models, e.g., interfaces? Thanks, Lou On July 26, 2015 4:41:32 PM Andy Bierman <andy@yumaworks.com> wrote: > Hi Acee, > > I agree that "Relocatable YANG" would be very useful, and have been > thinking about the problem for awhile. I think the key is to precisely > define a protocol-independent document root for each of the various > YANG XPath contexts. In most cases the expression can be > automatically relocated to an ancestor root. For the rest, a > YANG mechanism is needed to tell the compiler to force evaluation > on the old docroot (not the new docroot ancestor). > > > Andy > > > On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) <acee@cisco.com> wrote: > > > I think being able to place a given model anywhere in the device tree > > would be useful and this would allow a model to be rooted in different > > locations on different devices. Similarly, we’d need the ability to prefix > > XPATH references to data nodes in the model with the root. > > Thanks, > > Acee > > > > On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > > <netmod-bounces@ietf.org on behalf of > > j.schoenwaelder@jacobs-university.de> wrote: > > > > >Lada, > > > > > >Y34 is closed and I have not seen any new argument here that indicates > > >we made a major mistake with the resolution of Y34. As such, Y34 > > >remains closed. > > > > > >If you want to discuss new ideas to relocate or "symlink" data models, > > >please do so in a separate thread. (And no, we do not accept new > > >issues for YANG 1.1 either at this point in time.) > > > > > >/js > > > > > >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > > >> > > >> > 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 mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > >-- > > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > >Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > > >_______________________________________________ > > >netmod mailing list > > >netmod@ietf.org > > >https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > ---------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- [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