Re: [regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04

[Matthew Pounsett <[e-mail]>]

Hi Patrick.  Thanks for your patience in waiting on a reply from me.. as I
mentioned in private email at the time you sent your mail, the
winter/spring has been a bit complicated.

Also, thanks very much for your thorough review.  I think we're still a
long way from a good Standards Track document... your suggestions echo my
thoughts on several things I'd like to fix, and bring up new ones I'd
missed.



On 22 December 2017 at 01:03, Patrick Mevzek <[e-mail]> wrote:

> Hello authors,
>
> Please find below my review of your draft.
> It mixes spellings/phrasing fixes and more formal questions/problems.
>
> * The title itself does not look like to me specific enough to the goal.
> Even more so as you finish the abstract with:
> "This same protocol can be used by Registrants"
> So it is not a "Third Party DNS Operator to ..." but something like a
> "Non-Registrar to ..."
>
> In short I am not good at this but I believe a better name can be found.
>
> Also further down you say:
> " For the purposes of this draft, a third-party DNS Operator is any DNS
>    Operator responsible for a zone, where the operator is neither the
>    Registrant nor the Registrar of record for the delegation."
>
> So at the end of the day it is not 100% clear if the intent is to be
> also used by registrants or not. I believe the whole document should
> be more clear on that and state only one case through the whole of it.
>

The draft is intended to patch the RRR environment to permit third-party
DNS operators to participate.  The fact that it could be used by a
sufficiently technically savvy registrant to automate their own operations
is considered a side-benefit, since they already have a means to submit DS
directly to their registrar, and have the choice to move to a registrar
that supports automation of DNSSEC setup (e.g. Gandi's registrant API or
any FRED-based registry that auto-scans for CDS/CDNSKEY).  Hence the almost
throwaway reference at the end of the abstract.

If you have a suggestion for how we could make that clearer I'd be happy to
consider text changes.

I share your misgivings about the title of the draft.  It doesn't read like
a protocol name to me, and I've been trying to think of something that
would be an improvement.  I haven't discussed this with my co-authors yet,
but I've been considering adding an RR application to the draft for
locating the entry point within a TLD.  It suffers from fewer potential
policy delays than an RDAP extension (both must get incorporated into ICANN
contracts for gTLDs, but RDAP seems like it's still suffering from
technical uncertainty) and a service discovery RR keeps this more within
the DNS.  However, doing so would require having a better service name than
we do now, so it could be adequately represented in an RR name.



>
> * Abstract
>
> I think it would be best to at least have a sentence explaining the goal
> before beginning to describe the current situation and its shortcomings.
> So that people reading it know where you are going to right at the
> beginning.
>

I think I see a way to rearrange the abstract for this.  Does this seem
better to you?

This document describes a simple protocol that allows a third party DNS
operator to: establish the initial chain of trust (bootstrap DNSSEC) for a
delegation; update DS records for a delegation; and, remove DS records from
a secure delegation. The DNS operator may do these things in a trusted
manner, without involving the Registrant for each operation. This same
protocol can be used by Registrants to maintain their own domains if they
wish.

There are several problems that arise in the standard
Registrant/Registrar/Registry model when the operator of a zone is neither
the Registrant nor the Registrar for the delegation. Historically the
issues have been minor, and limited to difficulty guiding the Registrant
through the initial changes to the NS records for the delegation. As this
is usually a one time activity when the operator first takes charge of the
zone it has not been treated as a serious issue.

When the domain uses DNSSEC it necessary to make regular (sometimes annual)
changes to the delegation, updating DS record(s) in order to track KSK
rollover. Under the current model this is prone to delays and errors, as
the Registrant must participate in updates to DS records. Implementation of
this protocol at the Registrar and/or Registry would eliminate the need for
a Registrant who is not normally involved in the technical operation of
their zone(s) from being required to become a participant in order to
secure them with DNSSEC.


It would be useful to be able to provide such examples or even some
> references,
> if they exist. Or at least types of failures, the kind of consequences
> they create
> and so what the protocol in the document could have solved.
> There is a sentence just after it about that but it gives one vague
> example where
> the sentence above has "many types of failures".
>

I think I can expand on this in the Introduction, rather than the Abstract
(which is already pretty long in my opinion).  I don't like the idea of
linking out to potentially-ephemeral examples on the web (news, etc.) but
we can certainly describe the types of failures that can occur in more
detail.


> * I am not convinced in the use of REST/REST-framework/REST-nomenclature
> for the exposed use case.
> The fact that all your exchanges (except one) do not need any content in
> the body
> (both in request and in reply) - but need multiple explanations in the
> protocol,
> and the fact that your two resources are not really resources handled at
> the
> server on which the client has any say show that your protocol is just a
> signaling
> one (the client signals the server that it has something to do, that
> happens completely
> outside of the REST setup) not something really letting clients act on
> resources
> stored on the server.


I don't follow your first point .. what do you mean by "multiple
explanation in the protocol"?


>
>
> However note that using POST/PUT/PATCH has consequences on property like
> idempotence
> and security of write operations, whereas a simple GET would work on your
> case,
> since it is a at its core a signaling protocol.
> This GET would also even work for token retrieval and would even be the
> more logical
> case.
>

You are correct that it is primarily a signalling protocol.  It exists for
Registrars and Registries that do not want to perpetually scan their signed
or unsigned delegations for CDS/CDNSKEY updates.  Even so, I don't think
that all the verbs here should be GET, since they are asking the server to
make a change.


>
> So is the REST setup really providing you any benefit here?
>

It's an existing framework we can use which implementers know how to work
with.  The alternative is to specify something entirely from scratch.


>
> * 2.1 You say CDS and CDNSKEY are like interchangable in the context of
> the protocol,
> so I would recommend to change the path of all endpoints in order to not
> have
> cds at the end, nor cdnskey but something more generic that would not be
> ambiguous.
> Maybe /dnssec simply ?
>

dnssec?  trust?  I see your point... and we'll think about what works as a
generic replacement for cds.  If you have other suggested words we can
consider please feel free to put them on the table.



> In the same train of thought you write later
> "the child DNS Operator needs to upload the DS record(s) to the parent."
> ... but some registries only work (accept from their childs) with DNSKEY
> data where
> they generate the DS records themselves.
> I recommend you rephrase there and everywhere below in the same context to
> have
> a more generic sentence that would apply to both DS-based and DNSKEY-based
> registries
> without having the need to repeat both cases each time.
>

That was why we simply said any instance of CDS could be read to include
CDNSKEY.  This is a common pattern in drafts that have this type of
either/or text which would otherwise be frequently repeated.  We did the
same thing with "Registration Entity" in order to avoid repeating the same
complex set of relationships every few paragraphs.


>
> * 3.1 Identifying The Registration Entity
>
> About the automated discovery of the base URL of the API, did you think
> about using SRV records at the parent? And/or URI or NAPTR?
>
> Would also well-known URIs (RFC5785) have something to offer here?
>

Initially we dismissed the general idea of inserting RRs into a TLD for
service discovery because of the issues surrounding gTLDs and the
ICANN-imposed limitations on what records they can put in their zones.
However, I'm starting to think that we should reopen that discussion
because I'm not convinced that our proposed RDAP extension will ever seen
the light of day, even assuming that RDAP gets widely adopted in the next
five years.

To that end.... I had a look at 5785 but didn't think it applied.  It's
more about where to find policy and other meta-data than a
service-discovery system.  SRV seems to be considered by many in the DNS
community to have been a mistake, as it tries to overload the namespace
with meaning that should be in the type.  Lack if implementation aside, URI
and NAPTR, applied to this use case, would suffer from the same problem as
SRV:  what meaning specific to this protocol could you infer from the query
`example/IN/URI`?  We'd have to overload the namespace to use them.

I'm left thinking we should register our own service discovery RR, after we
fix the naming problem so that we could come up with a reasonable RR type
name.  If we define the RR "FOO" for discovery of the entry point of this
service, then 'example/IN/FOO' is all you need to query for, and it
requires no additional explanation or processing.


>
> * 3.2 "Registration Entities MAY regularly scan the child name servers of
>    unsecured delegations for CDS records in order to bootstrap DNSSEC,
>    and are advised to do so."
>
> I have mixed feelings about the "are advised to do so." part for various
> reasons.
> While I can understand your intent, it seems to come out of the blue here,
> even more so as this point is not the core of the document and even
> further than
> that since you stipulate that if they were doing as advised the whole
> protocol
> described in the document would not be needed, except one point.
>
> If you really want to discuss that practice I believe you would need more
> data
> or recommendations like on timings (minimum/maximum periods, hardcoded at
> registry
> or depending on zone TTL, etc.)
>

Yeah, doing that scanning obviates the need for this protocol.  I think we
should move that recommendation up to the Introduction and use it as an
example of when you *shouldn't* implement this.



>
> Also, multiple registries do DNS checks after each change and go forward
> only
> if everything returns OK (from their very specific local list of tests).
> There may be a merit to discuss what happens when the child does some
> CDS/CDNSKEY
> changes that get automatically picked up by registry (for the one doing it
> like you advise) but then the DNS checks fails for whatever reason (example
> among many other possible cases: the child publishes a new CDS without
> publishing
> the corresponding DNSKEY in its zone), so no changes happen.
> How the third party/registrant get notified of that (besides not seeing its
> wanted change appearing on the registry level)?
>

What happens if they do that today?  That sounds like it either belongs in
the CDS/CDNSKEY draft, or to be left to EPP and the agreement between
registry and registrar.  I hesitate to write things into this draft that
have applicability beyond its use, and that sounds like something that
would affect all uses of CDS/CDNSKEY where a registrar might try to also
submit changes to the registry.




>
> * 3.3 same problem, you are adding something (the registry having to
> regularly
> scan the child zone for CDS records) that is not really part of this
> protocol
>

I agree.  I think that should be a MAY, not a SHOULD.  Would that fix your
concern?


> * 3.4
>
> I was thinking about the signatures lifetime of the records, maybe that
> should
> be checked by the parent, so that they do not expire "too soon" ?
>

What is "too soon"?  If an operator is signing on the fly, then the
signature lifetime doesn't need to be any longer than the TTL of the
RRset.  And again, this sounds like advice with general applicability to
all DNSSEC operations, and not just this protocol.  The Acceptance
Processing section is meant to describe how to validate that the request is
valid, not to test whether the downstream server is following every DNS
operations best practice.


>
> * 3.5 You suddenly use "Registration Entities" in plural for no reason as
> it was
> singular before. Maybe it should be consistently singular in the whole
> document.
>

This looks like a mistake.  I'll fix it.


>
> I find the test to be a little harsh: if I read it correctly if even one
> query
> timeouts among all of them done each 2 hours during a week (so 84*2 per
> nameserver
> to check both TCP/UDP) everything is reset back to its beginning. But
> network
> outages can happen and not necessarily under control of the DNS provider,
> and also
> the DNS service is available globally through the constellation of
> nameservers,
> not necessarily for one of them all the time.
>

The text is about the consistency of the response, not the quality of the
service, so I don't personally see the same implied restriction with regard
to timeouts.  Do you have a suggestion about how we could make that
clearer?  The intent here to to prevent an attacker from spoofing responses
from one or more servers in order to fool the parent into adopting the
wrong DS.  Since this option bootstraps trust from nothing we intend for
the tests to be extremely rigorous.


* 4 "It is up to the child to monitor the parent
>    for completion of the operation"
> While probably obvious to anyone I think it would not be bad to be even
> more
> explicit to re-iterate that this part is outside of the protocol you design
> here, as it is based only on DNS queries.
>

We can do that.


>
> Also: "This protocol is partially synchronous" I do not think this is a
> valid term here.
> You could maybe say that the server can decide to handle the requests
> either
> synchronously or asynchronously: in the first case it keeps the connection
> open
> during the time it processes the request, and in the second case it
> replies immediately
> telling the process is ongoing.
>

This sounds like a better way to phrase things, to me.


> In fact I doubt how it could be synchronously: when setting the trust
> relationship
> you imagine delays of a week for a registry to do its test, delay which is
> course
> incompatible with maintaining an HTTP connection open; but even in the
> other cases
> the registry may not be fully automated in real time for all its DNS
> publication
> so even if all the tests are successful the showing of the new DNS/DNSKEY
> records
> in registry zonefile may happen minutes or hours later, which again will
> prove
> difficult for synchronous operations, but even more than that probably
> unnecessary,
> as a simple signaling protocol, it can be purely asynchronous.
>
> In short what does having the two cases offer to the protocol?
>

I've had the same thought, but wasn't sure if it was worth mentioning.
Since someone else has noticed the same thing I'll bring it up with my
co-authors and see if we can change it.


> * 4.1 "or VPN"
>
> I am against these two words. I see no need for them and in the contrary
> their presence
> gives false promises by putting two things on the same level where they
> are not: even if using a VPN, the access would still need to use TLS. So it
> is clearly not an "or".
> Also there is some logical problems in your suite of explanations: you say
> the protocol
> does not need any unique authentication, and that TLS would be enough for
> that.
> Then you say people can use TLS _or_ VPN: so if using VPN what about the
> needed features
> of authentication? You do not say.
>
> In short, remove "or VPN" and all problems are solved.
>

The requirement is about authentication, not encryption.  There's nothing
sensitive sent across this protocol (as you noted earlier, it's simply
signalling) so the only thing to be gained here is certainty that the
client is connect to the right server endpoint, or possibly the reverse in
the case where the registration entity wants to have a more formal
relationship with operators that send them signalling.  An unencrypted VPN
between the DNS operator and the registration entity would provide that
assurance in both directions.

If there is text that you think would make that point clearer we'll be
happy to consider it.  I'll take a look myself to see if I can improve on
its clarity.


> * 4.2.1.1.1
>  I believe a PUT would be more REST-like in this case
> (kind of "creating" DS data at the registry for the object being the
> domain)
> than a generic POST (see my discussion previously)
>

POST was chosen there to differentiate it from the PUT request at 4.2.1.3.
If I recall correctly, I think we chose to do it that way because we felt
POST made more sense for new data, while the PUT made sense as a
modification to existing data.  That seems like a fairly arbitrary
distinction to me though, and if enough people feel it should be changed I
have no problem swapping them.


> (side note purely aesthetic: it is "strange" to have a so deep
> nomenclature with 5 levels for a document not so long, especially since
> other "top" section are only one or two sentences long, so it is unbalanced)
>

I don't disagree.  I have some style rewrites I want to do, and finding a
better way to break up these sections is on the list.


>
> * 4.2.1.1.2
>
> Right now 401 cover registry lock based on your earlier explanation.
> However a domain can also be in multiple other states that would deny
> changes on it,
> either temporarily or definitively, among others: other pending update
> operation
> (EPP status pendingUpdate), client has locked the domain
> (clientUpdateProhibited),
> domain is in some kind of blocked state due to a procedure on it (could be
> EPP status
> serverUpdateProhibited but contrary to the registry lock case this would
> be a case
> where the client can not change anything)
> It can also cover all cases if the registry adds authentication features
> like
> you describe in 4.1
>
> So I believe you should put the definition of 401 in only one case, like
> alongside
> other status codes, but then it is kind of a shortcoming that a single code
> covers so many cases.
> Even more so as the reply has no body, so the server has no chance to
> provide
> more details to the client on what has failed, what the client could
> change, etc.
> So something maybe to think about?
> Maybe 451 error code should apply to some of these cases?
>
> (of course this applies in the same way to further descriptions of 401
> below)
>

Some of those could be covered by a 423 (Locked).. and 451 isn't out of the
question either.  Do you want to propose some specific codes we could use
and a description of what they cover?


> * 4.2.1.2
> Is there a specific reason to separate the case of removing all DS records
> from the case of generic DS records update detailed after?
>

Yes.  Removal of all DS records is a security downgrade, while removal of
some DS records in the course of updating the DS set is not.  The two
operations have distinct signals in CDS as well.


> * 4.2.1.3.1
> Nitpick: you use this form "CDS/CDNSKEY" and "CDS/CDSKEY RRset" here,
> while previously
> you said "CDS or CDNSKEY record in the child zone" where all of these
> points to
> the exact same concept so can you choose one case and apply it
> consistently in all
> the document. Also in the introduction you said you are using CDS but
> CDNSKEY could
> be swapped, so if that is true, why repeating the duality CDS/CDNSKEY
> later in the document?
>

That's an editorial mistake.  I'll clean it up in the next revision.

* 4.2.2.1.1
> "_delegate.@ domain name"
> This can not be a domain name as those, like hostnames, can not have _ in
> their labels.
> It is "just" a resource record.
>

No, it's a domain name.  Every name in the DNS is a domain name.  Some
domains are host names, which in certain contexts have stricter naming
requirements.  A domain name is a component (the first field) of a resource
record.

I believe you're using the registration industry definition of "domain",
which does not match the DNS terminology.  The registration industry's use
of "domain" (that which is sold to a registrant) is more like "delegation"
in DNS terms.


> Also for:
> "Note that the _delegate TXT record is publicly available and not a
>    secret token."
> Maybe rephrase that as I understand your intent would be to say that no
> secret
> value should be used as token for the _delegate TXT record since it is
> publicly available.
>

"Note that the _delegate TXT record is publicly visible and therefore
cannot be treated as a secret token." ?


> * on status codes, is there really a difference between 409 and 412?
> You use 409 for establishing the trust, and 412 for removing/updating it,
> in all 3 cases when there is an invalid situation (already DS when starting
> the trust, no DS to remove when asked, etc.)
> Wouldn't it be more logical to use 409 or 412 in all 3 cases?
>

We're using standard HTTP response codes in ways that are as close a
possible to their original definition.  Our reasoning is that since a 409
is a conflict, it makes sense to use it to indicate that a DS already
exists when the upstream is being asked to set up trust, and since 412 is a
failed precondition, it makes sense to use when trying to delete or update
something that doesn't exist.

If there were any cases where a 409 or 412 code were a possible response to
the same request then I'd be against changing it on the basis that it would
be a reduction in detail, but since there are no such cases I can see the
argument for simplifying it.

Does anyone else in the WG feel this should be changed?




>
>
> * 4.2.2.1.2
> " A token is included in
>       the body of the response, as a valid TXT record"
> This does look underspecified to me.
> Does that mean that in the body we find the token formatted as a DNS TXT
> record?
> In zonefile format or wire format?
> Or is just the token transmitted, in HTML? JSON? pure text?
> In the later case, with or without pre and post padding?
>
> Also, you specify previously that the token may expire.
> Wouldn't be nice if in this reply also the expiration would be
> transmittend back to client?
> Either as part of the body response (but then you even more need to define
> it precisely)
> or an the HTTP level like with Cache headers?
>

We've clearly missed something here.  Thanks for pointing it out.

My first inclination is to suggest that the "as a DNS TXT record" bit be
changed to simply say that the token should be formatted as the text
representation of the RDATA of a TXT record.  That allows us to make use of
the TXT RR specification without having to define (or redefine) anything
ourselves.  However, that still leaves the question of how to refer to any
potential expiry. I like the cache header suggestion.

Does anyone else have ideas for how we could approach fixing this?



> For this specific operation, why no 401 case, nor 409/412, nor 429?
> They should apply also here I believe.
>

I agree.  I don't know why those weren't included for this one.  Perhaps
one of my co-authors have reasoning behind that?


> * 4.3.  Customized Error Messages
>
> This is clearly underspecified. How it is formatted in the body of the
> response?
> Especially since you later say that it is a protocol for machine to machine
> communications, so these communications must be framed inside
> specific structures.
>

I believe that since that is the only thing that may be in the body, it was
assumed it would be a simple text string.  No extended error message is
ever going to be used directly by a machine.. it would have to be stored
and made available to a human looking into the results of a request.. so I
don't think further structure is necessary.  However, we should have
specified this more clearly.  I don't think it's a bad idea to give it some
sort of structure, especially to allow for the separation of an extended
error code and extended error text.

If we did add structure to the body, my personal preference is for
something light-weight and human debuggable like YAML or JSON.  Does anyone
have strong feelings about that, or other formats we should consider?


>
> * 5.  Security considerations
>
> You speak about drawbacks without explaining what they would be.
>

Yes, this text should be expanded.


>
> * 7.
> "   This protocol is designed for machine to machine communications.
>    Clients and servers SHOULD use punycode [RFC3492] when operating on
>    internationalized domain names."
>


> Why do you reference IDNA2003 instead of IDNA2008?
>

I'm assuming that's an oversight.. someone probably googled for the
punycode specification, found 3492 in txt form (which doesn't have Updates
meta-data) and went with that.

Although, I do think 3492 is still a valid reference in this case.  5891
goes out of its way to say that it does not update the specification for
converting U-labels to A-labels, and only corrects a non-normative
reference in 3492 (RFC5891 § 4.4).

I have no problem with updating this to refer to 5891 instead, if there are
no objections.




>
> Others open point I have not seen and maybe useful to think about:
>
> * I believe there should be some kind of recommendation (a SHOULD?) that
> the registry should notify the registrar of such changes to the domain it
> may
> have been instructed to do by third parties, like with service messages in
> EPP.
> For at least 2 reasons: internally for the registrar to have locally a
> relevant
> state of the domain it manages in its own database, and specially because
> it
> could have been an error by the third party/registrant, and also externally
> because registrars may publish data about domain names they publish (like
> whois, rdap, escrow exports, etc...) and this often includes DNSSEC data,
> even if sometimes only a flag enabled/disabled but this still means the
> registrar
> needs to be notified of changes it did not start itself.
>

One of the basic assumptions of the document is that this is being
implemented by whoever normally maintains delegation data.  In the case
you're describing above, that is the registrar, so I don't think we have a
problem.  However, we can be more explicit about that, especially for the
case (which exists in some ccTLDs) where the registrants are regularly able
to go around their registrar direct to the registry.  I think I would couch
the whole thing in something like "if the delegation is normally maintained
by a registrar, but the registry might update a delegation itself based on
CDS data, then policy or contractual agreements might compel the registry
to update the registrar on the changes" ... or something to that effect.


> * You advise more than once that the registry should monitor its child
> zones
> for their CDS records regularly.
> What happens if it detects a NS change? Because this may cover two complete
> differente cases: one where the current DNS hoster just does technical
> changes
> and completely manage correctly the DNSSEC setup on both the old and new
> server,
> or the second being a change of DNS operator, and the new one not being
> DNSSEC aware,
> hence maybe dropping at once all DS/DNSKEY/RRSIG/CDS/CDNSKEY records.
> What should the registry do? In general, and if it receives a ping through
> your protocol to update things (a cronjob could have been left running at
> the old
> provider for example)
>

I don't see a problem here.  If I'm reading this correctly, there are three
potential cases you consider.

First, the registry can trust whatever signed responses it gets out of
child zones whether the child name servers have moved or not.  That's (part
of) the beauty of DNSSEC .. it validates data without having to validate
its source.  So a move from one DNSSEC-capable operator to another is a
nonevent as far as this protocol or CDS is concerned.

Second, if the registrant moves their (signed) zone from an operator that
supports DNSSEC to one that does not, then they need to take care of the
downgrade or their zone will fail.  That's basic operations that applies
whether this protocol is in use or not, and is therefore (in my opinion)
outside of the scope of this document.

Third, in the case of bootstrapping trust, an NS mismatch would be a clear
sign that there's a problem, and that bootstrapping should not proceed.  I
believe that's already covered by the reference out to
draft-wallstrom-dnsop-dns-delegation-requirements.


Incidentally, we're still hoping we can avoid having to import all the
advice from that draft into ours.  I'm not sure what the rules are around
having a non-normative downref in a Standards Track document, but hopefully
that document progresses further anyway.    Chairs.. any thoughts there?





> * Similar cases if there is a transfer of the domain name... should the
> trust
> relationship be reset to its beginnings since in some of these cases this
> also
> has the consequence of changing the DNS provider.
>

Again, that's standard DNSSEC operations and is outside of the scope of
this document.   Sometimes moving registrars means you have to downgrade
because the move process wipes out delegation data.  Sometimes it doesn't.
See draft-koch-dnsop-dnssec-operator-change (expired) for a discussion of
the problems of moving from one Registrar to another when the Registrar is
the DNS operator.


>
> You in fact barely touch on client authentication in your protocol
> and saying to me it is outside of the scope seems a little too quick.
> What happens when the DNS provider changes? How can old accesses be
> revoked?
>

The fact that you've asked the question means we've been unclear about
something.  Perhaps we've assumed too much about the reader's knowledge of
DNS security in our attempts to be brief about something that we don't need
to specify?  I'll be explicit here and perhaps you can suggest a spot where
we can meet in the middle.

DNSSEC takes care of validating the data in a signed zone regardless of the
source of the data.  So if a parent can get a signed CDS record that
validates according to the currently existing chain of trust, then the
parent can use that CDS to update the chain of trust, regardless of what
that update is or where they got it.  So the signalling provided by this
protocol does not need to be authenticated.  All it is is a poke to say "go
look at CDS for zone X now."   If we really wanted to be simple about it,
the entire thing could be a single GET URI, or even a custom ICMP message,
but we felt that as long as we're specifying this we might as well enable
it to carry more detail than that.

Even though further authentication of this protocol isn't *technically*
required, we realize that there may be business requirements that would
lead a Registrar or Registry to want to limit who can access the servers
where they provide this service, especially if they've chosen to enable the
bootstrapping of trust, and there are several places in the document where
we have a nod to these business requirements.  We feel that mentioning that
operators may want to implement such limitations is sufficient, and it's
not our place to specify what they SHOULD be, since it's not technically
required by the protocol.

With all that in mind, there is no such thing as revocation of old
accesses.  There's no reason given by this protocol for a parent operator
(registrar or registry) to track who they got poked by when CDS was
updated.  If they want that sort of tracking, or access restriction, or
hard association between an operator and a zone, that's their own business.