Re: [netmod] Module tags

Kent Watsen <kwatsen@juniper.net> Mon, 13 February 2017 18:19 UTC

Return-Path: <kwatsen@juniper.net>
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 1772D129795 for <netmod@ietfa.amsl.com>; Mon, 13 Feb 2017 10:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.788
X-Spam-Level:
X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 32idLU3-_tQ5 for <netmod@ietfa.amsl.com>; Mon, 13 Feb 2017 10:19:14 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0102.outbound.protection.outlook.com [104.47.38.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153591297A8 for <netmod@ietf.org>; Mon, 13 Feb 2017 10:19:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mSWUlnrXi8QaTyr4GPfiS0rMr6a+rYvvgFbGcCYzwy8=; b=CpaTp8NLKoC4oWHTSEbybecpHK6LOr/d62MMcOKmR+RNUrHO84b7mBu4dtYc3hTYJkQ7CSFM1QMNh8kMradKfKWRhLM4BjrLFjk8nvNbcEyeVOnhNs0MSiKG0C1FxTTdbu4YYPPmhsYhfLw8IGqFi2Ye9Lj5p9Mwk/kbs6Gj+mI=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 13 Feb 2017 18:19:11 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.011; Mon, 13 Feb 2017 18:19:11 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Robert Wilton <rwilton@cisco.com>, Lou Berger <lberger@labn.net>, Christian Hopps <chopps@chopps.org>, Dean Bogdanovic <ivandean@gmail.com>
Thread-Topic: [netmod] Module tags
Thread-Index: AQHSglkaJXuA9MNmPEe0mVPdwufnwKFfvBOAgACS4gCAACvkAIAAChyAgAAT9wCAAAJVgIAGkk0A///FRoA=
Date: Mon, 13 Feb 2017 18:19:11 +0000
Message-ID: <99A1ACCD-FDAE-4BE3-A267-E6FD12621B37@juniper.net>
References: <87r338gtzw.fsf@chopps.org> <20170209.085506.1418859449501855827.mbj@tail-f.com> <878tpfac43.fsf@chopps.org> <20170209.120823.198284779081114388.mbj@tail-f.com> <874m03a74p.fsf@chopps.org> <15a22d86378.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <72728899-a310-b43e-65dd-7623135c5fba@cisco.com>
In-Reply-To: <72728899-a310-b43e-65dd-7623135c5fba@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 51fded13-5b1b-462d-4e80-08d4543ccf1a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443;
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:UdPXq6kd+vW0qUr/Qtzm5lw+xcMSNXxNGnjc5/GgeKaygiFFHDe1fOSfuPuzOG6iYbBF+W/1BpCSRx6jEmxZWehSlxROmdmIBFjdAxiyWF/gC96DCJJ/KhEKzGKAu8LUPfXH20sp0MKfVpzhrnDZYGvSaeGSC5QUJ1sp1VXwLdzyCicp3QUuNjFi7c/cP7C5kWMdCibTTmYjT6YpNLSpUCDq4i970W9gvbUpDLuQQcbNVrFxprx9Hu1ivji286rs2tDr3P4KDpL9bq5Bv61uJqJE8+9jjEAQCclc7jQAyiMedIRxx+ikyQTKEZ14LRNhB8Arp6lhT9UNsT3fAs3odnzZUYwXlADVXywlS92V+p+/eohfigdEeJaoq6uH6Cl2wz/nnja2jG6hfjJsTaPSwn69VuluWPcXz6CemY+wjytOMT7bBgpayo/FQThwbjkFAMpiCWTiyveui5DONSN/0lHD21eMyKvlbyG9yePdYaRQ8/8ueV5VICab9/LcWmbKos8Vem7How5l4EU/nVWEhA==
x-microsoft-antispam-prvs: <BN3PR0501MB144355EF1A05A8123A465604A5590@BN3PR0501MB1443.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443;
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(51444003)(24454002)(199003)(189002)(8676002)(122556002)(2950100002)(3280700002)(2906002)(4326007)(81166006)(3846002)(81156014)(6116002)(102836003)(53936002)(6246003)(38730400002)(97736004)(83506001)(53546003)(4001350100001)(66066001)(99286003)(101416001)(92566002)(82746002)(93886004)(39060400002)(83716003)(305945005)(36756003)(6306002)(6512007)(7736002)(86362001)(229853002)(68736007)(189998001)(106356001)(2900100001)(106116001)(33656002)(6436002)(105586002)(25786008)(8936002)(50986999)(77096006)(5660300001)(3660700001)(54356999)(76176999)(6486002)(6506006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9D577B1494A21047A487BFFCCB40EB02@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 18:19:11.3759 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jT391AXaXiz8hVDdALlHFIANiYg>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Module tags
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: Mon, 13 Feb 2017 18:19:16 -0000

As for a concrete use-case, would something like this be helpful
for a server to indicate which datastores a module is supported in?

I'm thinking specifically about the revised-datastores draft where
we've discussed that a module might exist in just oper-state,
oper-state + ephemeral, oper-state + ephemeral + running, etc.


Kent // as a contributor




Hi tags draft authors,

On 09/02/2017 12:28, Lou Berger wrote:
>
> I'm personally more excited by the use of tags as additional module 
> meta-data accessible via yang library. But also see no reason to 
> preclude this possible  (even if unlikely) usage.

When the idea of tags was presented as IETF, I had assumed that tags 
would be versioned/managed entirely independently from the YANG modules 
that the tags apply to.

For a while, there was a desire to organize YANG modules by their 
hierarchical path location in the schema tree.  My concern with this 
approach, is that there needs to be sufficient foresight to get that 
structure right now, because it will be very painful to change it in 
future.  Unfortunately things have a habit of evolving over time, and 
hence choosing the right structure now such that is still the right 
structure in 25 years seems somewhat unlikely.

I was thinking that tags offers a better solution to this problem, that 
allows the structure to be a bit more dynamic, evolving over time.  I.e. 
YANG modules for features can sit at (or near to) the top level of the 
schema tree, and tags can then be used to group those modules into 
sensible organizations that can evolve, so that when clients are trying 
to sort through all the different YANG models that are available, they 
have more hope than looking at a flat list.

In this scenario, I think that it is better if the YANG module 
definitions themselves don't specify the tags because then 
adding/removing/changing them is going to be a pain.  If this tag 
information was managed separately (e.g. in something like YANG catalog) 
then it seems easier for the tags to evolve over time.

But I also had not really realized that the tags information would 
necessarily reach down to the devices.  I.e. I hadn't envisaged Chris's 
example of querying the hello-time via an IGP package tag. Instead, I 
had thought of tags making a YANG catalog website more useful.  E.g. 
when browsing for YANG modules, be able to restrict the query to just 
the modules that are tagged as "standard" + "IGP", etc.

So, I think that this draft may benefit with a bit more description of 
the envisaged use cases, and also about how tags are envisaged to evolve 
once they have been defined.

Thanks,
Rob

>
> Lou
>
>
>> Thanks,
>> Chris.
>
>
> _______________________________________________
> 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