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]> 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.
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.
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 /n/th 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.
I have an extra question:
Does it make sense to specify in Registry Mapping the transport protocol
supported by the server?
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 5^th 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]
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
