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