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

Andy Bierman <andy@yumaworks.com> Wed, 26 August 2015 13:54 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 A4C641B2A58 for <rtgwg@ietfa.amsl.com>; Wed, 26 Aug 2015 06:54:49 -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=unavailable
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 3Xjdyryu-CuN for <rtgwg@ietfa.amsl.com>; Wed, 26 Aug 2015 06:54:41 -0700 (PDT)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 4BD3C1B2A24 for <rtgwg@ietf.org>; Wed, 26 Aug 2015 06:54:41 -0700 (PDT)
Received: by lbbtg9 with SMTP id tg9so120878316lbb.1 for <rtgwg@ietf.org>; Wed, 26 Aug 2015 06:54:39 -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=wSQBBqsbXBM9PGUi4J1Gh2cUSCEo4MTevJZIt3MWIFw=; b=ZTFfYtw6ORNADgNysMntb43X+Mb92FjtXZ2DGvWc13SV9mTn241gNpJTtCHmMaH90X aVelVwlZo0HL7WR9HJLf+KcD8y10pVy1g1gkEakkJ/6vHsvjuugAkjKuntPU6YN3S/pF J6hownK10y9LJswqyTQCVzuD0bNhBRgBKI6N4Bh4drX0qNCN8rUOMG8LcgORJ88ikV/8 wQVtLyq+wurCC41V2ER9LHG7kcFwoSDwvBHtrcX8+Q5VMv+5nCQunRvPz449pD0BSXfc 5sqhBNHpwXEHn8MhOcF71LIjsq+xtGy5HS6h6jwTRtRVIys/1MinuC4Epgy1DkImCdU8 kNoQ==
X-Gm-Message-State: ALoCoQnxy33MrT/w3/z6ynrYt9k6ZKSkhgTMShq/nEgdBnBbxguY6e2q8YUN02SH+kJ2tFfgEz86
MIME-Version: 1.0
X-Received: by 10.112.85.3 with SMTP id d3mr30654632lbz.33.1440597279803; Wed, 26 Aug 2015 06:54:39 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 26 Aug 2015 06:54:39 -0700 (PDT)
In-Reply-To: <ED14E3B4-450F-4E33-A786-8767E55C7002@lucidvision.com>
References: <D203014F.2CA9C%acee@cisco.com> <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> <D203327E.2CAE1%acee@cisco.com> <ED14E3B4-450F-4E33-A786-8767E55C7002@lucidvision.com>
Date: Wed, 26 Aug 2015 06:54:39 -0700
Message-ID: <CABCOCHSxEwjuiU8PSJ9hyN_OxsdD1Xvu8-1BCL21G5rv=8NdtQ@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=001a1134946c20a483051e373159
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/cKs6z7j8ukPP-3qn9O2fR9LopXM>
Cc: "draft-rtgyangdt-rtgwg-device-model@ietf.org" <draft-rtgyangdt-rtgwg-device-model@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "rtgwg@ietf.org" <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:54:49 -0000

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

>
> > On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) <acee@cisco.com>;
> wrote:
> >
> >
> >
> > On 8/26/15, 8:09 AM, "Martin Bjorklund" <mbj@tail-f.com>; wrote:
> >
> >> Nadeau Thomas <tnadeau@lucidvision.com>; wrote:
> >>>
> >>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund <mbj@tail-f.com
> >
> >>>> wrote:
> >>>>
> >>>> "Acee Lindem (acee)" <acee@cisco.com>; wrote:
> >>>>>
> >>>>>
> >>>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder"
> >>>>> <j.schoenwaelder@jacobs-university.de>; wrote:
> >>>>>
> >>>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote:
> >>>>>>
> >>>>>>>> Hopefully, a decision to change all existing models (including
> >>> vendor
> >>>>>>>> models!) will be based on something more technical than the fact
> >>> that
> >>>>>>>> a group of people "really like it" some other way.
> >>>>>>>
> >>>>>>> I'm equally unsure that having an argument of "I got there first"
> >>> is a
> >>>>>>> compelling argument given the number of folks (including vendors)
> >>> who
> >>>>>>> have stated willingness (or even support) for change.  I think
> >>> having
> >>>>>>> a
> >>>>>>> major class of users stand up and say this is important should
> >>> garner
> >>>>>>> some notice.
> >>>>>>
> >>>>>> Please keep in mind that we are talking about several published
> >>>>>> proposed standards that have been implemented and deployed. I think
> >>>>>> there must be convincing technical reasons to declare them broken
> >>> and
> >>>>>> to redo them.
> >>>>>
> >>>>> Other than adding /device at the top, we are not obsoleting RFC
> >>>>> 7223.
> >>>>
>



This shows a rather diminished understanding of how YANG works.
YANG defines data at a specified location /some/path/from/root.
Protocols like HTTP can deal with moved resources (e.g., 301).




> >>>> This doesn't make sense.  The YANG model is the contract.  You are
> >>>> proposing changing the contract.  The fact is that you will be
> >>>> obsoleting 7223 (and the other RFCs).  Existing devices and
> >>>> applications will have to change in order to handle this new top-level
> >>>> node (which will be in some other namespace I presume, unless your
> >>>> proposal is one gigantic monolithic model).
> >>>>
> >>>>
> >>>> /martin
> >>>
> >>>     Again I will ask: why is this bad?
> >>
> >> My point above was in reply to the statement that "we are not
> >> obsoleting RFC 7223" [because the change is so small?] - you would in
> >> fact be obsoleting the model in 7223.
> >
> > There have been other mechanisms discussed to relocate YANG models.
> > Perhaps, one of these could be employed in lieu of obsoleting the
> existing
> > models.
> >
> > Thanks,
> > Acee
>
>         This is exactly what I want to get on the table.  If we can agree
> on a mechanism/s to do relocate modules, then this might alleviate the
> resistance to evolve models. The current issue aside, if you step back and
> look
> at the wider IETF situation around all the Yang models being created and
> are RFCs, and the dependency graph that is created. You can then
> imagine a time after that point when others come along that evolve
> parts or entire modules.  We currently refer to this as “obsoleting”
> all of the modules that it depends on, which is a very big problem using
> the current RFC process.  Not only does it require a revision of all those
> RFCs (due to obsoleting the previous ones) - and thus all the
> procedural/management
> overhead that will incur - but the time lag from start to finish. And
> this might happen for any new module. This is not scaleable going forward.
>
>
So we would just need to retrofit all the clients and servers with
complicated
code to relocate YANG modules and adjust all the validation tests?

Another approach is to not rely so heavily on one giant uber-tree
that MUST be correct on the first try and never change.
Resource directories and other flexible approaches have been developed
for this purpose.



>         —Tom
>
>
>
Andy


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