On Sat, Jan 06, 2018 at 08:01:02PM +0100, Patrick Mevzek <p...@dotandco.com> wrote a message of 77 lines which said:
> as soon as we add one RR through EPP, as James stated there is the > question about all others. Yes, and I clearly do not want to go into that: too complicated for me. > There is even already an extension for that. It had URN > http://www.verisign.com/epp/zoneMgt-1.0 and I have the code > implementing it in my client, but I do not find it anymore on > Verisign website. It is not in the IANA EPP extensions registry either. > * I would like to see more explanations on what happens if a registrar adds a > DNAME > on an existing domain name that have in-bailiwick nameservers and hence glues > in registry > zonefile. Should the change be forbidden (until the registrar > removes the nameserver objects) or just the glues just be removed? > Then should the nameserver object be deleted too automatically? There is also the fact that not everybody uses RFC 5732. Added as #7 <https://framagit.org/bortzmeyer/ietf-epp-dname/issues/7> > * Also what happens if the DNAME target is internal to the registry > (same TLD)? Should the registry check the domain exists? What if > the target has a DNAME record too? Added as a MAY, like for the DNS tests <https://framagit.org/bortzmeyer/ietf-epp-dname/commit/19875dbdfdc04c24ed26a0d5085147727f34673e> > I fear this can very soon go into the same rabbit-hole as the case > of DNSSEC enabled transfers, and then you have only answers like the > keepDS solution in frnic extension, or something along the standard > keyRelay extension. Yes. I do not intend to develop a new mechanism. Either the registry policy forces all the clients to handle a set of mandatory extensions, or we reuse the DNSSEC hacks. > * I have mixed feelings about section 10. It is copy-and-paste for RFC 5910, which is on the standards track. > * On issue #3 and the issue of feature discoverability per domain, I > do not think the EPP check command is appropriate for that. The > DNAME record is not an object per se in the registry data model and > hence no operations would apply to it. The idea was not to use the DNAME record as the object but the domain name, with an extension. Something like: <domain:check <domain:name>example.com</domain:name> <dnameDeleg:if>foo.bar.example.net</dnameDeleg:if> </domain:check> But I agree it is not necessary: > I fear right now the best way is for a registrar to just try its > create/update and mandate that the registry has a clear error essage > in its answer I agree. > * On issue #5 I would prefer it stays with EPP terminology, so > update+chg (not set) nodes. Noted. > * On issue #6 I feel it not necessary for the client to explicitely signal it > wants the info back for the following reasons: I agree also. > If you really want to signal no data in all cases, you can also > reply with an empty dNameTarget Note that it is not permitted if we switch from EPP string to eppcom:labelType. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
