Patrick, Again, thanks for providing the detailed information. I provide my feedback embedded below. — 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:41 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: * contacts, the extension has: <registry:contact>: Zero or more <registry:contact> elements that defines the minimum and maximum number of contacts by contact type. This will not cover all cases, like those: - admin contact is optional and falls back to registrant - since you allow for custom type (and I disagree with that here), some registries have other contact types, let us say "other" and have rules like: at least one contact of type technical or other. JG-Can you provide a propose of how to define this? The use of "custom" is a pattern that has been followed elsewhere to enable an extensible set of values. If a registry does have "other" or "custom" contact types, they can fully define the min and max policies for their custom contact type. * about periods, there are 2 cases not handled: - something around maximum expiration date, like the ICANN rule on 10 years max and what happens for commands that would go beyond that (ex: create for 9 years and immediate renewal for 5) JG-What are the possible set of policies out in the wild? We clip the fractional period past the maximum year (10.5 years would become 10 years and attempting to go 11 or more years would fail). - how is the new expiration date computed after a transfer: for some registries it is like a start of a new contract, hence the expiration is the date of transfer + 1 year JG-You mean the transfer is not treated as a renewal and sets a new expiration date independent of the expiration date prior to the transfer? How many registries do this (many, some, few, or just one)? In the same way, sometimes a registrant change (often through a separate command) is deemend to be a new contract starting at the command time, hence it changes the expiration. How could we encode these expiration rules? JG-You mean a domain update can result in changing the expiration date if the registrant is changed? How many registries do this (many, some, few, or just one)? We may not include such a policy in draft-gould-carney-regext-registry, where this would be left to the registry to define their own policy extension. * about secDNS, one registry has this: keyData only, flags muts be 257, protocol 3 and any algorithm. While indeed protocol 3 is the only value possible, the secDNS extension could allow other value for flags even if 257 is the only one making sense, and the only one used in examples. Should we care to codify these limits? Things may be different with CDS/CDSNKEY, I am not sure. JG-We will need to take a closer look at this one. I don't have any immediate thoughts for this. -- 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
