Patrick, Thank you for your review and feedback. My comments are embedded below. — JG
James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/9/18, 3:39 AM, "Patrick Mevzek" <[email protected]> wrote: On Fri, Jun 1, 2018, at 17:16, Roger D Carney wrote: > 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! Some quick remarks before trying to implement it and hence reviewing it more in depth later. First I think it is an important concept (auto-discovery), whatever the implementation is. It would be most useful if deployed by multiple registries, also outside of gTLDs, so even if not technical some outreach should be done to try finding registries willing to participate and/or deploy it later. So that during desigining no spots are missed. Also I think this is an extension that needs itself to be extended. I have seen the other document about the launchphase policies but I think the model should be different, so that extension data is still inside the <registry:infData> node. JG - Why does the extension data need to reside within the <registry:infData> node? EPP already has an extension mechanism that can be used, so why not use it in this case? The Registry Mapping defines a Registry object with two separate sub-objects, which include Zone and System. The Zone represents the RFC policies for an individual zone supported by the Registry. The System represents the policies of the Registry System. The Registry Mapping provides the base to define zone-level (e.g., Launch Phase Policy Extension or Registry Fee Policy Extension) or system-level (e.g., Login Security Policy Extension) extensions using the existing command / response EPP extension mechanism. Here is an outline of what I thought, so names are just examples: among the nodes there would be a <policy> one with a "for" attribute whose value would be the XML namespace of the extension concerned by the policies that will be described inside this policy node. So infData will be mostly a list of <policy> nodes. The core document would define the blocks for RFC 5730 to 5733 (and maybe also RGP and DNSSEC) and then each other extension would define their own block content. Also, using the XML namespace as identifier may not be always possible: all policies regarding transport are in RFC5734 which has no XML namespace per se. So maybe instead of the XML namespace you could use the RFC number or the interne-draft name. In the long run if all of this work (independ of the specific implementation details) I would think at least an update to RFC3735 would be welcome that could add: * IANA registration in the EPP registry is mandatory * and description of the policy of the extension described must exist and conform to this document standard. JG - Maybe you can provide some sample XML that combines the policy for a Registry Zone that supports what is in the Registry Mapping and in the Launch Phase Policy Extension to help understand your proposal. More specifically now, about "2.3. Schedule" I am *strongly* against using the format proposed for at least 2 reasons: - crontab format is not a standard, and is ambiguous for various points - it encodes a format as a string which is itself in a formatted structure since it is XML. "Hijacking" some free form space when you are in formatted structure seems wrong to me and shows that the structure is not correctly formatted because if it were you would not have to inject a new format in a free text. Why not use ISO8601 Repeated Time Interval format? We are then still gulty of the previous point but at least it is a standard. Otherwise please amend the XML structure to break the content currently in the crontab format. JG - The schedule can certainly be enhanced. Can you propose an alternative structure to define it? As for timezones, all EPP standards always used UTC for all timestamps (and even if some registries on the field do not respect that), and I think it would be best to stick to that, so that removes the "tz" attribute. JG - Yes, that is the case for communicating dates (create date, expiration date), but not the case when it comes to defining a schedule for a batch component that runs based on a local time zone. I find this unfortunate: <registry:name>: The zone name that can be at any level When you parse it, you read it as "a registry name", but then it is a zone. So while it could probably not be <zone:name> it should at least be <registry:zoneName>. JG- The label name could be changed, but I believe the most important item is the meaning of the element. Since the <registry:name> element is a sub-element of the <registry:zone> element, wouldn't it be redundant to replicate the zone in the label (<registry:zoneName>) or the namespace (<zone:name>)? I don't believe defining a new namespace will help here. I believe leaving it as <registry:zone><registry:name>EXAMPLE</registry:name>...</registry:zone> with a description of the <registry:name> element as meeting the need. You are speaking about "regex" in various places without referencing how is this formatted. There are multiple de facto regex "standards" so care must be taken there to reference precisely what kind of regex are manipulated. Also, for example for passwords, some registries policies are not possible to express (only) in regex I think, so there might be a blind spot here. JG - Do you have a proposal of how to precisely define the regex? I'm looking for the other registries to review the draft and weigh in on how they can effectively communicate their policies. alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported and maybe others (all the IDNs ones) should be removed and instead LGRs (RFC7940) should be used/referenced: far more complicated but at least you cater for all cases. JG - I agree that this would get much too complex for what we're attempting to solve here. The alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported elements are booleans that clearly define registry policy on what can be supplied. I would like to know about the registry policies that go beyond these booleans and the regex element. For IP addresses (min/max) you may need to separate between IPv4 and IPv6 as some registries may impose different constraints to each (including: IPv4 allowed but not IPv6) JG - Is this the case? If so, you are correct that they would need to be separated. For contacts: - I think the design around int/loc policy does not capture all cases. Some registries allow int only; some loc; some int only or int+loc, some loc only or int+loc, some int only or loc only or int+loc, etc. (I am not saying all combinations exist, but there are at least more than one of them so we need to be able to handle that) JG - I'm looking for the other registries to identify whether their policy can be reflected with the "loc", "int", "locOrInt", or "locAndInt" <registry:postalInfoTuypeSupport values. If not, I would like to know why and how it can be changed to support their policy. - for the contact ID some registries let the registrars choose it (per the RFC5733 spirit) but some do not and just choose instead of them; it should be possible to encode this in the policy; there may also be the need to encode that in some cases the prefix of contact ids is not free, but fixed per registrar; maybe a need too to define what happens when 2 registrars try to create the same contact ID, depending on if they are global to the system or local to each registrar (the ROID would be different of course). JG - That's interesting since in RFC 5733 the contact ID is client-specified. I'm sure this is not the first case where registry policy is not following the RFC, so we need to be careful in trying to support one-off policies that are not in line with the RFCs. With that in mind, if this is a general case, draft-gould-carney-regext-registry can certainly be updated to define the various general policies. We just need to be careful. Other things that would be useful to include (and could be done "easily" if you take my ideas on top to have blocks identified by the underlying XML namespace or RFC number): - data related to transport: number of connections, timeouts (soft and hard), recommended frequency of keepalive, etc. JG - This policy information is supported with the <registry:system> child element of the registry info command and the resulting <registry:system> element in the registry info response. Is there any attribute that is missing? - data related to sessions: password policies (maybe both for registrar login and for domain authInfo) which go further than just regex you may want to code about lifetime of a password, and the sets/classes of characters allowed and their use (like mandatory one uppercase character, one lowercase, one "special", etc.), etc. JG - The Login Security Extension (draft-gould-regext-login-security ) can have an associated Login Security Policy Extension that fully defines the password policies you outline. For domain passwords, is <domain:null> allowed? JG - I know nothing of the use of <domain:null>, so I would be interested to further understand it. (an arcane part of the standard that I know one registry does) Also/maybe: - various rate limiting (per command or not, etc.) - various hitpoints mechanism (ex: 1 hitpoint per EPP error, cut of all write operations after X hitpoints, for X days or token bucket like operations) - data about notification messages: how long are they kept in the queue? What happens at end of lifetime? - "extended" error codes used Finally, as bikeshedding as it may seem, I am not convinced that "Registry Mapping" is the correct naming here. The abstract talks about zones, features and policies. All other EPP standards talks about server and client, not about registry and registrar. I would favor changing the name of the extension and removing Registry from it. I lack good suggestions for now, maybe later. Policy Mapping? Metadata? Zone Metadata? -- Patrick Mevzek _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
