Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

Joel Halpern Direct <> Tue, 15 October 2019 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 552771201E5; Tue, 15 Oct 2019 10:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N0lTrtArbtQo; Tue, 15 Oct 2019 10:52:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4081B12088A; Tue, 15 Oct 2019 10:52:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46t30S6dNbzKmlB; Tue, 15 Oct 2019 10:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1571161928; bh=PlBcsge6J7B9TtGWeR+O1Zk0oDI8uPr++o7q2E/LCRs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KKYB4Q3NOEDkvvVON115+KfKRwtRxbFbMSjYzYJAo8XXjaxBqA2bTL6lKiqtj79Nh iyeqWLTtggqkJorj385I6ji3138ENjx54yuLlJ67MLUumchD4RfnQ8GFlKkq7BvlwG G3ut9stDp//+jxd0cyuG175P8/b82zTHxqTBhLOQ=
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 46t30R1vVSz1Z3gk; Tue, 15 Oct 2019 10:52:07 -0700 (PDT)
To: John C Klensin <>, Jiankang Yao <>
References: <> <> <> <5D394E0244700A5D092F1181@PSB>
From: Joel Halpern Direct <>
Message-ID: <>
Date: Tue, 15 Oct 2019 13:52:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <5D394E0244700A5D092F1181@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Oct 2019 17:52:12 -0000

If we do not have agreement on what the meaning is for the relevant 
terms, then either
1) The document should not be an IETF consensus document (which even 
Informational publication is)
2) The document should be Experimental, indicating explicitly that there 
is ambiguity in the terms, and one of the points of the experiment would 
be to find out if that matters.


On 10/15/2019 12:59 PM, John C Klensin wrote:
> Joel,
> Let me try one reason why this should not be Standards Track or,
> if it should, it isn't ready.  It uses, and is dependent on,
> terminology for which there is no consensus definition and that
> is used to describe different things in the wild.  As I think I
> suggested one of my earlier notes about this, it would be
> possible to say "these terms mean whatever the registry says
> they mean", explicitly anticipating that different registries
> might use the extension for slightly different purposes.   While
> not a problem for an Informational document whose purpose is to
> inform the community about what some registries are doing and
> perhaps not for an Experimental one, neither that option nor
> ignoring the definitional issue are consistent with our
> expectations that standards track documents will at least lay a
> foundation for interoperability.   Even if it worked for each
> registry that uses it taken separately, many of us have seen
> situations in which companies with different definitions and
> applicability for given named concepts merge and the
> difficulties that result.   For a standards track document,
> creating such a situation would be, at least, a "known defect"
> that requires exploration and explanation in the document, text
> that is not present.
> More details on these terminology issues in my two comments on
> the Secdir review on the 13th.
> best,
>     john
> --On Tuesday, October 15, 2019 08:10 -0400 "Joel M. Halpern"
> <>; wrote:
>> Regarding the document status, neither of the emails you
>> pointed to explains why the document is Informational.  I
>> understand from that and other discussions that there is no
>> desire to make this standards track.   As has been noted,
>> publication of usages of protocol by small groups is normally
>> handled by the Independent Stream.  This document has been
>> processed by the working group.
>> It is very strange for a protocol document to be processed by
>> a working group, be accepted as not needing experimental
>> status, and not be published as a standards track document.
>> Reading teh dcouemtn, I see no reason for it not to be
>> standards track.
>> If there is concern that there may be problems with the
>> document, then Experimental status would be the normal way to
>> handle this document. With an explanation of what the
>> experiment is intended to represent.
>> If the working group feels there is a good reason for
>> informational publication, that should be document somewhere.
>> It is currently not documented in either the document itself
>> or the shepherd report.
>> The fact that proprietary extensions to EPP are allowed by the
>> protocol and registries is irrelevant.  This document is an
>> IETF working group product and therefore is not a proprietary
>> extension.
>> With regard to the "b-dn:" elements of this document, I am now
>> more concerned than I was.  I had thought those were a
>> reference to some other document that clearly defined the
>> syntax and semantics of those elements.  I now understand that
>> the given prefix is used for the new elements defined in this
>> document.  The structure that is used to describe the expected
>> and permitted content of these elements is qutie confusing.
>> The actual definition is only in the "formal syntax" section.
>> The descriptions are scattered embedded in descriptions of the
>> messages, expecting to user to determine the permitted and
>> required behavior from informal descriptive text.  Yes, for
>> those who already know how it works and what it needs,
>> everything is hear.  For a new implementor it is very hard to
>> follow.