* 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.
* 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)
- 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
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?
* 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.
--
Patrick Mevzek
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
