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]> on behalf of Mario Loffredo <[email protected]> Date: Thursday, June 7, 2018 at 10:40 AM To: Roger Carney <[email protected]>, regext <[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. 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 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
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
