Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

Andy Bierman <andy@yumaworks.com> Wed, 26 August 2015 13:34 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1F1A8AC9 for <rtgwg@ietfa.amsl.com>; Wed, 26 Aug 2015 06:34:19 -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 lY9jci-Y-XOv for <rtgwg@ietfa.amsl.com>; Wed, 26 Aug 2015 06:34:17 -0700 (PDT)
Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 BFF7F1AC39A for <rtgwg@ietf.org>; Wed, 26 Aug 2015 06:34:13 -0700 (PDT)
Received: by labns7 with SMTP id ns7so1786986lab.0 for <rtgwg@ietf.org>; Wed, 26 Aug 2015 06:34:12 -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=w/7Pp9YhY7VToeQHCl19XUlZzRE9vM3Y5SeO/nSNSZ8=; b=P5XH7Ef9h6chGSFhRqwvjtKIizr6yQ7mTqPHv66vNOVm8nHQlfjy8uznwEhy/yVukP w9e1iVWzWsjOL+SEWCPSbQSrdSz+T8vXmBU2qGJ/U8En6Lc6a3ozDHPFRYbs3P2JmF4x zgoLe1tkKHBrv2MJdqN/sNXHaH7+BFl+wjHbmNViEb+EoTkImrXtmq46H4GjHuw7dJtu Vr0hz0Ib1coRFpSA9FTjX1tJap766IyZ9PCwTOAENk3WePYODR3XPlf2bFv0MddlUOh7 HERQvim2rViQThbPU0/gBxdyEYvccV0oTCzeEAmmLKPPXeI1OTQQUhKsCl5S6ARTuEC9 zicQ==
X-Gm-Message-State: ALoCoQmbLNZu/aI+b6WgeERpGmluxzUEQ2CIbLxcTkv5JuQrtM09/sxgxwCiB8znjG7RtFcKzN7L
MIME-Version: 1.0
X-Received: by 10.112.154.106 with SMTP id vn10mr30814020lbb.38.1440596052202; Wed, 26 Aug 2015 06:34:12 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 26 Aug 2015 06:34:11 -0700 (PDT)
In-Reply-To: <7E4038FA-F930-448A-9C65-C82C39E4825B@lucidvision.com>
References: <20150826064030.GB84416@elstar.local> <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> <20150826.135823.2123307386758409523.mbj@tail-f.com> <7E4038FA-F930-448A-9C65-C82C39E4825B@lucidvision.com>
Date: Wed, 26 Aug 2015 06:34:11 -0700
Message-ID: <CABCOCHTqBYiiC419MxAOPQDHsP=i29RMNPMd0qCWpR9MyjbGZA@mail.gmail.com>
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
From: Andy Bierman <andy@yumaworks.com>
To: Nadeau Thomas <tnadeau@lucidvision.com>
Content-Type: multipart/alternative; boundary="089e0122af2af4f166051e36e721"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/ASDYRgmOysVncg7xZ10eawNqeUQ>
Cc: Martin Bjorklund <mbj@tail-f.com>, draft-rtgyangdt-rtgwg-device-model@ietf.org, "netmod@ietf.org" <netmod@ietf.org>, Routing WG <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2015 13:34:19 -0000

On Wed, Aug 26, 2015 at 6:17 AM, Nadeau Thomas <tnadeau@lucidvision.com>
wrote:

>
> > On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> >
> > Nadeau Thomas <tnadeau@lucidvision.com> wrote:
> >>      [Speaking for myself]
> >>
> >>      Is the resistance to this proposal because of the actual changes to
> >>      structure, or is it a resistance to churn/change?
> >
> > The former.  IMO this is technically not a good proposal, as I have
> > tried to explain several times.
> >
> >>      And if we solved the
> >>      latter by say relaxing the rules around how we progress models to
> PS,
> >>      would this alleviate the concerns for the former?  The meta
> question I
> >>      will ask is: is the existing RFC process adequate/sufficient for
> us to
> >>      move forward on such a large scale with Yang models at the IETF?
> >>      Other organizations currently iterate on models using certain
> revision
> >>      conventions (that are consistent with the rules we put out here)
> yet
> >>      produce multiple versions of the same model within the same year.
> As
> >>      a matter of fact, multiple versions are allowed to coexist within a
> >>      single implementation.  In stark contrast, the M.O. at the IETF has
> >>      been to treat Yang models much like we did SNMP MIBs (or any other
> >>      document here) thereby assuming that once it becomes an RFC, that
> it
> >>      is largely set in concrete for many years to come.
> >
> > In this specific case the change is cosmetic but has disastrous
> > effects on other standard modules, other vendor-specific modules,
> > existing server code and existing client code.  I think people expect
> > IETF standards to be a bit more stable than that.
> >
> >
> > /martin
>
>         Therein lies the salient part of question I am asking: is this
> really
> the case these days?  The operators seem to be providing an answer that
> contradicts
> this age-old assumption. Other projects like ODL are too.  Both have real
> deployments too - these reference points are not science projects. I think
> its
> fair to bring this specific issue out in the open here to discuss because
> its
> a real issue we need to solve not just here in NETMOD, but at the IETF
> in general.
>
>

YANG modules are not relocatable.
The issue should be really clear to anybody who has to support product
in the field.  If you make this change, the existing products stop working.
It doesn't matter if you move the YANG objects a little or a lot.

Since the proposed change ( / to /device ) adds no value whatsoever
to a programmatic interface, the product in the field will be broken
for no real reason.

If vendors are expected to move all their YANG objects into some
uber-tree that the IETF owns, then the disruption is total.

I agree the NETMOD WG should think carefully about this change
before agreeing to it, but it is the equipment vendors who will
pay for it.



>         —Tom
>
>
Andy


>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>