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

From: "Gould, James" <[email-masked]>
Date: Mon, 16 Jul 2018 02:24:23 +0000

Mario,

In reviewing the mailing list feedback on draft-gould-carney-regext-registry, I missed your feedback.  Thanks for taking the time to review draft-gould-carney-regext-registry and provide your feedback.  I provide responses to your feedback below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of Mario Loffredo <[email-masked]>
Date: Thursday, June 7, 2018 at 10:40 AM
To: Roger Carney <[email-masked]>, regext <[email-masked]>
Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

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.
Good point that draft-gould-carney-regext-registry may not properly support defining the policies for a zone that supports hostAddr instead of hostObj in RFC 5731.  We’ll take a closer look at how hostAddr can be supported in draft-gould-carney-regext-registry including the XML schema definition of maxCheckHost.

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.

It would be good to understand how custom statuses are supported to effectively define the policy for custom statuses.  Can you provide a description of how custom statuses are supported?  You are correct that the supportedStatusType is not an enumerated type, so therefore any status can be included.

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" ?

Yes, adding “or transferred” to the description makes sense for the auto-renew grace period.

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.

Good point, we can put some thought into how to define this.

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 nth 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".

The schedule format was our first attempt, so we can consider your proposal as well.

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

I’m unsure what you mean by “mapping of the possible extensions described in RFC 5730”.  Can you describe this a little more?

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 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]> [mailto:[email-masked]]
Sent: Thursday, May 31, 2018 3:12 PM
To: Roger D Carney <[email-masked]><mailto:[email-masked]>; Lin Jia <[email-masked]><mailto:[email-masked]>; James Gould <[email-masked]><mailto:[email-masked]>; Roger D Carney <[email-masked]><mailto:[email-masked]>; Jody Kolker <[email-masked]><mailto:[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

_______________________________________________

regext mailing list

[email-masked]<mailto:[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]<mailto:[email-masked]>

Phone: +39 050 3153497

Web: http://www.iit.cnr.it/mario.loffredo

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 16 Jul 2018 09:13:45 +0200

On Mon, Jun 11, 2018, at 15:48, Gould, James 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? 

I have two reasons for this.
The first one being that the XML document in itself can be useful, outside of the EPP protocol and design over how messages are exchanged.
If all (core + extensions) policies of a given registry are in one and some document, registrars can use it, for example, to process it and generate some code based on it. The XML document in this case, that is without any structure coming from EPP, could evevn be distributed out of band (one may argue that EPP being a *provisioning* protocol it is not the best to just send information and while you define the <create> command on this new structure, I doubt many EPP clients will implement or need to implement it).

The second reason is structure.
You decided to have domain/host/contact as "top" structure, hence mimicking the  3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC are their own RFCs and while they are purely related to domain names, it would not look strange to me that they are top elements themselves, like I wrote each RFC and/or namespace could be a top element grouping policies related to it.

This would also simplify the whole <registry:services> content.

> 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.      

I will try to do that based on other discussions of this draft, to see where the consensus goes to.

>     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.
> 
> JG - The schedule can certainly be enhanced.  Can you propose an 
> alternative structure to define it?      

The current example

   <registry:batchJob>
     <registry:name>pendingDelete</registry:name>
     <registry:description>Pending Delete Batch
     </registry:description>
     <registry:schedule tz="EST5EDT">0 14 * * *
     </registry:schedule>
   </registry:batchJob>

could be with ISO8601:

   <registry:batchJob>
     <registry:name>pendingDelete</registry:name>
     <registry:description>Pending Delete Batch</registry:description>
     <registry:schedule>R/14:00:00-05:00/P1D</registry:schedule>
   </registry:batchJob>

The EDT/EST switch may be a problem and would need two intervals maybe,
each for 6 months during the year (this can be done by start and stop date of the ISO8601 format)

On a related note, there may be a need here to also encode things such as: contacts not linked for 30 days are deleted from system
(which means processes that can not be anchored at a specific time)

>     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.
> 
> 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 still think it is simpler to have UTC everywhere, this also makes registries fully aware that their operations are indeed international because some of their registrars may really be from the opposite side of the world.

But at least as long as the timezone is mandatory (and non ambiguous, which means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a step in the good direction.

>     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>.
>  
> 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.   

My problem is probably exacerbated by the use of "registry" as namespace alias. I believe both the name of the extension and hence its XML namespace should be changed.

>     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.
> 
> 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.    

I think it would be important to specify the type of the regex that are used.
Unfortunately, like I said, I am not sure all cases should be able to be expressed, especially with all kinds of regex engine.
Some registries are rules such as: this character can only appear after this one. While it could be put in a regex, the combinations can explode very fast.
     
You have the same problem with reservedNames: sometime it is just not a static list but can have things like "any domain starting with ac- is reserved".
It can also be included by reference and not listed like: list of all cities in the country.

You may also have separate types of reserved names: some can not be registered at all, and some can be registered but with additional procedure about eligibility. This distinction may need to be conveyed.

\w and \d may also be ambiguous as locale dependent (or not, depends on language and regex flavor I guess), so in case of IDNs that is a problem.

>     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.
> 
> 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.

Unfortunately I still think that the whole <registry:idn> part is a rewrite of what LGRs do, with less features. If they are deemed too complicated this means either that the features they have are not needed by registries or that we are trying to implement a subset of them.

In short, I feel uneasy to just forget them and saying we will reimplement part of them differently.

This would also mean that the same things (IDN handling) can be coded in two different ways: through your extension and through LGRs.
Questions will arise about this.

>     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)
> 
> JG - Is this the case?  If so, you are correct that they would need to 
> be separated.  

Yes, some registries do not allow IPv6 values at all, and some will have different limits for IPv6 or IPv4.
     
>     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)
> 
> 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.

Except if that changed, TRAVEL for example allowed either INT only, or INT+LOC together, but not LOC alone.
Such kind of things can not be encoded with the above parameters.

>     - 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).
>   
> JG -  That's interesting since in RFC 5733 the contact ID is client-
> specified.  

It is *very well* spread in ccTLDs, whatever the RFCs say.
The client can indeed specify whatever it wants (or some registries may impose a specific value), but the registry will ignore the value and just return the one allocated in the creData section of the contact:create reply.

This is the case in .FR for example. Or .EU

> 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. 

Agreed but with the risk that even less registries will deem it useful to use your extension if they are not able to encode their current business policies in it.

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

RFC 5731 section 3.2.5:
A <domain:null> element can be used within the <domain:authInfo> element to
remove authorization information.

And associated schema:
   <!--
   Allow the authInfo value to be nullified by including an
   empty element within the choice.
   -->
   <complexType name="authInfoChgType">
    <choice>
      <element name="pw" type="eppcom:pwAuthInfoType"/>
      <element name="ext" type="eppcom:extAuthInfoType"/>
      <element name="null"/>
    </choice>
   </complexType>

>From my notes, and except if it changed recently, .NO uses this feature.

Related to passwords, I think there is nothing about the EPP one (client login).
But you have things like that:

- some registries mandate it to be changed on first login
- some registries mandate it to be changed at least in some frequence (ex: each 183 days).

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 16 Jul 2018 12:54:31 +0000

Patrick,

My replies 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 7/16/18, 3:14 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

JG - The elements included in the draft ("top" structure) are directly associated with the existing mature EPP RFCs.  New EPP extensions (drafts and RFCs) that are defined can include or be associated with new policy extensions of the registry object.  The entire EPP command and response is a full XML document, so I don't see any advantage to creating a new extensibility point within the registry mapping to put policy extensions under the <registry:infData> element.  We should use the extensibility mechanism that is already defined in EPP.  

    
    
    The current example
    
       <registry:batchJob>
    
    could be with ISO8601:
    
       <registry:batchJob>

    
  JG - I believe the format of the schedule is a good area for discussion, since use of the cron format was simply the first attempt.  Yes, policy associated with deletion of unused (unlinked) objects (contacts and hosts) is a good topic for inclusion.  

    

JG-Yes UTC everywhere would make things simpler, but the reality is that there are registries that do run batches based on the local time zone.  

JG-We can agree to disagree on this one.  Hopefully use of "registry" will grow on you, but we'll see how things progress.

         

JG-The goal is not to define every possible registry naming rule in the wild today, but to enable the definition of a policy that can be automatically consumed.  A registry should be able to express their naming rules via a regular expression, and if not I would question the policy.   IDNs do represent a unique issue to domain name registries, so we will need to consider how to effectively represent them.  For reserved domain names, we could look to include support for a regular expression as well as a static value for the <registry:reservedName> element.    

    

JG-The registry mapping contains a lot of feature and policy information, so we want to ensure to keep it as simple as possible.  Pulling in LGRs seems too complex to me to meet the need.  

JG - I would like to hear from the registries that do have separate policies for IPv6 and IPv4.  If that is the case, then they would need to be separated.  

 
JG-So TRAVEL makes "int" required and "loc" optional.  Maybe this could be represented by adding "intOptLoc" or something like that.  We can rethink how this is represented if the options get too complex.

    
    
JG-This is something to consider; although this is out of line with RFC 5733.

JG-There is a fine line of making the registry mapping too complex to meet one-off policies.  I would like the registries of these one-off policies to review the draft and provide feedback and proposals of how to meet their policies.

    RFC 5731 section 3.2.5:
    
    And associated schema:
       <!--
     
JG - Thanks for the reminder on the use of <domain:null/> to remove the authInfo.  Yes, we should include something associated with the support for this.      

    

JG-I have a login security policy extension in the works that is associated with draft-gould-regext-login-security that will define login policies like this.  We could merge some of this into the base as well.    

    -- 
      Patrick Mevzek
      [email-masked]
    
    [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 16 Jul 2018 17:11:22 +0200

Hi James,
my  answers to your questions are below.

Regards,
Mario

Il 16/07/2018 04:24, Gould, James ha scritto:
>
> Mario,
>
> In reviewing the mailing list feedback on 
> draft-gould-carney-regext-registry, I missed your feedback.  Thanks 
> for taking the time to review draft-gould-carney-regext-registry and 
> provide your feedback.  I provide responses to your feedback below.
>
> —
>
> JG
>
>
>
> *James Gould
> *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> *From: *regext <[email-masked]> on behalf of Mario Loffredo 
> <[email-masked]>
> *Date: *Thursday, June 7, 2018 at 10:40 AM
> *To: *Roger Carney <[email-masked]>, regext <[email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] New Version Notification for 
> draft-gould-carney-regext-registry-00.txt
>
> Hi Roger,
>
> 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
> Good point that draft-gould-carney-regext-registry may not properly 
> support defining the policies for a zone that supports hostAddr 
> instead of hostObj in RFC 5731.  We’ll take a closer look at how 
> hostAddr can be supported in draft-gould-carney-regext-registry 
> including the XML schema definition of maxCheckHost.
>
>
>
> 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.
>
> It would be good to understand how custom statuses are supported to 
> effectively define the policy for custom statuses.  Can you provide a 
> description of how custom statuses are supported?  You are correct 
> that the supportedStatusType is not an enumerated type, so therefore 
> any status can be included.
>
>
In the same way the rgpStatus of RGP extension is supported. Usually, 
due to local regulations, custom statuses are applied to domains and 
affect the set of operations a client can request. I think that the 
Registry Mapping extension would be very helpful if servers could 
provide clients with a formal description of the operations clients are 
allowed to request on a domain according to their statuses, no matter 
the statuses are standard or custom. IMHO, the only reference of the 
extension declaring the custom statuses in the registry:svcExtension 
element would not be enough.
I hope this could clarify my previous statement.

> 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:
>
> –7 to –1 (a negative number means the /n/th day or days before the end 
> of the month). For example: dayOfMonth="–3".
>
> 6) Finally, I hope that in the future the draft will address the 
> mapping of the possible extensions described in RFC 5730.
>
> I’m unsure what you mean by “mapping of the possible extensions 
> described in RFC 5730”.  Can you describe this a little more?
>
>
This answer is strictly related to the previous one of point 2. 
According to RFC5730 there could be three kinds of extensions.  By the 
term "extensions", I mean both the custom extensions (applied only to a 
specific registry) and  new standardized extensions (completing in the 
future the standardization process). Both could deeply affect the server 
policy.
Just to give you an example,  the Login Security extension is currently 
under the WG evaluation. If it will complete the standardization track, 
it will heavily affect clients authentication for those servers that 
will implement it. Clients should be able to catch which kind of 
authentication method servers support (i.e only the standard method, 
only the login security method, both). So I don't think that it would be 
enough to deal with it by simply putting it in the registry:svcExtension 
element.
As an example of a custom extensions, I know many European ccTLDs 
requiring additional properties for those contacts that will be 
referenced as registrants in domain registrations. If a client don't
provide them when creating the registrant, the domain cannot be registered.
Please, don't misunderstand me, I don't want to provide a method to 
increase the number of custom extensions. For interoperability reasons, 
it is always be better to have a standardization process for those 
extensions that could be potentially applied to all the EPP servers. 
Anyway, custom extensions exist and we should face with.

I have an extra question:
Does it make sense to specify in Registry Mapping the transport protocol 
supported by the server?

>     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
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     To: Roger D Carney <[email-masked]>
>     <mailto:[email-masked]>; Lin Jia <[email-masked]>
>     <mailto:[email-masked]>; James Gould <[email-masked]>
>     <mailto:[email-masked]>; Roger D Carney <[email-masked]>
>     <mailto:[email-masked]>; Jody Kolker <[email-masked]>
>     <mailto:[email-masked]>
>     Subject: New Version Notification for
>     draft-gould-carney-regext-registry-00.txt
>
>     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:
>
>     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
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
> E-Mail:[email-masked] <mailto:[email-masked]>
> Phone: +39 050 3153497
> Web:http://www.iit.cnr.it/mario.loffredo

E-Mail: [email-masked]