Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-module-tags-07: (with COMMENT)

Christian Hopps <> Fri, 03 May 2019 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 610B61202DB; Fri, 3 May 2019 11:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fTOmqg_i0s2D; Fri, 3 May 2019 11:48:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA92E1202D9; Fri, 3 May 2019 11:48:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 31F396019B; Fri, 3 May 2019 14:48:33 -0400 (EDT)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_7D383906-6D8E-4253-863D-0D47465AD531"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Fri, 3 May 2019 14:48:31 -0400
In-Reply-To: <>
Cc: Christian Hopps <>, The IESG <>,, Joel Jaeggli <>, NetMod WG Chairs <>,
To: Alvaro Retana <>
References: <>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <>
Subject: Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-module-tags-07: (with COMMENT)
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: Fri, 03 May 2019 18:48:42 -0000

> On Apr 11, 2019, at 9:30 AM, Alvaro Retana via Datatracker <> wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-netmod-module-tags-07: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (1) Along the same lines of Alissa's DISCUSS, which I support.
> §6.1: "For standardized modules new tags MUST be assigned in the IANA registry
> defined below, see Section 7.2."  What is a "standardized module"?  It sounds
> like a Standards Track document, but (as Alissa pointed out) the registration
> policy is only IETF Review.

In addressing the other DISCUSS/COMMENTs almost all (but not all) use of the word "standard tag"/"standardized tag" has switched to some variant of "registered tag". That said, the intention here is what you read: it's saying if you are defining a module in a standard's track document then any new tags you create MUST be added to the IANA registry. This doesn't contradict the IANA registry policy of IETF review (i.e., it's not talking about or trying to constrain the registration policy). Consider a case of a info doc that is documenting some odd or misuse of tags, we don't want to require that this doc register the "odd" or misused case in the registry -- it could, but it's not required.

> (2) §7.1: "All YANG module tags SHOULD begin with one of the prefixes in this
> registry."  That statement along with the text in §2.4:
>   Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is
>   reserved for future standardization.  These tag values are not
>   invalid, but simply reserved in the context of standardization.
> ...seem to indicate that a tag with any format can be used.  Is that true?  Is
> that the intent?  If so, then it seems to me that vendor/user tags could simply
> forgo the standardized prefix.  I guess this is just makes me wonder
> about the need to even define those prefixes.

The document goes to some length to make sure that users can do whatever they want as they should be the final arbiter (that philosophy). The need for the standard prefixes is to provide a stable framework so that if users choose to follow the prefix rules (i.e., use "user:") then they won't get stepped on by upstream (design and vendor) uses.

> (3) I'm not sure what, but I think it may be wise to give the would-be DEs for
> the new registry in §7.1 some more guidance on the allocation of new prefixes.
> The only current guidance is this: "Prefix entries in this registry should be
> short strings consisting of lowercase ASCII alpha-numeric characters and a
> final ":" character."

The expected use case (and thus the "guidance"):

   Other standards organizations (SDOs) wishing to allocate their own
   set of tags should allocate a prefix from this registry.

Perhaps you think this needs wordsmithing though?