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

["Gould, James" <[e-mail]>]

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

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

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

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

From: Mario Loffredo <[e-mail]>
Date: Monday, July 16, 2018 at 11:11 AM
To: James Gould <[e-mail]>, Roger Carney <[e-mail]>, regext <[e-mail]>
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

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

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

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

From: regext <[e-mail]><mailto:[e-mail]> on behalf of Mario Loffredo <[e-mail]><mailto:[e-mail]>
Date: Thursday, June 7, 2018 at 10:40 AM
To: Roger Carney <[e-mail]><mailto:[e-mail]>, regext <[e-mail]><mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, May 31, 2018 3:12 PM
To: Roger D Carney <[e-mail]><mailto:[e-mail]>; Lin Jia <[e-mail]><mailto:[e-mail]>; James Gould <[e-mail]><mailto:[e-mail]>; Roger D Carney <[e-mail]><mailto:[e-mail]>; Jody Kolker <[e-mail]><mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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

Phone: [phone]

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

Phone: [phone]

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