Re: [netmod] Y34

Andy Bierman <andy@yumaworks.com> Sat, 01 August 2015 18:05 UTC

Return-Path: <andy@yumaworks.com>
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 47F691A0277 for <netmod@ietfa.amsl.com>; Sat, 1 Aug 2015 11:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 TEhvJQzQtlGu for <netmod@ietfa.amsl.com>; Sat, 1 Aug 2015 11:05:53 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F831A026F for <netmod@ietf.org>; Sat, 1 Aug 2015 11:05:52 -0700 (PDT)
Received: by lbbyj8 with SMTP id yj8so61412110lbb.0 for <netmod@ietf.org>; Sat, 01 Aug 2015 11:05:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tMWJxFozUYd+m8p78d21r4zyj50QB3jHfJHGFFVFGKY=; b=C59eK5iE8iSINa6+TrTdkNaIe1vn4jPTo2PmfG078naMvF+rO5g8E9oTPCvT79Q4H5 5PA5ECXVcTOx9IvGTELNg+Ir4JhxqYoE2HbPT/L0a6xXo9nboHYWA1PNWrKCQwX4T0fj b7PSEUPuPz9a6vxYxhAOAV7uoTPeIVP8pibfY8ntNW2h0UvEDO02Ii+g1JHgWPLh6Ffy gSpiXWp5GFAq4rF8HywJXdWHKOTLP4HfiHqZXRu23dGijGQU4R+89YXvMHJr5nGMnzbT lFwbP3ecjCvhHEvcXRQB/G6Xco40aMRjZnztfQrQTYDpKiqYu9cQFDk7zBJR8arHqxf6 cOqw==
X-Gm-Message-State: ALoCoQkwzXen864P8WWeEVVcjDaCKlm/20vFaDSRmThA9VPDlWW8oTsMs8TNTa4FPqKvV18SKTyU
MIME-Version: 1.0
X-Received: by 10.152.7.65 with SMTP id h1mr9193479laa.33.1438452350759; Sat, 01 Aug 2015 11:05:50 -0700 (PDT)
Received: by 10.112.200.102 with HTTP; Sat, 1 Aug 2015 11:05:50 -0700 (PDT)
In-Reply-To: <D1E270C7.29F82%acee@cisco.com>
References: <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> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CABCOCHQ-XOJMXfZfijd1OJcgvx4wkRuY0P7UhF5zej_Q36GHYg@mail.gmail.com> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CABCOCHQAc310ZwScEN=BFEzHUj3uY3HBQjo131J6yigGEW9Yrw@mail.gmail.com> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <D1E270C7.29F82%acee@cisco.com>
Date: Sat, 01 Aug 2015 11:05:50 -0700
Message-ID: <CABCOCHSPmCdd2eeb6S9sPzjD+G7vrCs+HNac5KDj3QHUuGMofQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c27cf064cffb051c43c9ff"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/RqrK6b8quLtEcEPg54dwL18BN_M>
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: Sat, 01 Aug 2015 18:05:55 -0000

On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Juergen,
>
> On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder"
> <netmod-bounces@ietf.org on behalf of
> j.schoenwaelder@jacobs-university.de> wrote:
>
> >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote:
> >> Andy,
> >>
> >> On 07/27/2015 12:58 PM, Andy Bierman wrote:
> >> > Hi,
> >> >
> >> > I don't think a standard for relocating subtrees would be worth it.
> >> > I am not in favor of moving /interfaces or /system to a new location.
> >> > That's not how YANG works. It only allows "obsolete and start over".
> >> >
> >> > I would suggest pursuing solutions that don't cause
> >> > as much disruption and expense as possible.
> >> >
> >>
> >> I think it would be really good to explore other, less "disruptive"
> >> options.
> >>
> >
> >I think the first step is to find out whether there is a problem worth
> >to be fixed. Why are the RFCs in question broken? (Yes, I have read
> >the openconfig IDs,
>
> Section 1.1 in
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
> lists the goals of a generic model structure that will accommodate most
> modern network devices. I guess you don’t agree that these are desirable?
>
>

The only objection I have to this draft is the insertion of a top-level root
called "device".  (Might as well be called "self").
There are no sibling nodes planned or intended for
this node, so it serves as an extra document root.

The well-specified XPath and YANG root (/) can be
accessed by all protocol operations, exactly the same
as a node called 'device'.  The actual node name will
depend on the RPC function (e.g. 'data' or 'config').

This is more than redundant however.  It introduces a "super-module"
into YANG that every other module is expected to augment.
YANG is intended to be more loosely coupled than that.
This introduces an extra node and namespace declaration
in all protocol messages, increasing message sizes.

It also assumes all existing YANG models will get rewritten to
account for "/device" in all path and XPath expressions.
This is highly disruptive to existing deployments.
Also, multiple data models to edit the same thing causes lots
of extra complexity in the server (supporting both old
location and new location).

IMO a resource directory approach is much more realistic.
The /device tree can contain all the organized NP containers.
Instead of all the actual data nodes, this tree just has pointers
to the real location of the resource. (like 301 Moved Permanently)




Thanks,
> Acee
>
>
>
Andy


>
> >I listened to the virtual interim meetings, I
> >assume you have read draft-bjorklund-netmod-openconfig-reply.)
>
>
>
> >
> >Lets get the core of the openconfig argument on the table why the
> >existing RFCs are flawed.
> >
> >/js
> >
> >--
> >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
>