Re: [Netconf] health of NETCONF

Andy Bierman <andy@yumaworks.com> Wed, 01 March 2017 15:39 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBA9129594 for <netconf@ietfa.amsl.com>; Wed, 1 Mar 2017 07:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 QNFxJngE93Pm for <netconf@ietfa.amsl.com>; Wed, 1 Mar 2017 07:39:50 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 2E012129584 for <netconf@ietf.org>; Wed, 1 Mar 2017 07:39:50 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id v186so113403146wmd.0 for <netconf@ietf.org>; Wed, 01 Mar 2017 07:39:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eWITL0tj4F51frsAn0aQJzagfGdywV28+SgGLjPNOdo=; b=Y6pv5l3jx4PA8XvvnAnUa9BO9DsglMAkxHvH+sVkc2w+DM4yZUxzJGbhcJftdOe/ko fMu3Cs4b9ABNvbXl1kWshGl8dtMTxKAX5bUJkVYmsg5V2X5I6qZjHVDoXNs3kgGcPxOX /+Jpo6xGacUiz+m/QXpq2SzYiibZdFY7poSs2WAgXTXXPe6I/4/XA1AU/csERJfoUuX3 LPou71c53jGH2DQUuW0074H3wu/ezI138aXr35544Zopq2axIXdz9ZTDytjvQNxd9Z7F PgAO5EDgGh+EhODeASdBvWlalmUFwHfd0LMODzeJH/o4Uc9DF16HhWQu85iuNVuqFQ9P yrAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eWITL0tj4F51frsAn0aQJzagfGdywV28+SgGLjPNOdo=; b=QxDSo8rSZl+W8AbJFDLssWkOU5pBvx9x3vvnGxk4R+rxw5YQvVI2FUmr5H5FxulG25 1Mts6aIBalu3oHXEpYv5DvAntEFSS9DnwZAhUIg3JN33nJx1TlDuVAxmVYdz5JSyMkID s9EOMuQ9iaDf+BL/wpvLMK+m9PG2iNnzKYUttSZdzGreguqksb7Q/thb3bECKoijlwHC bh3FqeM+rpOhy/j+8DJvLImnEdvwPxJGIJVxylWyQCmwKFWmSo21JH2cpqNsMBWgUUTT amWI49Yzw4b6FfTl3CLCIJykasPM8J8loKBxaF34dAwYZypl/TB7dgX+UTO0gyw73Rki Wm5w==
X-Gm-Message-State: AMke39mPGmR142Pk6dBDlKLoTwlrHg2Nh40pC0690ZjTdT812p3SVkVysO6krzNCtbJrPojedf4npaIM+JLuwA==
X-Received: by 10.28.214.144 with SMTP id n138mr3806224wmg.136.1488382788614; Wed, 01 Mar 2017 07:39:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.165.154 with HTTP; Wed, 1 Mar 2017 07:39:47 -0800 (PST)
In-Reply-To: <05ec01d2927b$a7e374a0$4001a8c0@gateway.2wire.net>
References: <014101d2913a$3db72870$b9257950$@gmail.com> <20170227221434.GB68878@elstar.local> <026f01d29273$5d57dfa0$4001a8c0@gateway.2wire.net> <5e19057c-1b77-e6e3-bf30-8acf36e279d9@cisco.com> <05ec01d2927b$a7e374a0$4001a8c0@gateway.2wire.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 01 Mar 2017 07:39:47 -0800
Message-ID: <CABCOCHTJw+bGfE_spO5MG9ZmG4egcp4-1qD+MpdJCg=_XG-O3w@mail.gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Content-Type: multipart/alternative; boundary="001a113fb18a67dfb80549ad1f17"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Z3pALxqK9W91rl9TbjNPd7GSaxs>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] health of NETCONF
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2017 15:39:52 -0000

On Wed, Mar 1, 2017 at 3:04 AM, t.petch <ietfc@btconnect.com> wrote:

> From: "Robert Wilton" <rwilton@cisco.com>
> Sent: Wednesday, March 01, 2017 10:45 AM
> > Hi Tom,
> >
> > On 01/03/2017 09:58, t.petch wrote:
> > > ----- Original Message -----
> > > From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de
> > > Sent: Monday, February 27, 2017 10:14 PM
> > >> On Mon, Feb 27, 2017 at 09:44:06PM +0100, Mehmet Ersue wrote:
> > >>
> > >>> 6. Revise the current NETCONF datastore concept as a protocol- and
> > > modeling
> > >>> language-independent standard as part of the network configuration
> > >>> framework. Use the datastore solution proposal in
> > >>> draft-ietf-netmod-revised-datastores as its basis. Will be used as
> a
> > >>> normative reference in protocol specifications.
> > >> There is no point in dupliating work in WGs that have a common
> history
> > >> and a common set of active contributors.
> > > Juergen
> > >
> > > I am not sure what you are proposing;  Currently, datastores are
> poorly
> > > described in RFC6241 and RFC7950 and the publication of another
> > > incomplete description in the shape of
> > > draft-ietf-netmod-revised-datastores
> > > will likely make things worse.
> > >
> > > I see a need for a datastores RFC, probably separate from the
> current
> > > specifications, and do see the NETCONF WG as better placed to do it.
> >
> > I see that datastores and YANG are directly linked.  Specifically, I
> > think that the "config" statement, and any future I2RS related
> > "ephemeral" statement (or extension) give the data nodes in a YANG
> data
> > model particular semantics in the different datastores.
> >
> > So, I sort of see the document hierarchy should be something like:
> >
> >     Datastores architecture
> >              ^
> >              |                    (NETMOD WG)
> >         YANG language
> >         ^          ^
> >         |          |
> >         |   Encodings of YANG data trees
> >         |               (XML, JSON, CBOR)
> >         |                    ^
> >    -  - |-  -  -  -  -  -  - |-  -  -  -  -  -
> >         |                    |    (NETCONF WG)
> >      Common protocol abstraction
> > (that all YANG protocols should conform to).
> >      ^             ^            ^
> >      |             |            |
> >   RESTCONF      NETCONF        CoMI
> >
> > So, for the split of work between NETMOD and NETCONF, my thoughts are
> > that basically the work above the dotted line should be done in
> NETMOD,
> > and the work below the line should be done in NETCONF.  Of course,
> some
> > of the work may be done in other WGs (CoMI, I2RS, etc).
> >
> > >
> > > I think that the rush to  get
> > > draft-ietf-netmod-revised-datastores
> > > out is militating against the long term health of NETCONF.
> >
> > Please can you clarify, do you mean long term health of the NETCONF
> WG,
> > or the NETCONF RFC, or the NETCONF protocol?
>
> I mean NETCONF the means of doing network configuration, so that
> includes the protocol as defined in RFC6241, datastores as defined in
> RFC6241 and the existence of a data modelling language and data models
> written therein.  Essentially, the problem that the NETCONF WG was set
> up to solve.
>

I think this is getting done.


>
> The weakness I see is the lack of a Standards Track architecture or
> framework or some such which would likely have datastores at its heart;
> and, unlike you, I see the expertise for that in the NETCONF WG and not
> in the NETMOD WG.
>
>
If you mean an update to RFC 6244 would be useful, then I agree



> Tom Petch
>


Andy


>
> > Thanks,
> > Rob
> >
> >
> > >
> > > Tom Petch
> > >
> > >> /js
> > >>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>