Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
Ladislav Lhotka <lhotka@nic.cz> Fri, 02 September 2016 08:35 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDCF12D78D for <netmod@ietfa.amsl.com>; Fri, 2 Sep 2016 01:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level:
X-Spam-Status: No, score=-7.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 v4ukO50dHkXa for <netmod@ietfa.amsl.com>; Fri, 2 Sep 2016 01:35:39 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB0912D518 for <netmod@ietf.org>; Fri, 2 Sep 2016 01:35:39 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id ADBBF6177E; Fri, 2 Sep 2016 10:35:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472805336; bh=aWdsb+JdmuGKnODgoLYaBEeeOtzD4MvnkZuYXuSny3s=; h=From:Date:To; b=OSM8ntzRcMdc/7WkMZNdfy8Iu2a8ZqVcC/80N8B0jRQ/CJCCyRSLe+TzSjte8FAoT Qjuebg6pmFTXI27dA2CPriaaZBYH98ZCjoxTVzqply39jT3c+1nVFhhZaT8T/1aa6f IBXw/nwwMNGf8m4MvX1LxMLJ/LTaSE4J1/UlZZgE=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <4110_1472804197_57C93565_4110_1509_1_9E32478DFA9976438E7A22F69B08FF921BD66D91@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Date: Fri, 02 Sep 2016 10:35:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <699C9AEE-6AB8-4B60-B1BC-E4D93B733E6A@nic.cz>
References: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net> <4CF2F47E-ABF2-4368-8793-64E81AA02375@juniper.net> <20160831184040.GA4834@elstar.local> <4110_1472804197_57C93565_4110_1509_1_9E32478DFA9976438E7A22F69B08FF921BD66D91@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZqGDw4prjo1uhvFJIttiguIZxoY>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 02 Sep 2016 08:35:41 -0000
Hi Stephane, if we do any changes to the core routing module, then I am afraid all modules that depend on it will have to follow suit. In particular, if we put config and state data into separate modules, protocol modules should do the same. I don't like the idea of putting the core routing model and all work that depends on it on hold until we reach a decision regarding opstate. So, *if* the separation of config and state data gives a reasonable guarantee that at least the config part will be compatible with the ultimate opstate solution (whatever it is), it IMO makes sense to do it. But I am not even sure that the premise holds. Lada > On 02 Sep 2016, at 10:16, <stephane.litkowski@orange.com> <stephane.litkowski@orange.com> wrote: > > Hi, > > As this model is a base for multiple routing modules, it would be good to align the op-state modeling between this model and the existing routing related modules (so we can also close the work on multiple routing yang models). > So if core routing model uses foo:/foo foo:/foo-state, do we keep this modeling also for our protocol models and close the work ? > > Best Regards, > > Stephane > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, August 31, 2016 20:41 > To: Kent Watsen > Cc: netmod@ietf.org > Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016) > > On Wed, Aug 31, 2016 at 06:11:14PM +0000, Kent Watsen wrote: >> [as a contributor] >> >> My only comment on this draft is that I’d prefer it if the “routing-state” tree were moved into another YANG module, so that it could be more easily deprecated when the opstate solution comes. I suggested this before, with regards to rfc6087bis Section 5.23, but that thread seemed to have petered out, but now here we are and my opinion remains the same. >> > > We already have foo:/foo /foo:foo-state modules and while we can now start a series of foo:/foo and foo-state:/foo-state modules in the hope that this will eventually 'easier' in the future, it might also be that we just create more variation and confusion. > > /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 > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [netmod] WG Last Call for draft-ietf-netmod-routi… Kent Watsen
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Kent Watsen
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Juergen Schoenwaelder
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Ladislav Lhotka
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… stephane.litkowski
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Ladislav Lhotka
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Kent Watsen
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Kent Watsen
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Ladislav Lhotka
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Rob Shakir
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Ladislav Lhotka
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Kent Watsen
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Ladislav Lhotka
- Re: [netmod] WG Last Call for draft-ietf-netmod-r… Kent Watsen