Subject: Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

From: Roger D Carney <[email-masked]>
Date: Fri, 1 Jun 2018 15:16:57 +0000

Good Morning,

We have been talking about Registry Mapping for over a year now and here is the official first draft<https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/>.

Please take a read and let the discussions flow! We will be having an interim meeting<https://datatracker.ietf.org/doc/agenda-interim-2018-regext-03-regext-01/> next Tuesday (June 5th at 16:00 UTC) and one of the two agenda items is a discussion of this idea/draft.

Thanks

Roger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 31, 2018 3:12 PM
To: Roger D Carney <[email-masked]>; Lin Jia <[email-masked]>; James Gould <[email-masked]>; Roger D Carney <[email-masked]>; Jody Kolker <[email-masked]>
Subject: New Version Notification for draft-gould-carney-regext-registry-00.txt

A new version of I-D, draft-gould-carney-regext-registry-00.txt

has been successfully submitted by James Gould and posted to the IETF repository.

Name:                  draft-gould-carney-regext-registry

Revision:              00

Title:                      Registry Mapping for the Extensible Provisioning Protocol (EPP)

Document date:               2018-05-31

Group:                  Individual Submission

Pages:                   61

URL:            https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry-00.txt

Status:         https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/

Htmlized:       https://tools.ietf.org/html/draft-gould-carney-regext-registry-00

Htmlized:       https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry

Abstract:

   This document describes an Extensible Provisioning Protocol (EPP)

   mapping for provisioning registry zones (e.g. top-level domains) in a

   Domain Name Registry.  The attributes of a registry zone include the

   features and policies of the registry zone.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 7 Jun 2018 16:39:36 +0200

Hi Roger,

I couldn't attend the last Interim Meeting so I apologise if some 
comments below could be obsolete:

1) According to section 1.1 of RFC 5731, a server cannot support the 
host object. So, even if the server implements a policy about IP 
addresses included in domain:hostAddr elements, it doesn't implement 
check (or any other) operation on hosts
Therefore, a minOccurs="0" attribute should be added to the element 
maxCheckHost of hostType.

2) Why should supportedStatus only contain standard status ? The 
supportedStatusType definition is less strict than the description and 
this seems good to me because supportedStatusType can match custom 
status too.

3) The description of expiryPolicy contains the following sentence:

"autoRenew": The domain object will auto-renew at expiry.
                           The client can receive a credit for the 
auto-renew if the
                          domain object is deleted within the auto-renew 
grace period."

Does it make sense to replace "if the domain object is deleted" with "if 
the domain object is deleted or transferred" ?

4) Considering that RFC 5730 defines a response code returned when a 
server receives an unimplemented command (i.e. 2101) , maybe it's worth 
to add information about unimplemented operations.

5) In my opinion, the schedule format has some limits. Java EE Timer 
expressions 
(https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples004.htm) 
seem to be more flexible especially regarding dayOfMonth values:

1 to 31. For example: dayOfMonth="15".

–7 to –1 (a negative number means the /n/th day or days before the end 
of the month). For example: dayOfMonth="–3".

Last. For example: dayOfMonth="Last".

[1st, 2nd, 3rd, 4th, 5th, Last] [Sun, Mon, Tue, Wed, Thu, Fri, Sat]. For 
example: dayOfMonth="2nd Fri".

6) Finally, I hope that in the future the draft will address the mapping 
of the possible extensions described in RFC 5730.

Regards,
Mario

Il 01/06/2018 17:16, Roger D Carney ha scritto:
>
> Good Morning,
>
> We have been talking about Registry Mapping for over a year now and 
> here is the official first draft 
> <https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/>.
>
> Please take a read and let the discussions flow! We will be having an 
> interim meeting 
> <https://datatracker.ietf.org/doc/agenda-interim-2018-regext-03-regext-01/> 
> next Tuesday (June 5^th at 16:00 UTC) and one of the two agenda items 
> is a discussion of this idea/draft.
>
> Thanks
>
> Roger
>
> To: Roger D Carney <[email-masked]>; Lin Jia <[email-masked]>; 
> James Gould <[email-masked]>; Roger D Carney 
> <[email-masked]>; Jody Kolker <[email-masked]>
> Subject: New Version Notification for 
> draft-gould-carney-regext-registry-00.txt
>
> Name:draft-gould-carney-regext-registry
>
> Revision:00
>
> Title:Registry Mapping for the Extensible Provisioning Protocol (EPP)
>
> Document date:2018-05-31
>
> Group:Individual Submission
>
> Pages:61
>
> URL:https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry-00.txt
>
> Status:https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/
>
> Htmlized:https://tools.ietf.org/html/draft-gould-carney-regext-registry-00
>
> Htmlized:https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry
>
> Abstract:
>
> Domain Name Registry.The attributes of a registry zone include the
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 09 Jun 2018 09:39:09 +0200

On Fri, Jun 1, 2018, at 17:16, Roger D Carney wrote:
> We have been talking about Registry Mapping for over a year now and here 
> is the official first 
> draft<https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/
> >.
> 
> 
> 
> Please take a read and let the discussions flow! 

Some quick remarks before trying to implement it and hence reviewing it more in depth later.

First I think it is an important concept (auto-discovery), whatever the implementation is. It would be most useful if deployed by multiple registries, also outside of gTLDs, so even if not technical some outreach should be done to try finding registries willing to participate and/or deploy it later.
So that during desigining no spots are missed.

Also I think this is an extension that needs itself to be extended.
I have seen the other document about the launchphase policies but I think the model should be different, so that extension data is still inside the <registry:infData> node.
Here is an outline of what I thought, so names are just examples:
among the nodes there would be a <policy> one with a "for" attribute whose value would be the XML namespace of the extension concerned by the policies that will be described inside this policy node. So infData will be mostly a list of <policy> nodes. The core document would define the blocks for RFC 5730 to 5733 (and maybe also RGP and DNSSEC) and then each other extension would define their own block content.

Also, using the XML namespace as identifier may not be always possible: all policies regarding transport are in RFC5734 which has no XML namespace per se.
So maybe instead of the XML namespace you could use the RFC number or the interne-draft name.

In the long run if all of this work (independ of the specific implementation details) I would think at least an update to RFC3735 would be welcome that could add:
* IANA registration in the EPP registry is mandatory 
* and description of the policy of the extension described must exist and conform to this document standard.

More specifically now, about "2.3.  Schedule" I am *strongly* against using the format proposed for at least 2 reasons:
- crontab format is not a standard, and is ambiguous for various points
- it encodes a format as a string which is itself in a formatted structure since it is XML. "Hijacking" some free form space when you are in formatted structure seems wrong to me and shows that the structure is not correctly formatted because if it were you would not have to inject a new format in a free text.

Why not use ISO8601 Repeated Time Interval format? We are then still gulty of the previous point but at least it is a standard.
Otherwise please amend the XML structure to break the content currently in the crontab format.

As for timezones, all EPP standards always used UTC for all timestamps (and even if some registries on the field do not respect that), and I think it would be best to stick to that, so that removes the "tz" attribute.
 
I find this unfortunate:
<registry:name>:  The zone name that can be at any level

When you parse it, you read it as "a registry name", but then it is a zone.
So while it could probably not be <zone:name> it should at least be
<registry:zoneName>.

You are speaking about "regex" in various places without referencing how is this formatted. There are multiple de facto regex "standards" so care must be taken there to reference precisely what kind of regex are manipulated.
Also, for example for passwords, some registries policies are not possible to express (only) in regex I think, so there might be a blind spot here.

alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported and maybe others (all the IDNs ones) should be removed and instead LGRs (RFC7940) should be used/referenced: far more complicated but at least you cater for all cases.

For IP addresses (min/max) you may need to separate between IPv4 and IPv6 as some registries may impose different constraints to each (including: IPv4 allowed but not IPv6)

For contacts:
- I think the design around int/loc policy does not capture all cases.
Some registries allow int only; some loc; some int only or int+loc, some loc only or int+loc, some int only or loc only or int+loc, etc.
(I am not saying all combinations exist, but there are at least more than one of them so we need to be able to handle that)
- for the contact ID some registries let the registrars choose it (per the RFC5733 spirit) but some do not and just choose instead of them; it should be possible to encode this in the policy; there may also be the need to encode that in some cases the prefix of contact ids is not free, but fixed per registrar; maybe a need too to define what happens when 2 registrars try to create the same contact ID, depending on if they are global to the system or local to each registrar (the ROID would be different of course).

Other things that would be useful to include (and could be done "easily" if you take my ideas on top to have blocks identified by the underlying XML namespace or RFC number):

- data related to transport: number of connections, timeouts (soft and hard), recommended frequency of keepalive, etc.
- data related to sessions: password policies (maybe both for registrar login and for domain authInfo) which go further than just regex you may want to code about lifetime of a password, and the sets/classes of characters allowed and their use (like mandatory one uppercase character, one lowercase, one "special", etc.), etc.
For domain passwords, is <domain:null> allowed?
(an arcane part of the standard that I know one registry does)

Also/maybe:
- various rate limiting (per command or not, etc.)
- various hitpoints mechanism (ex: 1 hitpoint per EPP error, cut of all write operations after X hitpoints, for X days or token bucket like operations)
- data about notification messages: how long are they kept in the queue? What happens at end of lifetime?
- "extended" error codes used

Finally, as bikeshedding as it may seem, I am not convinced that "Registry Mapping" is the correct naming here. The abstract talks about zones, features and policies. All other EPP standards talks about server and client, not about registry and registrar. I would favor changing the name of the extension and removing Registry from it.
I lack good suggestions for now, maybe later. Policy Mapping? Metadata? Zone Metadata?

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 11 Jun 2018 13:48:35 +0000

Patrick,

Thank you for your review and feedback.  My comments are embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 6/9/18, 3:39 AM, "Patrick Mevzek" <[email-masked]> wrote:

    

JG - Why does the extension data need to reside within the <registry:infData> node?  EPP already has an extension mechanism that can be used, so why not use it in this case?  The Registry Mapping defines a Registry object with two separate sub-objects, which include Zone and System.  The Zone represents the RFC policies for an individual zone supported by the Registry.  The System represents the policies of the Registry System.  The Registry Mapping provides the base to define zone-level (e.g., Launch Phase Policy Extension or Registry Fee Policy Extension) or system-level (e.g., Login Security Policy Extension) extensions using the existing command / response EPP extension mechanism.  

    

JG - Maybe you can provide some sample XML that combines the policy for a Registry Zone that supports what is in the Registry Mapping and in the Launch Phase Policy Extension to help understand your proposal.      

JG - The schedule can certainly be enhanced.  Can you propose an alternative structure to define it?      

JG - Yes, that is the case for communicating dates (create date, expiration date), but not the case when it comes to defining a schedule for a batch component that runs based on a local time zone.  
     
    I find this unfortunate:

JG- The label name could be changed, but I believe the most important item is the meaning of the element.  Since the <registry:name> element is a sub-element of the <registry:zone> element, wouldn't it be redundant to replicate the zone in the label (<registry:zoneName>) or the namespace (<zone:name>)?  I don't believe defining a new namespace will help here.  I believe leaving it as <registry:zone><registry:name>EXAMPLE</registry:name>...</registry:zone> with a description of the <registry:name> element as meeting the need.   

JG - Do you have a proposal of how to precisely define the regex?  I'm looking for the other registries to review the draft and weigh in on how they can effectively communicate their policies.    

JG - I agree that this would get much too complex for what we're attempting to solve here.  The alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported elements are booleans that clearly define registry policy on what can be supplied.  I would like to know about the registry policies that go beyond these booleans and the regex element.    

JG - Is this the case?  If so, you are correct that they would need to be separated.  
    
    For contacts:

JG - I'm looking for the other registries to identify whether their policy can be reflected with the "loc", "int", "locOrInt", or "locAndInt" <registry:postalInfoTuypeSupport values.  If not, I would like to know why and how it can be changed to support their policy.

JG -  That's interesting since in RFC 5733 the contact ID is client-specified.  I'm sure this is not the first case where registry policy is not following the RFC, so we need to be careful in trying to support one-off policies that are not in line with the RFCs.  With that in mind, if this is a general case, draft-gould-carney-regext-registry can certainly be updated to define the various general policies.  We just need to be careful.   

JG - This policy information is supported with the <registry:system> child element of the registry info command and the resulting <registry:system> element in the registry info response.  Is there any attribute that is missing?  

JG - The Login Security Extension (draft-gould-regext-login-security ) can have an associated Login Security Policy Extension that fully defines the password policies you outline.  

JG - I know nothing of the use of <domain:null>, so I would be interested to further understand it.  

    Also/maybe:

    -- 
      Patrick Mevzek