Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 16 November 2018 04:51 UTC
Return-Path: <jefftant.ietf@gmail.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 93147129619; Thu, 15 Nov 2018 20:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 Hgc66PLJtxix; Thu, 15 Nov 2018 20:51:33 -0800 (PST)
Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 885E81286E3; Thu, 15 Nov 2018 20:51:33 -0800 (PST)
Received: by mail-pl1-x642.google.com with SMTP id b5-v6so10554556pla.6; Thu, 15 Nov 2018 20:51:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sa5++/h+n/vT9NXOCcGvEyxwdo7DSDQsg3hhbm7yVQc=; b=juvZgIKFr9x4uhOiWObGUGEDdylb7LWwzTd1kon9m3IXKyu8BrVgqpThPeMATKB7Wj hJystXoFJEWjU3jJdawZh11yvqOjOwtUz41+qZRuTIM8+GtGst0wb3lRndfHI8ebHRrX Ky7qZyuN9p3OSKJlqVepT2cPNh+Mat9KG1yHb2/ERGIcMv6ZWYfAMsjsjEPjtleJ7Jtj LPc1pqxedbL6XtD/LnXuUVkPi5rL/E07xBSiz4K85IOnn8sSKGXao9srkJIa9Mx0ibWj 1QY7J/dm4gd3l8KnyhUsZPYKovHfuD3puxEa4UUggy+22e0pZ2hn0F+zStzN3jjIKsKy fVrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sa5++/h+n/vT9NXOCcGvEyxwdo7DSDQsg3hhbm7yVQc=; b=PmtXm5FAqapop3ZzNIoHnb6Gi5dtL+amSi/az6b6kgYI9Wh/o25X5o3/XhgRppGQeL 5rUKItlQ6KbwwGLy94yYtKsvZZGvJazyCOEzqPiCuQ8jZ6Mdr4e78LGuQw8f6L0yQO36 p+lKOIG018NSX1Xtl5M/MWdgx/HRGyQdfNlRsb0olPqjXiMjick7iqjRBqjpTg6wtFsY VtwcXUBl26e8AX7xzCYypDl+M6Nhd2D8lntbHOL7BjpwrR/emP2xdN4j0uaHsUIt1rl2 KQ8mByHjjC7gtH325GgfeU6JAQbL8d0KeyZ/5/1aCTmzwRk9fE9TPq/6Xwfb2wPjsdUi x/pw==
X-Gm-Message-State: AGRZ1gJNdAA1EWI91dTkxdbISx5ZaSuhVq8C2e3rJQTcKb2Mxl2d7wlL qusph/iZHWA2vRUa8CjCcV4=
X-Google-Smtp-Source: AJdET5cAyP0tyJCudWFKMrzqIBNQXnspKB3ISQsFVklAnpSNTv7rxNYxDws2BnuYtDg7dtLULsc/qg==
X-Received: by 2002:a17:902:1105:: with SMTP id d5-v6mr9590772pla.28.1542343892995; Thu, 15 Nov 2018 20:51:32 -0800 (PST)
Received: from [192.168.88.33] (mx-ll-183.89.24-193.dynamic.3bb.co.th. [183.89.24.193]) by smtp.gmail.com with ESMTPSA id z83-v6sm34577284pfi.4.2018.11.15.20.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 20:51:32 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-806141F5-A524-4D20-8D3C-CE692FAD3895"
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <CABCOCHQ4=Nw=YJD9LRmwBiidifqGowrAcVo5yJmddap2Si99_w@mail.gmail.com>
Date: Fri, 16 Nov 2018 11:51:27 +0700
Cc: Christian Hopps <chopps@chopps.org>, joel jaeggli <joelja@gmail.com>, draft-ietf-netmod-module-tags.authors@ietf.org, NetMod WG <netmod@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <E514339F-5CF3-4DEB-8009-5CD185EA04F4@gmail.com>
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> <FA626D88-6ED2-40AD-B38E-EFBD2860D579@chopps.org> <CABCOCHQ4=Nw=YJD9LRmwBiidifqGowrAcVo5yJmddap2Si99_w@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YUq7tUq7TbcWMhkTGkRdJRMiGvg>
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 04:51:37 -0000
+1 Christian Regards, Jeff > On Nov 16, 2018, at 10:23, Andy Bierman <andy@yumaworks.com> wrote: > > > >> On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps <chopps@chopps.org> wrote: >> 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. >> > > +1 to all. > Hopefully, the standard and vendor tags automatically installed by the server are good enough, > but if not, then the user can configure tags as well. > > It would be good to get away from complex data silos in the client, or a mega-tags-server > that does the same thing. The tag mappings could get complex and keeping them in the config > on each server seems the easiest to manage, > > >> Thanks, >> Chris. >> > > > Andy > >> >> >> > 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 mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [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