IETF Logo Mail Archive

Re: [netmod] Augmenting an unimplemented module

Martin Bjorklund <mbj@tail-f.com> Wed, 08 February 2017 20:34 UTC

Return-Path: <mbj@tail-f.com>
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 B236A129E8D for <netmod@ietfa.amsl.com>; Wed, 8 Feb 2017 12:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Z2nLAm0oifAt for <netmod@ietfa.amsl.com>; Wed, 8 Feb 2017 12:34:31 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82E02129E69 for <netmod@ietf.org>; Wed, 8 Feb 2017 12:34:31 -0800 (PST)
Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 6CD271AE0476; Wed, 8 Feb 2017 21:34:30 +0100 (CET)
Date: Wed, 08 Feb 2017 21:34:30 +0100
Message-Id: <20170208.213430.967442394732720779.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20170208202923.GA99261@elstar.local>
References: <15a1e579a30.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <87wpd0h7au.fsf@chopps.org> <20170208202923.GA99261@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/E3Dm-l-tL6Sa-giRw_r-ggrY9Pg>
Cc: netmod@ietf.org
Subject: Re: [netmod] Augmenting an unimplemented module
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: Wed, 08 Feb 2017 20:34:32 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote:
> > 
> > Lou Berger <lberger@labn.net> writes:
> > 
> > > On February 8, 2017 10:16:14 AM Juergen Schoenwaelder
> > > <j.schoenwaelder@jacobs-university.de> wrote:
> > > ...
> > >>
> > >> We should perhaps start a separate thread but I fail to see why tags
> > >> require new editing primitives.
> > >
> > > It was an intentional design choice/preference by one of the authors.
> > > Basically, Chris thought it was easier from a client perspective.  He's the
> > > user, so he won:-)
> > 
> > The tags in the library and the tags in a module are updated at the same
> > time and represent logically the same list of tags. Its clear this
> > happens with an RPC. It seems a lot less clear this would (or should)
> > happen if one edited only once location.
> > 
> 
> I am not convinced by the design. We have lots of other resources
> where we have configured and system determined values. I do not see
> that tags are any different.

I agree.  *If* you want a config true datastructure, it should be
modified with the normal edit operations, not special RPCs.  There are
several reasons for this.  For example, how would your new RPCs interact
with locks?  With candidate?  With startup?

Also I am not sure it is a good idea to add configuration meta-data
that really should be common across all modules into the modules
themselves.  Another approach is to keep a separate list with the
tags, indexed by modulename and revision.


/martin

v2.23.0 | Report a Bug | By Email