Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Christian Hopps <chopps@chopps.org> Fri, 16 November 2018 02:57 UTC
Return-Path: <chopps@chopps.org>
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 ABAFC130E3D; Thu, 15 Nov 2018 18:57:19 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BWWCWYV4sDnY; Thu, 15 Nov 2018 18:57:18 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2332D1274D0; Thu, 15 Nov 2018 18:57:18 -0800 (PST)
Received: from dex.chopps.org (97-83-3-72.dhcp.aldl.mi.charter.com [97.83.3.72]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5CE1360024; Fri, 16 Nov 2018 02:57:17 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
Date: Thu, 15 Nov 2018 21:57:16 -0500
Cc: Christian Hopps <chopps@chopps.org>, Robert Wilton <rwilton@cisco.com>, joel jaeggli <joelja@gmail.com>, "draft-ietf-netmod-module-tags.authors@ietf.org" <draft-ietf-netmod-module-tags.authors@ietf.org>, NETMOD Working Group <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA626D88-6ED2-40AD-B38E-EFBD2860D579@chopps.org>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com> <c6d24aae-267e-1b0e-0602-7e9d2e9d3961@cisco.com> <A6608120-8F38-4FB6-9B44-BA4D1755264A@chopps.org> <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
To: Kent Watsen <kwatsen@juniper.net>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/T5AQ2yFUtt_I6JA_3QhhLmb8Gos>
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 16 Nov 2018 02:57:20 -0000
So I would now have a new tags server to store tags associated with the modules for each of my actual servers in my network? This seems a bit convoluted to me, and I haven’t heard anyone say what the problem is with the servers storing the tags associated with their modules, there are obvious problems (that you highlight) with the servers *not* storing the tags. I think this is a rather simple thing we’ve proposed, and the server is the seemingly natural/simple place to do it. I think it would be good to get some justification for *not* having the server store tags for it’s own modules. Thanks, Chris. > On Nov 15, 2018, at 19:54, Kent Watsen <kwatsen@juniper.net> wrote: > > >> The servers implement the modules which can have predefined tags from >> the module designer as well as the implementer (vendor) which literally >> cannot come from anywhere *but* the server that implements the module. > > Predefined tags from the implementer only needs to come from the > implementor. Whether it is provided by the server itself or via > some out-of-band mechanism (e.g., module catalog) seems to be the > question. > > Of course, one might say that user-tags must be provided by the > server itself, in order to provide an inter-client communication > mechanism of some sort, as otherwise a single client, even if > distributed, could keep the user-tags in its local database. > > Though this begs the question, would it be better for the clients > to use a centralized service of some sort (perhaps within the > deployment's infrastructure, assuming the user-tags are private) > to have user-tags once per module, rather than (redundantly?) on > each server, thus ensuring consistency as well as avoiding > potential race conditions? Or are these user-tags truly > server-specific (not just module-specific)? > > Is it accurate to assume that two servers running identical > software would have identical user-tags? Of course, the servers > might be running different software (either different releases > for the same hardware, or different hardware, potentially from > different vendors). Accommodating such would complicate the > construction of a centralized module-tagging service, though > it could still be done. > > I suppose that the value of this document is not in any one of > the use-cases, as they each seem minor and having alternate > (potentially better) workarounds, but in the multitude of them > all, and how a single mechanism can help. > > >> This is not what I thought would hold this work up. > > My experience is that Last Calls tend to drive people to question > basics again. By example, it's rather common for a draft's title > to change during a Last Call. That said, this suitability question > has been lingering since the day Joel kicked off the Adoption Call, > that it is still with us seems to be the problem. > > > Kent // contributor > > >
- [netmod] Confirming draft-ietf-netmod-module-tags… joel jaeggli
- Re: [netmod] Confirming draft-ietf-netmod-module-… Alex Campbell
- Re: [netmod] Confirming draft-ietf-netmod-module-… joel jaeggli
- Re: [netmod] Confirming draft-ietf-netmod-module-… Robert Wilton
- Re: [netmod] Confirming draft-ietf-netmod-module-… Christian Hopps
- Re: [netmod] Confirming draft-ietf-netmod-module-… Robert Wilton
- Re: [netmod] Confirming draft-ietf-netmod-module-… Christian Hopps
- Re: [netmod] Confirming draft-ietf-netmod-module-… Robert Wilton
- Re: [netmod] Confirming draft-ietf-netmod-module-… Christian Hopps
- Re: [netmod] Confirming draft-ietf-netmod-module-… Andy Bierman
- Re: [netmod] Confirming draft-ietf-netmod-module-… Robert Wilton
- Re: [netmod] Confirming draft-ietf-netmod-module-… Kent Watsen
- Re: [netmod] Confirming draft-ietf-netmod-module-… Christian Hopps
- Re: [netmod] Confirming draft-ietf-netmod-module-… Andy Bierman
- Re: [netmod] Confirming draft-ietf-netmod-module-… Jeff Tantsura
- Re: [netmod] Confirming draft-ietf-netmod-module-… Robert Wilton
- Re: [netmod] Confirming draft-ietf-netmod-module-… joel jaeggli
- Re: [netmod] Confirming draft-ietf-netmod-module-… joel jaeggli
- Re: [netmod] Confirming draft-ietf-netmod-module-… joel jaeggli