Re: [regext] milestones for recently adopted documents

[Patrick Mevzek <[e-mail]>]

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.
> 
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
> 	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:
https://mailarchive.ietf.org/arch/msg/regext/d79sscIkCy0RR1yv-VZb3d2_D48/

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">
       <simpleContent>
         <extension base="token">
           <attribute name="type" type="maint:envEnum" use="required"/>
           <attribute name="name" type="token" use="optional"/>
         </extension>
       </simpleContent>
     </complexType>

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"/>
       </restriction>
     </complexType>

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
  [e-mail]