Re: [regext] milestones for recently adopted documents

Patrick Mevzek <> Mon, 27 April 2020 05:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 342893A0C28 for <>; Sun, 26 Apr 2020 22:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=CmxTYGSY; dkim=pass (2048-bit key) header.b=uD4oAARz
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZlbzI0UtdvfL for <>; Sun, 26 Apr 2020 22:32:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB17F3A0C53 for <>; Sun, 26 Apr 2020 22:32:40 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 6B09263B for <>; Mon, 27 Apr 2020 01:32:39 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 01:32:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=rK310y5AXSGSriJsrtlQJ95V7uHV+cj BVUN/M4Utn3s=; b=CmxTYGSYoK1CPefZf6VG6lRzJNjS9WU2TCEssPKmVBNPiwM jlOexzcPMtPFUmaxsS/qjkGu8nXsqbjTGr0IuYh6U8QBwd1Ek+kUeD2FZobVqfgS exkTk8syU0JnlBjX3ma6lJD6Rvfwlf66uBVX1qm525feai9/DYM9rz1SRDskuv35 2WttzMO9JefRc/k+Y+9Jk3dWDIEGyO2722l/0GSQWegQjPqZ4eS6ZvcUHKb0i9rm fPZttPPIQsd7YTKAHffs5El/uR87gY2q3iM8PMj5LfdMeuEyt7INYv1c2hCdRzPr cdeClvs9DNfITFOycZIgx91OOVWhuVMSj8CEq9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rK310y 5AXSGSriJsrtlQJ95V7uHV+cjBVUN/M4Utn3s=; b=uD4oAARzLTvjNTUqlTQeyh vRCVvpXqw0zMrWBKbQtJV1y1O012n98B08hbUFiE0BZzhK6I2qq+lYqDqziI6BeS JBSgoKF3HYefUwoUC0cCjy7kcKiWh71rrXutkWhKxW/8SNUYnRK2xx0vvF4KvQpR ZIk4LRiDwKdoOaz4tlGKtZdo2P4u6pml7GSxIIpDACK5J0Wb8rU/CyggONOzza4q wmii276PIuJR8NyV3Ju14L5RaRhPBUWKglta04/mImDC7On3x8+Gx2ZxAz0G6eRx +UC84gTlWisO54NIdqUf+ThkV0hw3wIVIUxj1f701P9crUPzu6mOj5178UbNyZoQ ==
X-ME-Sender: <xms:dm6mXruSu0rzy1w6DH-h7KgkoFOpNmG-CxpU-hG5RVNU9Cq5nX3IFvth5SY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmseguohht rghnuggtohdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutgho rdgtohhm
X-ME-Proxy: <xmx:dm6mXiQTvPX0-BDZ4anZmf2CRcM2_tAQ0mxT9HkaJvVBWXOUl1YIQA> <xmx:dm6mXg2U6Jzx4uDXaPiiMdo_tchNJWeIMlehkqE53GR8VvjABnJhxw> <xmx:dm6mXizOp3gpsENXW-lOEB5DFsxJZ32KkgkfXJProGzb_vfu9j-ZtQ> <xmx:d26mXoKbRz1BGpSwN_E3Ai8e3zkvol7kesoxKMX43tIiYL1RZ7XzhQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7A5F76680073; Mon, 27 Apr 2020 01:32:38 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Mon, 27 Apr 2020 00:32:17 -0500
From: Patrick Mevzek <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [regext] milestones for recently adopted documents
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 05:32:44 -0000

On Fri, Mar 6, 2020, at 10:02, James Galvin wrote:
> The co-chairs have discussed proposed milestones for the recently 
> adopted documents.  We would like to propose the following.
> 	2020 October - Jim Galvin will be document shepherd


> Document authors are encouraged to begin discussion of these documents 
> on the list at this time, in preparation for asking for submission to 
> the IESG for publication.

In that regard, for this document, I can offer again my list of comments and questions
already asked 2 years ago on the mailing-list without any follow-up:

They were also some procedural interrogations, but the technical parts are below.

Before that, now with a fresh view, I'm wondering if "maintenances" are really
objects that should managed through EPP and what is the benefit.

If I take for example one of the major ccTLD disruption from this week-end,
due to DDOS, the EPP server was completely unreachable. I am also sure the registry
at that moment had other things to worry about than enqueing to all registrars
EPP polling queue a message about an emergency maintenance... which can not
be read anyway as the server is unreachable.
So right now I am not sure anymore to be convinced that:
- maintenances are objects in EPP ecosystem, like domains or hosts
(in fact they are not *registrar* objects in registry database, which is what EPP is bout)
- if doing so does really provide benefit in operations, especially for the
unscheduled maintenance cases

Back to the technical part from 2 years ago:
I did a quick glance on my past technical comments anyway, it seems the document did not change significantly since then 
so most if not all points apply.
In fact in the meantime I found other 2 areas of concern that I did not bother
post about but here they are:


"     <maint:environment>
       MUST be present and indicates the type of the affected system;
       values SHOULD either be 'production', 'ote', 'staging' or 'dev'"

but in schema:
     <complexType name="envType">
         <extension base="token">
           <attribute name="type" type="maint:envEnum" use="required"/>
           <attribute name="name" type="token" use="optional"/>

So text and schema do not seem to align very well and at the very
least the text does not say anything about the "type" and "name" attributes.
Also, since "type" is an enum, you can not say "values SHOULD either be...", they MUST be one of the values in the enum list.
And you do not list the "custom" value among the possible ones.


"     <maint:description>
       MAY be present and provides a freeform description of the
       maintenance without having to create and traverse an external
       resource. The maximum length MUST NOT exceed 1024 bit."

and in schema:
     <complexType name="descriptionType">
       <restriction base="string">
         <maxLength value="1024"/>

So, it should be 1024 characters in the text, not 1024 bit (sic).
Also, I see no reason for this limit, can you care to explain why description content, being freeform for human consumption, should be limited at the protocol level?

  Patrick Mevzek