# Internet AD comments for draft-ietf-dnsop-dnssec-bootstrapping-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S7

* Should there be some kind of registration or reservation for the "_dsboot"
  meaning and usage described in this document?

# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08.txt

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================

## idnits: There seems to be an obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)

I agree with Eric Kline's comment regarding reservation for the "_dsboot".

Thank you to Peter Yee for the GENART review.

** Section 6.  Editorial.
   The level of rigor in Section 4.2 is needed to prevent publication of
   a half-baked DS RRset

Is “half-baked DS RRset” a term-of-art?  To improve readability, I recommend not using an idiomatic expression.

** Section 7.  Editorial. Per the reference to [draft-ietf-dnsop-dnssec-bootstrapping], this should likely be something like “[This RFC]” and subsequent comment of that string being replaced by the RFC Editor.  

** idnits reports:
  ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08

Thank you for the work put into this document, if widely used then it could help the deployment of DNSSEC.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tim Wicinski  for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status and uses an old template.

Other thanks to Benson Muite, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-dnssec-bootstrapping-08-intdir-telechat-muite-2024-05-12/ (and I have read Peter's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

I am sympathetic to Paul Wouter's comments about 'bailiwick' and the use of "_signal". The latter is probably to late to be changed.

## Section 2

Two normative "SHOULD" but no reason/suggestion on when the SHOULD can be bypassed.

## Section 4.1.1

"example.co.uk" is not a IANA/IETF reserved domain name. Suggest to use an actual reserved domain name.

Suggest to also add the RR type in the example.

Perhaps explain `Publication of signaling records under the in-bailiwick domain _signal.ns3.example.co.uk is not required`.

## Section 7

Like Erik Kline, I wonder whether the IANA considerations should include a request for _dsboot. The use of _dsboot is only briefly mentioned in section 1.1, which is rather weak for a proposed standard document (I was close to open a DISCUSS on this topic).

I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar to say a past process is obsolete and you SHOULD NOT use it, because then continuing to use it is technically still supported by this document.  Don't we want to say that new implementations MUST NOT do the old thing and MUST do the new thing?  Using SHOULD effectively leaves two systems "live" rather than one.

This may be some ignorance talking, but: In Section 4.2, if it's found that the child is already securely delegated, should this be an error, or just treat the whole thing like a no-op?  Redundant verification returning an error seems an odd choice, but I'm probably missing some context.

I think the SHOULD in Section 4.3 should really be more like "Parental agents normally trigger ...".  I'm not clear on why this is a normative SHOULD.  What if I don't do it in those circumstances, but possibly in others?  I'm still compliant with a SHOULD then, right?  Why might I do it in other situations?  The text doesn't say.

Thanks for working on this specification. No objection from transport protocol considerations.