Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11

John C Klensin <> Sun, 13 October 2019 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D68E120024; Sun, 13 Oct 2019 12:24:55 -0700 (PDT)
X-Quarantine-ID: <K6qyL6Ygb8Jr>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References:>\n \n <CALaySJ+_cGw[...]
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K6qyL6Ygb8Jr; Sun, 13 Oct 2019 12:24:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51DA9120013; Sun, 13 Oct 2019 12:24:53 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1iJjU2-0007TZ-Si; Sun, 13 Oct 2019 15:24:50 -0400
Date: Sun, 13 Oct 2019 15:24:45 -0400
From: John C Klensin <>
To: Barry Leiba <>, Russ Housley <>
Message-ID: <D4EF4C8F115C9C0B186BE1D6@PSB>
In-Reply-To: <B6C040FB39BBDE043035D02D@PSB>
References: <> < om> <B6C040FB39BBDE043035D02D@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [secdir] Secdir telechat review of draft-ietf-regext-bundling-registration-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Oct 2019 19:24:56 -0000

Sorry... Addendum to the technical comment quoted below:

The document uses the term "variant" extensively, but does not
define it either.  That term seems essential to what is going on
in this document.  It des not appear in RFC 8499 (which is not
cited in any event).  The term was introduced into the IETF and
DNS vocabulary by the JET Guidelines (RFC 3743) but the term
there, as called out in both the text and the IESG Note, is used
for language-based preferences and relationships.  In most of
the DNS registry and registrar communities, and in the ICANN
Variant Information Project that spawned the efforts that, in
turn, led to RFCs 7940 and 8228, the term is primarily used to
describe the potential for visual confusion among characters or
strings.  The document should be clear about whether one
definition, the other, or both are intended.   Again, if it is
not, it is not possible for readers to objectively determine
whether the specification is applicable to their needs.


--On Sunday, October 13, 2019 14:39 -0400 John C Klensin
<> wrote:

> Technical comment:  While this protocol extension appears to be
> applicable only to "strict bundling" and calls that term out in
> the title, the term is, AFAICT, not ever defined in a rigorous
> way.  The Introduction says "...strict bundling, which requires
> all bundled names to share many same attributes".  Ignoring the
> inconvenient English, "many same" is not a definition without
> either a list of attributes or quantification like "at least
> five of the following list".   When we get to Section 5, the
> specification isn't talking about "strict bundling" any more,
> but, even then, says "should share some parameter or attributes
> associated with domain names", an even weaker and m0re vague
> requirement.  So readers of this document who are considering
> implementing the extension is not able to determine whether it
> is applicable to their needs (at least in the absence of
> discussions with the designers).  If "strict bundling" is
> really whatever a particular registry says it is, that should
> be explicit in the text.