Re: [regext] Secdir telechat review of draft-ietf-regext-bundling-registration-11
John C Klensin <john-ietf@jck.com> Sun, 13 October 2019 18:40 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF26112003F; Sun, 13 Oct 2019 11:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 XAIhLnOSbwMm; Sun, 13 Oct 2019 11:40:07 -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 596DC120024; Sun, 13 Oct 2019 11:40:07 -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 1iJimi-0007O3-Ni; Sun, 13 Oct 2019 14:40:04 -0400
Date: Sun, 13 Oct 2019 14:39:59 -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
Message-ID: <B6C040FB39BBDE043035D02D@PSB>
In-Reply-To: <CALaySJ+_cGwUA94O8b09nU+qujQbPmBUGQATQmzpp-ko8SLoNA@mail.gmail.com>
References: <157071977760.20403.2267644082355726284@ietfa.amsl.com> <CALaySJ+_cGwUA94O8b09nU+qujQbPmBUGQATQmzpp-ko8SLoNA@mail.gmail.c om>
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/regext/aY7Pe6lUcFxVdkd7_gIvNzGnfho>
Subject: Re: [regext] Secdir telechat review of draft-ietf-regext-bundling-registration-11
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2019 18:40:11 -0000
--On Sunday, October 13, 2019 16:25 +0200 Barry Leiba <barryleiba@computer.org> wrote: >> The Abstract ans Section 1 say: "This is a non-standard >> proprietary extension." I understand that this is not a >> standards track document, so the "non-standard" part makes >> sense. However, what is the point of publishing a >> "proprietary" extension as an RFC. I would hope that >> interoperable implementations is the goal of publication. > > I'm afraid this addition is my fault. Perhaps > "proprietary" is the wrong word here: The point is that > this is documenting an extension developed by one registry and > not in use by others, with the idea that if others want to use > it they can follow this to interoperable. It's rather like > when we documented Apple Bonjour as Informational. > > Better word? Barry, Our traditional way of handling this sort of thing is to have the title say "FooCompany's method of doing X" (presumably, in this case, "CDNC Method for Domain Name Mapping Extension for Strict Bundling Registration" (with or without the EPP identification) and then identifying the companies or registries that have implemented it in the Introduction. Some of the latter information is included in Section 12 on Implementation Status but not only is that section not referenced from the Introduction, but there is a note requesting that the RFC Editor remove it. Most such documents have been handled as Independent Submissions, rather than by the IESG and the IESG has generally insisted on such titles and introductory material as well as the usual "this is not a standard..." boilerplate. That list specifically includes RFC 4290, an opinion piece on registration procedures for IDNs that is referenced by this document, and RFCs 3743 and 4713, which are the core JET and CDNC documents respectively and which, while not referenced from this document, appear to define and explain concepts essential to it. If the Bonjour spec you are referring to is RFC 6886, while the title does not reflect that status, the Abstract does indicate its status and it was also handled as an Independent Submission. Noting that there is a presumption of IESG Consensus for anything published in the IETF Stream (even Informational pieces), I suggest that if this is a non-standard, but compatible, extension that is expected to be published in the IETF Stream, the title should be adjusted to show the status as above, the implementation status should be retained, and, although it is unusual, an explicit statement should be included that others are free to implement and use this extension without any special arrangements with the authors or their organizations. Or toss it over the wall to the ISE with an explicit note indicating that there has been BOF, WG, and mailing list discussions (possibly by including the Shepherd's report), that the WG is in favor of this being published, waiving further RFC 5742, and urging expedited handling. That would allow a quick review through the ISE and associated processes, which are much more familiar with this type of document than the IETF Stream his historically been. 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. best, john p.s. While I appreciate the acknowledgment which is possibly due to my contributions to related work, I generally do not follow EPP work (for reasons of which several of those copied on this note are aware) and do not remember looking at this document, at least in its present form, before it was called to my attention by this correspondence. On the other hand, perhaps the authors could anticipate the future and proactively acknowledged my comments above :-)
- [regext] Secdir telechat review of draft-ietf-reg… Russ Housley via Datatracker
- Re: [regext] Secdir telechat review of draft-ietf… Jiankang Yao
- Re: [regext] Secdir telechat review of draft-ietf… Barry Leiba
- Re: [regext] Secdir telechat review of draft-ietf… Paul Hoffman
- Re: [regext] Secdir telechat review of draft-ietf… Barry Leiba
- Re: [regext] Secdir telechat review of draft-ietf… John C Klensin
- Re: [regext] Secdir telechat review of draft-ietf… John C Klensin