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:[email protected]] James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Mario Loffredo <[email protected]> Date: Monday, July 16, 2018 at 11:11 AM To: James Gould <[email protected]>, Roger Carney <[email protected]>, regext <[email protected]> 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:[email protected]] James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <[email protected]><mailto:[email protected]> on behalf of Mario Loffredo <[email protected]><mailto:[email protected]> Date: Thursday, June 7, 2018 at 10:40 AM To: Roger Carney <[email protected]><mailto:[email protected]>, regext <[email protected]><mailto:[email protected]> 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 protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Thursday, May 31, 2018 3:12 PM To: Roger D Carney <[email protected]><mailto:[email protected]>; Lin Jia <[email protected]><mailto:[email protected]>; James Gould <[email protected]><mailto:[email protected]>; Roger D Carney <[email protected]><mailto:[email protected]>; Jody Kolker <[email protected]><mailto:[email protected]> 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 protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]> Phone: +39 050 3153497 Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
