Patrick, Thank you for this information. I provide feedback embedded below. Our goal is to address the crosscutting policy choices, so it's important to understand how many registries implement the policies (many, some, few, or just one), where "just one" or potentially a "few" may be best suited for the registry or registries to define a policy extension.
— JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/17/18, 3:38 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: Specific points related to RFC5730: * clTRID is optional; but some registries make it mandatory JG - Does this apply to all commands sent to the registry system or is it a policy that applies at the zone-level (e.g., .FOO requires the clTRID but .BAR does not require the clTRID)? The reason that I ask is to determine where such a policy would be defined at the system-level or at the zone-level. How many registries implement this policy (many, some, few, or just one)? * some registries do not allow some commands, like contact:transfer being not implemented (this is very frequent) or even sometimes contact:check (especially if registrars do not control their IDs), or other operations. Should that be specified somehow? JG-yes, I can see this. I assume this policy would be classified as "many". It may make sense to add a <registry:supportedCommands> element that supports an "all=<boolean>" attribute along with a list of sub-elements to identify which commands are supported. Such an element would be used under each of the objects (domain, host, contact). In draft-gould-regext-launch-policy, the policy associated with the check forms and create forms supported by the zone kind of matches this use case for the operations supported by RFC 8334. * for domain:info you have the hosts boolean with 3 values, not all registries are supporting all 3 cases. JG- How many registries implement the policy of support for a subset of the "hosts" values in RFC 5731 (many, some, few, or just one)? If this needs to be added, I would imagine that we would need to include a list of the supported host values; although this is certainly not compliant with RFC 5731. * also, some commands, like updates may always be asynchronous (return code 1001), should that be specified? JG-I believe it's good enough to include "pendingUpdate" in the list of <registry:status> sub-elements of the <registry:supportedStatus> element. The client then knows that an update may result in a pendingUpdate. * for authInfo: <registry:authInfoRegEx>: The OPTIONAL regular expression used to validate the domain object authorization information value. I do not think again that a regext will solve all problems. For example some registries say: with at least one uppercase and one digit and one "special" character. This is hard to express in a regex as the position does not matter. JG-A regular expression can precisely define the required syntax. Yes it may be hard, but a client can directly pull the regular expression for execution on their side. I would like to hear from a registry that can't express their policy without the use of a regular expression. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
