Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

Ladislav Lhotka <lhotka@nic.cz> Tue, 19 September 2017 13:37 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 8F987134324 for <netmod@ietfa.amsl.com>; Tue, 19 Sep 2017 06:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8tQke2Nbzo1J for <netmod@ietfa.amsl.com>; Tue, 19 Sep 2017 06:37:22 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF2134225 for <netmod@ietf.org>; Tue, 19 Sep 2017 06:37:18 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 981561820E76; Tue, 19 Sep 2017 15:36:50 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 6C3571820E71; Tue, 19 Sep 2017 15:36:48 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
In-Reply-To: <20170919.115915.1668734288988659917.mbj@tail-f.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
Date: Tue, 19 Sep 2017 15:37:53 +0200
Message-ID: <87shfistam.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EkfXkgd-JEMJ7sy8sSVDnAHQA1E>
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 19 Sep 2017 13:37:24 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
>> Hi,
>> 
>> I support the adoption but I propose two conceptual changes:
>> 
>> 1. Introduce a new module name and namespace so that it is not
>> necessary to carry along the deprecated baggage. If readability is
>> the primary concern, this is IMO the way to go. Instead of
>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>> 
>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>> to be used 
>> in areas where NMDA is an overkill, such as open source home
>> routers.
>
> Why wouldn't NMDA be appropriate in an open source home router?  Note
> that the new model really just have a single tree instead of two
> trees, so the data that needs to be instrumented is more or less the
> same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

>
> In fact, if we claim that the new architecture is not appropriate for
> some devices I think we have failed, especially if the conclusion is
> that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

Lada

>
>
> /martin
>
>
>
>
>
>
>> NMDA
>> implementors should be aware of the new modules but there is no need to
>> eradicate the old data models.
>> 
>> #2 applies also to other modules for which the NMDA version is underway.
>> 
>> Lada
>> 
>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>  
>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>> > All,
>> > 
>> > This is start of a two week poll on making
>> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>> > send email to the list indicating "yes/support" or "no/do not support".
>> > If indicating no, please state your reservations with the document.  If
>> > yes, please also feel free to provide comments you'd like to see
>> > addressed once the document is a WG document.
>> > 
>> > The poll ends Oct 2.
>> > 
>> > Thanks,
>> > 
>> > Lou (and Kent)
>> > 
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67