Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
joel jaeggli <joelja@gmail.com> Thu, 22 November 2018 15:25 UTC
Return-Path: <joelja@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 D666412D84D; Thu, 22 Nov 2018 07:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 5jnYhiMkiYxO; Thu, 22 Nov 2018 07:25:44 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 B90EC129A87; Thu, 22 Nov 2018 07:25:44 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id v28so1864691pgk.10; Thu, 22 Nov 2018 07:25:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XNyRX0ee9qN9B1jBJ533F4qWvWtJOyUCqb943xEOFds=; b=JlJXgrsK5L0xdiH3SF74rLQNmXUHgmmMQDNciYr4PCb3B8JJZGy/w0Ggo3W1h3Iqlf Lv5fV5t59JKbbL3io1mK8hnN21VJq1+1+WpkBzZuv3kh8fDe28/zE0XfU13YBpChLkLm dQdT2hS3I5HkmjzIuLswCRyCX0Jm3ybMnv4glhfNnW92J4NVUkTBoVptbCZoxyZv6oUy LpX5vVXbF7aAdsoxL3OuEbINqWQWdsepbpI57XQ4fWXRpuHRtAeNIMIJf6Y31TMJFN4d 6dNfDYPa76ZH6RLbM3LiQHt8aGWcJDXjj0qo6F+2dzl7wQ2JMf+4qhAATx5StHspZo3f 6f+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XNyRX0ee9qN9B1jBJ533F4qWvWtJOyUCqb943xEOFds=; b=R+4frAUAOm3Vv3ekGHOyOfmAfuJPccETirMUXt3Cb30X1IWHs7xaN8hAtBmnVgtyUw xHvt0de0fr44YtyAOOVaUQm2Z+j2v9OKBhUbur57IZFdsZqYnmz2CgYbp/YKIhgvpGsi ABFrazlGATEUuxLuabheLLxvcs7MYD0UnKsO27BpwJIeRMAdnErTfIueNtIRfQyvizHk ZuYeWOgI5f6LOA3PwJi0K3vnUNJepEPX101fjoPlajk2XJwUdtU1Z2H7sri6wa76887R LHKn1X8jLMT/5aSm1dwRtppY3cqLpuEImnzv6EUGPHRVwgBIiV+mmD139lCwHWyGr5gz jksg==
X-Gm-Message-State: AGRZ1gIuEjyZub6Sv4qsxgv12qxYiWB11vV3swaFg8NEUnM5EJtfKCYy JlcuCPs3O/v8byCD8kuL6Sx1TROBdGE=
X-Google-Smtp-Source: AJdET5dmh9nk72Qtn7n1BEZ/Mo95WijAAX/nrldU+bFe6q5+jins2Sv3zk+g16XF4ivpK9QxHaSZkA==
X-Received: by 2002:a62:c42:: with SMTP id u63-v6mr12058004pfi.43.1542900343919; Thu, 22 Nov 2018 07:25:43 -0800 (PST)
Received: from [172.20.10.2] (mobile-166-137-176-240.mycingular.net. [166.137.176.240]) by smtp.gmail.com with ESMTPSA id h124sm24847554pfg.143.2018.11.22.07.25.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 07:25:43 -0800 (PST)
From: joel jaeggli <joelja@gmail.com>
Message-Id: <59148A79-7C50-479C-8F53-0EDF3C426EC4@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2AD0A735-51A1-4E8A-B366-78836438CF9A"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Thu, 22 Nov 2018 07:25:40 -0800
In-Reply-To: <cce02f66-1ee6-6c08-92c9-5811fb199323@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, draft-ietf-netmod-module-tags.authors@ietf.org, NETMOD Working Group <netmod@ietf.org>
To: Robert Wilton <rwilton@cisco.com>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com> <c6d24aae-267e-1b0e-0602-7e9d2e9d3961@cisco.com> <A6608120-8F38-4FB6-9B44-BA4D1755264A@chopps.org> <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com> <DD0C60B5-6556-4C60-9F99-D1E7735BCEAA@chopps.org> <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com> <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org> <cce02f66-1ee6-6c08-92c9-5811fb199323@cisco.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WXb7X3cMoYmAv0FetFfqWq2fiHw>
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: Thu, 22 Nov 2018 15:25:47 -0000
Something like the text below addresses the question of guidance. I think we get a better draft if we close off this discussion on the list. I think the question about where the tags reside generally is settled. Thanks joel > On Nov 14, 2018, at 09:26, Robert Wilton <rwilton@cisco.com> wrote: > > >> >> The answer is: >> >> 1) B/c there's literally no where else they could be stored (no way for a vendor to add tags) >> 2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place. >> >> Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things. > That is not what I was suggesting. > > I was suggesting text something like this: > > Introduction: > > OLD: > > The use of tags for classification and organization is fairly > ubiquitous not only within IETF protocols, but in the internet itself > (e.g., #hashtags). Tags can be usefully standardized, but they can > also serve as a non-standardized mechanism available for users to > define themselves. Our solution provides for both cases allowing for > the most flexibility. In particular, tags may be standardized as > well as assigned during module definition; assigned by > implementations; or dynamically defined and set by users. > > NEW: > > The use of tags for classification and organization is fairly > ubiquitous not only within IETF protocols, but in the internet itself > (e.g., #hashtags). One benefit of using tags for organization > over a rigid structure is that it is more flexible and can more easily > adapt over time as technologies evolve. Tags can be usefully > standardized, but they can also serve as a non-standardized mechanism > available for users to define themselves. This document provides a > mechanism to define tags and associate them with YANG modules in a > flexible manner. In particular, tags may be standardized as > well as assigned during module definition; assigned by > implementations; or dynamically defined and set by users. > > > NEW: > > 1.1 Some example use cases of YANG module tags > > Tags can be used to help filter different discrete categories of YANG > modules supported by a device. E.g., if modules are suitably tagged, > then an XPath query can be used to list all of the vendor modules > supported by a device. > > Tags can also be used to help coordination when multiple > semi-independent clients are interacting with the same devices. E.g., > one management client could mark that some modules should not be used > because they have not been verified to behave correctly, so that other > management clients avoid querying the data associated with those > modules. > > Tag classification is useful for users searching module repositories > (e.g. YANG catalog). A query restricted to the 'ietf:routing' module > tag could be used to return only the IETF YANG modules associated with > routing. Without tags, a user would need to know the name of all > the IETF routing protocol YANG modules. > > Future management protocol extensions could allow for filtering > queries of configuration or operational state on a server based on > tags. E.g., return all operational state related to system-management. > > > If you think that this text is helpful, and it allowed, then please add it, refining as required. If you think that it detracts from the clarify of document, and is superfluous then leave it out, that is also fine with me ... > > Thanks, > Rob > >
- [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