On 08/07/2011 5:18 PM, Joe Abley wrote:
On 2011-07-08, at 14:03, Stephen Morris wrote:
If the answer is yes, then the CDS approach is certainly one to be
looked at. The answer also suggests that we should be looking at an
equivalent mechanism for updating NS (and possibly glue) information in
the parent zone. Perhaps all can be done under a single framework?
If that's the direction we're looking in, then delegation scaffolding (NS and DS) seems
like just the beginning; perhaps we need to consider the possibility of zone managers
pushing signed registry ("whois") metadata from the DNS back into the registry
as well. I'm not convinced that's sensible, but it seems helpful to find out how deep the
rabbit hole goes if we want to properly scope the problem space.
Just let Whois die a peaceful death, it serves no purpose other than
make work.
A zone -> registry data flow might at least provide some incentive for DNSSEC
deployment, if it represented a simplification for the registry interaction
required by DNS service providers.
On the other hand, if this is an effect a short-cut between registry and
registrant (or by the registrant's agent, in the case of third-party
signing/hosting of zones) then we might discover that it's contractually
infeasible for any gTLD registry to support.
As I mentioned in my prior post to dnsop,
Parent != Registry in the RRR world.
There is no reason why the registrar can not perform this "scan"
and update the registration information.
The biggest beneficiary in the RRR world is the external DNS operator
that currently has to funnel DNS information via the registrant.
If the answer is no, then along with publishing a mechanism for the
automatic update of DS records, should we be providing guidance on when
to use that and when to use EPP/Web/Email?
Don't get me wrong, I don't want any unnecessary delay. But if it turns
out that what is being addressed is part of a larger problem, it's worth
looking first to see if there is a general solution.
+1
+1
IMHO this is a no-brainer once we agree on few constraints:
a) only applies to normal changes
b) delay of few days/weeks is acceptable
Thus:
New registration is not covered.
Emergency operations are not supported
Transfer is not explicitly supported, but at the same time not
prevented.
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
