Patrick, My replies 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 7/16/18, 3:14 AM, "regext on behalf of Patrick Mevzek" <[email protected] on behalf of [email protected]> wrote: On Mon, Jun 11, 2018, at 15:48, Gould, James wrote: > 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? I have two reasons for this. The first one being that the XML document in itself can be useful, outside of the EPP protocol and design over how messages are exchanged. If all (core + extensions) policies of a given registry are in one and some document, registrars can use it, for example, to process it and generate some code based on it. The XML document in this case, that is without any structure coming from EPP, could evevn be distributed out of band (one may argue that EPP being a *provisioning* protocol it is not the best to just send information and while you define the <create> command on this new structure, I doubt many EPP clients will implement or need to implement it). The second reason is structure. You decided to have domain/host/contact as "top" structure, hence mimicking the 3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC are their own RFCs and while they are purely related to domain names, it would not look strange to me that they are top elements themselves, like I wrote each RFC and/or namespace could be a top element grouping policies related to it. This would also simplify the whole <registry:services> content. JG - The elements included in the draft ("top" structure) are directly associated with the existing mature EPP RFCs. New EPP extensions (drafts and RFCs) that are defined can include or be associated with new policy extensions of the registry object. The entire EPP command and response is a full XML document, so I don't see any advantage to creating a new extensibility point within the registry mapping to put policy extensions under the <registry:infData> element. We should use the extensibility mechanism that is already defined in EPP. > 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. I will try to do that based on other discussions of this draft, to see where the consensus goes to. > 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? The current example <registry:batchJob> <registry:name>pendingDelete</registry:name> <registry:description>Pending Delete Batch </registry:description> <registry:schedule tz="EST5EDT">0 14 * * * </registry:schedule> </registry:batchJob> could be with ISO8601: <registry:batchJob> <registry:name>pendingDelete</registry:name> <registry:description>Pending Delete Batch</registry:description> <registry:schedule>R/14:00:00-05:00/P1D</registry:schedule> </registry:batchJob> The EDT/EST switch may be a problem and would need two intervals maybe, each for 6 months during the year (this can be done by start and stop date of the ISO8601 format) On a related note, there may be a need here to also encode things such as: contacts not linked for 30 days are deleted from system (which means processes that can not be anchored at a specific time) JG - I believe the format of the schedule is a good area for discussion, since use of the cron format was simply the first attempt. Yes, policy associated with deletion of unused (unlinked) objects (contacts and hosts) is a good topic for inclusion. > 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 still think it is simpler to have UTC everywhere, this also makes registries fully aware that their operations are indeed international because some of their registrars may really be from the opposite side of the world. But at least as long as the timezone is mandatory (and non ambiguous, which means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a step in the good direction. JG-Yes UTC everywhere would make things simpler, but the reality is that there are registries that do run batches based on the 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. My problem is probably exacerbated by the use of "registry" as namespace alias. I believe both the name of the extension and hence its XML namespace should be changed. JG-We can agree to disagree on this one. Hopefully use of "registry" will grow on you, but we'll see how things progress. > 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. I think it would be important to specify the type of the regex that are used. Unfortunately, like I said, I am not sure all cases should be able to be expressed, especially with all kinds of regex engine. Some registries are rules such as: this character can only appear after this one. While it could be put in a regex, the combinations can explode very fast. You have the same problem with reservedNames: sometime it is just not a static list but can have things like "any domain starting with ac- is reserved". It can also be included by reference and not listed like: list of all cities in the country. You may also have separate types of reserved names: some can not be registered at all, and some can be registered but with additional procedure about eligibility. This distinction may need to be conveyed. \w and \d may also be ambiguous as locale dependent (or not, depends on language and regex flavor I guess), so in case of IDNs that is a problem. JG-The goal is not to define every possible registry naming rule in the wild today, but to enable the definition of a policy that can be automatically consumed. A registry should be able to express their naming rules via a regular expression, and if not I would question the policy. IDNs do represent a unique issue to domain name registries, so we will need to consider how to effectively represent them. For reserved domain names, we could look to include support for a regular expression as well as a static value for the <registry:reservedName> element. > 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. Unfortunately I still think that the whole <registry:idn> part is a rewrite of what LGRs do, with less features. If they are deemed too complicated this means either that the features they have are not needed by registries or that we are trying to implement a subset of them. In short, I feel uneasy to just forget them and saying we will reimplement part of them differently. This would also mean that the same things (IDN handling) can be coded in two different ways: through your extension and through LGRs. Questions will arise about this. JG-The registry mapping contains a lot of feature and policy information, so we want to ensure to keep it as simple as possible. Pulling in LGRs seems too complex to me to meet the need. > 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. Yes, some registries do not allow IPv6 values at all, and some will have different limits for IPv6 or IPv4. JG - I would like to hear from the registries that do have separate policies for IPv6 and IPv4. If that is the case, then 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. Except if that changed, TRAVEL for example allowed either INT only, or INT+LOC together, but not LOC alone. Such kind of things can not be encoded with the above parameters. JG-So TRAVEL makes "int" required and "loc" optional. Maybe this could be represented by adding "intOptLoc" or something like that. We can rethink how this is represented if the options get too complex. > - 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. It is *very well* spread in ccTLDs, whatever the RFCs say. The client can indeed specify whatever it wants (or some registries may impose a specific value), but the registry will ignore the value and just return the one allocated in the creData section of the contact:create reply. This is the case in .FR for example. Or .EU JG-This is something to consider; although this is out of line with RFC 5733. > 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. Agreed but with the risk that even less registries will deem it useful to use your extension if they are not able to encode their current business policies in it. JG-There is a fine line of making the registry mapping too complex to meet one-off policies. I would like the registries of these one-off policies to review the draft and provide feedback and proposals of how to meet their policies. > 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. RFC 5731 section 3.2.5: A <domain:null> element can be used within the <domain:authInfo> element to remove authorization information. And associated schema: <!-- Allow the authInfo value to be nullified by including an empty element within the choice. --> <complexType name="authInfoChgType"> <choice> <element name="pw" type="eppcom:pwAuthInfoType"/> <element name="ext" type="eppcom:extAuthInfoType"/> <element name="null"/> </choice> </complexType> JG - Thanks for the reminder on the use of <domain:null/> to remove the authInfo. Yes, we should include something associated with the support for this. >From my notes, and except if it changed recently, .NO uses this feature. Related to passwords, I think there is nothing about the EPP one (client login). But you have things like that: - some registries mandate it to be changed on first login - some registries mandate it to be changed at least in some frequence (ex: each 183 days). JG-I have a login security policy extension in the works that is associated with draft-gould-regext-login-security that will define login policies like this. We could merge some of this into the base as well. -- Patrick Mevzek [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
