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

From: Patrick Mevzek <[email-masked]>
Date: Fri, 10 Aug 2018 00:07:43 +0200

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

Another way of encoding that, without judging myself if it is good/bad/better or worse than others but just to open horizons and see what is out there since I just stumbled upon it for unrelated reasons, is the systemd way, as described on 
https://www.freedesktop.org/software/systemd/man/systemd.time.html

With this example:

Thu,Fri 2012-*-1,5 11:12:13

The above refers to 11:12:13 of the first or fifth day of any month of the year 2012, but only if that day is a Thursday or Friday.

HTH,

-- 
  Patrick Mevzek
  [email-masked]

---

From: Pieter Vandepitte <[email-masked]>
Date: Fri, 10 Aug 2018 07:23:36 +0000

Did anyone consider RFC 6321 (xcal)? It has features like recurrences too. A maintenance event is basically just a calendar event + some data about the scope/context...

Kind regards

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>

On 10/08/18 00:08, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    
    With this example:

    
    HTH,
    
    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Fri, 10 Aug 2018 16:05:24 +0000

Mario,

Sorry again for not replying to your message earlier.  I’m capturing the issues that are raised for draft-gould-carney-regext-registry in the GitHub project (https://github.com/james-f-gould/EPP-Registry-Mapping/issues).  I provide replies to your feedback embedded below.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: Mario Loffredo <[email-masked]>
Date: Monday, July 16, 2018 at 11:11 AM
To: James Gould <[email-masked]>, Roger Carney <[email-masked]>, regext <[email-masked]>
Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

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

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

From: regext <[email-masked]><mailto:[email-masked]> on behalf of Mario Loffredo <[email-masked]><mailto:[email-masked]>
Date: Thursday, June 7, 2018 at 10:40 AM
To: Roger Carney <[email-masked]><mailto:[email-masked]>, regext <[email-masked]><mailto:[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.

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.

JG – I believe custom statuses and mapping the custom statuses to the prohibited operations would be up to a custom server policy extension.  As captured in the GitHub issue (https://github.com/james-f-gould/EPP-Registry-Mapping/issues/3), where I recommend adding SHOULD normative language into the draft and to keep the XML schema supportedStatusType non-enumerated to support custom statuses.  The language for the supported statuses would read as follows:

"The OPTIONAL set of supported domain statuses that SHOULD match the statuses defined in [RFC5731]."
"The OPTIONAL set of supported host statuses that SHOULD match the statuses defined in [RFC5732]."
"The OPTIONAL set of supported contact statuses that SHOULD match the statuses defined in [RFC5733]."

Does this match what you’re looking for in addressing the issue?
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?

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.

JG – Extension specific policies would be captured in Registry Mapping policy extensions like how draft-gould-regext-launch-policy defines zone-level policies associated with the Launch Phase Extension (RFC 8334).  The EPP extensibility mechanism can be used to define EPP extension policy extensions that are either at the zone-level (e.g., draft-gould-regext-launch-policy) or at the system-level (e.g., Login Security Policy Extension).  Registries that have custom zone-level or system-level policies can define them in a custom Registry Mapping policy extension.  I don’t want to create two extensions (extension and policy extension) for every EPP extension.  In the future the extension and the policy extension could be included in a single draft, but in the meantime they would be separate.  Does this address your concern related to the policy extensibility mechanism?

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

JG – Right now the Registry Mapping is co-located with the specific service on the chosen transport (TLS, HTTPS, and other), meaning it does not provide an endpoint discovery service.  There is no concept of an aggregate service Registry Mapping that includes all of the endpoints available; although something similar could be created.  I would view it as a separate goal.

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

--

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

--

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