Re: Secdir telechat review of draft-ietf-regext-bundling-registration-11
John C Klensin <john-ietf@jck.com> Sun, 13 October 2019 19:24 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68E120024; Sun, 13 Oct 2019 12:24:55 -0700 (PDT)
X-Quarantine-ID: <K6qyL6Ygb8Jr>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...55726284@ietfa.amsl.com>\n \n <CALaySJ+_cGw[...]
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6qyL6Ygb8Jr; Sun, 13 Oct 2019 12:24:53 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DA9120013; Sun, 13 Oct 2019 12:24:53 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>, Russ Housley <housley@vigilsec.com>
cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org
Subject: Re: Secdir telechat review of draft-ietf-regext-bundling-registration-11
Message-ID: <D4EF4C8F115C9C0B186BE1D6@PSB>
In-Reply-To: <B6C040FB39BBDE043035D02D@PSB>
References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> <CALaySJ+_cGwUA94O8b09nU+qujQbPmBUGQATQmzpp-ko8SLoNA@mail.gmail.c 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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-yJ99abIMjWCh5DqOIm2PPYS6Wk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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. thanks, john --On Sunday, October 13, 2019 14:39 -0400 John C Klensin <john-ietf@jck.com> 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. >...
- Secdir telechat review of draft-ietf-regext-bundl… Russ Housley via Datatracker
- Re: Secdir telechat review of draft-ietf-regext-b… Jiankang Yao
- Re: Secdir telechat review of draft-ietf-regext-b… Barry Leiba
- Re: Secdir telechat review of draft-ietf-regext-b… Paul Hoffman
- Re: Secdir telechat review of draft-ietf-regext-b… Barry Leiba
- Re: Secdir telechat review of draft-ietf-regext-b… John C Klensin
- Re: Secdir telechat review of draft-ietf-regext-b… John C Klensin