Subject: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-maintain-ds-03: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 30 Aug 2016 05:47:44 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-maintain-ds-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I support Jari's discuss - but it might be fine to
just chat about the 7344 status change, not sure. But
that said, I'm balloting yes, as this bootstrapping is
definitely needed if DNSSEC is going to prosper.

- please check and respond to the secdir review, [1]
which overlaps a bit (but not totally) with my comments.

   [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html

- 1.3: s/digiest/digest/

- 1.3: definition of RRR isn't clear (enough) - I think
you want to define RRR to mean the current public DNS
ecosystem maybe, but not sure if there's a subtlety
somewhere in e.g. 3rd level and other domains. This
might be clearer if you mention the PSL as a way to
explain (not define) RRR. OTOH, you don't use RRR later
at all, so you could just delete that term entirely and
say a parent is typically an entity one above what's in
the PSL, but can be lower down the naming hierarchy,
e.g. within an enterprise.

- section 2: calling operation 2 the "first one" is
confusing, maybe re-order for clarity. Oh, and then you
later mean "first one" == "operation 1" - so that does
need fixing. Or just delete that para.

- 2.1: I think you need to say that the acceptance
policy for the very first use of CDS requires some
out-of-band agreement, or is just done at the whim of
the parent based on a possibly unknown policy. Ah, you
do say that in section 3 - maybe consider re-doing the
split into sections, e.g. make 2.1 be text at the start
of 3.

- section 3: I think it'd be good to call out the case
where the domain is brand-new (i.e. never before
existed) and has a CDS from the very first instant. That
might fit in to 3.1, but I think it is worth a mention
as a) it's a good goal to have (since it minimises the
window without DNSSEC to zero) and so hopefully worth
supporting and b) there's arguably no additional risk
due to the CDS in this case, since the parent is also
adding the delegation at the same time and c) it makes
for better automation. That said, I'm not sure what s/w
changes supporting that'd imply, but since a lot of
parent registry code (APIs and such) are likely
home-grown today, calling it out here might help ensure
that parents don't all e.g.  follow 3.3 or otherwise
make DNSSEC-from-the-getgo hard or impossible.

- 3.4: Do you need to say that the parent in this case
ought monitor the child's DNS and react when the right
challenge is visible? If it wasn't already done, this
section might also be worth checking with some folks
working on acme, as they have analysed such cases.