Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

joel jaeggli <> Thu, 22 November 2018 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8C2D126CB6; Thu, 22 Nov 2018 07:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vD1YPN3AwWse; Thu, 22 Nov 2018 07:15:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95211130ED9; Thu, 22 Nov 2018 07:15:43 -0800 (PST)
Received: by with SMTP id x21-v6so9394154pln.9; Thu, 22 Nov 2018 07:15:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fTN1oTl4BnZ4lY/ByqHj7eWnDMOArfz5roXGzVzbC9E=; b=Q3j542dqsQ/RD/gIgKETIDYIzZOxq7yE+zE2AWR0fnSldSHip0erTiQPl9bXe2KHFO QOdZT+IHsMNQYH80EnYUe/doyaliXiZJIARvxKH+HV+7idOz26OeVBskChgOq6ngi3OD s40LfSaodnJ8wwyZbMN8/GmJuofOY3IUqxTigZrbeYCCIFoej6FNpn2o7n42+IH15DNb objXsBLVshWbeedTnMs5+WrjbZaP8YRWe5u4KrkysVS+6WyF0OPBdY9kGLfupruhwQxj Le7ajzZkI2SUZIQ805uw48NGhrjSLET+e+lSKPWYRMAM6q5eHJ+z85Ojnpo+KxiAyOQP lhSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fTN1oTl4BnZ4lY/ByqHj7eWnDMOArfz5roXGzVzbC9E=; b=IrSNnxFJk1mJnSn3PnnRkC9RlA8B9c/v2RZUcSVrI5BhJ8LyiE3Wotz6fYVw26zSwL Uk2LtlVTsu79RMbD5xbuxTebJmNqBK9x/33WjuXBBLVoNFGKRJoFuPVkqmfs0oqMQYs6 8nTPBKCPJDT9v4aYcUHwqLhEporAUM9/05sWWJ7l3ucrh1ItwtcgRuFkP1CWO7aHbdun B6A3bhcILlcLKgs4sSIywOl6JGbk07hrOk2+YwY4CcFdbeb1KCOV2k6eGj93eiXNdrsd ZS4N1FoEnPtHddGTVAHhAwWuZ0yAbiEflFR+EVq3aP50a4e4mDCq6Et4nSVw7SWos9VO +bOg==
X-Gm-Message-State: AA+aEWbxXtzZBDWUnaV2SeeSzxPxpEPNSBirpLszy08x9SgkEQ4iyabD udaNVCNsHL0YGIUA8ex6KXRtFXWMBak=
X-Google-Smtp-Source: AFSGD/UVfk4xXJlNVpnCecZTDsPW0Ba3FEM46KU03/cVJGoD2AwsrfFLjY+beB02EaJiOR7w71OOgg==
X-Received: by 2002:a17:902:aa0a:: with SMTP id be10mr11487544plb.266.1542899742846; Thu, 22 Nov 2018 07:15:42 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g190sm51024294pgc.28.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 07:15:42 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: joel jaeggli <>
In-Reply-To: <>
Date: Thu, 22 Nov 2018 07:15:39 -0800
Cc: Christian Hopps <>,, NETMOD Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Robert Wilton <>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <>
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Nov 2018 15:15:46 -0000

>>  I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it.
> My apologies, but I had intended to review this more thoroughly during the WG LC but ran out of time.  If was when I read Alex's comments that I thought that he was raising some valid points. The key one that struck a chord is that this document describes a solution but doesn't seem to clearly describe what problem it is solving (other than tags are good), or how it is intending to be used.  When I reviewed this document after reading Alex's comments, I was asking myself how this was going to be used, and the answer I came up with was that I didn't really know.  Or the case that I had in mind (YANG catalog filtering on module tag) doesn't seem to match the authors envisaged use cases.  Looking back at some of the previous comments on this work (not just Alex), others have also questioned what problem it is solving and how it will be used.

So the backup slides I had for the talk basically asked if more proscriptive text was required on their use. Which is a bit different then working how they are to be used. 

The three cases of module tags, IETF, Vendor and User come from different sources. The IETF source comes with a demand for IETF consensus. The others do not. 

Ultimately I can imagine all sorts of user classification schemes that might emerge so my general conclusion that that any description should come in the form of guidance rather than proscription.