[DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dnssec-bcp-05: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-dnssec-bcp-05: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

# GEN AD review of draft-ietf-dnsop-dnssec-bcp-05

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/TNMpPSf36E8i5Nt96FoRSlbjPFA).

## Discuss

### "Abstract", paragraph 1
```
 This document describes the DNS security extensions (commonly called
 "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
 others.  One purpose is to introduce all of the RFCs in one place so
 that the reader can understand the many aspects of DNSSEC.  This
 document does not update any of those RFCs.  Another purpose is to
 move DNSSEC to Best Current Practice status.
```
I don't understand what "move DNSSEC to Best Current Practice status" means in
terms of the standards track. I'm all for advancing the RFC set that makes up
DNSSEC along the standards track, but BCP it not part of that track. Publishing
a BCP that normatively references some DNSSEC RFCs isn't doing anything in terms
of moving them forward.

### Section 1.1, paragraph 2
```
 The DNSSEC set of protocols is the best current practice for adding
 origin authentication of data in the DNS.  To date, no standards-
 track RFCs offer any other method for such origin authentication of
 data in the DNS.
```
Just because no other standards track RFCs compete with DNSSEC does not mean it
is a BCP. A BCP is something else, i.e. "The BCP subseries of the RFC series is
designed to be a way to standardize practices and the results of community
deliberations." [RFC2026]

### Section 1.1, paragraph 1
```
 However, this low level of implementation does not affect whether
 DNSSEC is a best current practice; it just indicates that the value
 of deploying DNSSEC is often considered lower than the cost.
```
Protocols aren't BCPs. HTTP isn't the "best current practice" for transporting
HTML either.


--
COMMENT:
--

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC2535]` to `RFC2535`, which was obsoleted by `RFC4033`,
`RFC4034`, and `RFC4035` (this may be on purpose).

Reference `[RFC2065]` to `RFC2065`, which was obsoleted by `RFC2535` (this may
be on purpose).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-dns-catalog-zones-08: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

# GEN AD review of draft-ietf-dnsop-dns-catalog-zones-08

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/V-jMkADwNBpUN-H4TyNcC_RdTwg).

## Comments

### Section 3, paragraph 2
```
 Catalog consumers MUST ignore any RR in the catalog zone which is
 meaningless to or otherwise not supported by the implementation.
```
Russ Housley raised this in his Gen-ART review: What is meant
by "meaningless" here?

### Too many authors

The document has seven authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

 "Table of Contents", paragraph 1
```
tent of a DNS zone is synchronized amongst its primary and secondary nameserv
   ^^^
```
Do not mix variants of the same word ("amongst" and "among") within a single
text.

 Section 4.1, paragraph 3
```
ord in the collection.  has an unique value in the collection. When
  ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

 Section 5.1, paragraph 7
```
dure described in Section 4.4.1. Otherwise a migration of a member zone from
 ^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

 Section 5.2, paragraph 2
```
 yet (because of a lost packet or down time or otherwise), but did already se
  ^
```
This word is normally spelled as one. Did you mean "downtime"?

 Section 6, paragraph 1
```
 to enumerate the contents of a multi-valued property (such as the list of m

```
This word is normally spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-alt-tld-23: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--


# GEN AD review of draft-ietf-dnsop-alt-tld-23

CC @larseggert

Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1LB6_ujGseyZRWPgTQZrP2pS8zk).

## Comments

### DOWNREFs

DOWNREF `[RFC8244]` from this Proposed Standard to Informational `RFC8244`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

I think RFC8244 could be cited informatively?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

 Section 2, paragraph 7
```
 performing aggressive use of DNSSEC- validated caches (described in [RFC8198
  ^
```
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

 Section 2, paragraph 8
```
will cover all names under .alt. Currently deployed projects and protocols t
 ^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

 Section 7.1, paragraph 2
```
and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156,

```
Do not mix variants of the same word ("minimisation" and "minimization") within
a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

# GEN AD review of draft-ietf-dnsop-avoid-fragmentation-16

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VBI2ri6JwD9TEPjcxKBi828dVs4).

## Comments

### Paragraph 2
```
 IP Fragmentation Avoidance in DNS
```
Title should clarify this is for DNS over UDP.

### Section 1, paragraph 5
```
 This document specifies various techniques to avoid IP fragmentation
 of UDP packets in DNS.
```
Really wish that this BCP made a much stronger recommendation for DNS over TCP.

### Section 3.1, paragraph 0
```
  3.1.  Recommendations for UDP responders
```
I find myself agreeing with other ballots on these recommendations.
Will refrain from duplicating them (and also from holding another DISCUSS
based on them.)

### Section 3.1, paragraph 3
```
 At the time of writing, most DNS server software did not set the DF
 bit for IPv4, and many OS kernel constraints make it difficult to set
 the DF bit in all cases.  Best Current Practice documents should not
 specify what is currently impossible, so R2, which is setting the DF
 bit, is "MAY" rather than "SHOULD".
```
Maybe I'm familiar with different kernels, but all the ones I am
familiar with (except for some IoT platforms) readily offer socket
options to set DF (and prevent stack fragmentation in v6).

### Section 3.1, paragraph 3
```
 R3.  UDP responders SHOULD compose response packets that fit in the
 minimum of the offered requestor's maximum UDP payload size
 [RFC6891], the interface MTU, and the RECOMMENDED maximum DNS/UDP
 payload size 1400.
```
Why SHOULD, i.e., when would it ever be OK to do this? Also, where
does the 1400 byte value come from (magic constant?)

### Section 3.1, paragraph 3
```
 R5.  UDP responders SHOULD limit the response size when UDP
 responders are located on small MTU (<1500) networks.
```
Limit *to what*?

### Section 4, paragraph 0
```
  4.  Recommendations for zone operators and DNS server operators
```
I find it somewhat questionable to recommend changes in how DNS is
being operated just to cater to UDP needing to remain a viable
transport. (I realize I may be an outlier here.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-dnsop-svcb-https`, but that has been published
as `RFC9460`.

### Grammar/style

 "Appendix B.", paragraph 3
```
fter two UDP timeouts, BIND 9 will fallback to TCP. C.2. Knot DNS and Knot R
   
```
The word "fallback" is a noun. The verb is spelled with a space.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-iana-class-type-yang-03: No Objection

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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/



--
COMMENT:
--

Possible DOWNREF from this Standards Track doc to [IANA-DNS-PARAMETERS].
Possible DOWNREF from this Standards Track doc to [IANA-YANG-PARAMETERS].

Not sure if a normative reference to an IANA registry page is technically OK;
the document should probably normatively cite the RFCs that created these
registries instead, or maybe these can be converted to informative references?

---
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 5, nit:
>  can then, for instance, run several different DNS server implementations in
>  ^
Consider using "several".

Section 4, paragraph 17, nit:
> FC  5. Security Considerations This documents translates two IANA registr
>
Did you mean "these"?

Section 4, paragraph 17, nit:
> ty Considerations This documents translates two IANA registries into YANG dat
>  ^^
You should probably use "translate".

"Appendix A.", paragraph 6, nit:
> e corresponding IANA registries using a XSLT stylesheet from Appendix A of RF
>   ^
Use "an" instead of 'a' if the following word starts with a vowel sound, e.g.
'an article', 'an hour'.

These URLs point to tools.ietf.org, which is being deprecated:
 * https://tools.ietf.org/html/rfc

These URLs in the document did not return content:
 * https://tools.ietf.org/html/rfc

These URLs in the document can probably be converted to HTTPS:
 * http://www.w3.org/1999/XSL/Transform
 * http://www.iana.org/assignments



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-rfc7816bis-10: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-rfc7816bis-10: No Objection

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 DISCUSS and COMMENT positions.


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



--
COMMENT:
--

DOWNREF from this Standards Track doc to Experimental [RFC7816].

"Abstract", paragraph 3, comment:
>This document is part of the IETF DNSOP (DNS Operations) Working
>Group.  The source of the document, as well as a list of open issues,
>is at 

Should this not be removed before publication?

Obsolete reference to RFC7626, obsoleted by RFC9076 (this may be on purpose).

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms "traditional", "tradition", "Traditionally"; alternatives might be
   "classic", "classical", "common", "conventional", "customary", "fixed",
   "habitual", "historic", "long-established", "popular", "prescribed",
   "regular", "rooted", "time-honored", "universal", "widely used",
   "widespread".

---
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Table of Contents", paragraph 2, nit:
> ed in Section 6.1 of [RFC6973]: the less data you send out, the fewer privac
> 
Did you mean "fewer"? The noun data is countable. (Also elsewhere.)

Section 1.2. , paragraph 3, nit:
>  is to minimise the amount of privacy sensitive data sent from the DNS resolv
>   ^
This word is normally spelled with a hyphen. (Also elsewhere.)

Section 4. , paragraph 1, nit:
> en saved if the incoming QTYPE would have been the same as the QTYPE selected
>^^^
Did you mean "had been"? (Also elsewhere.)



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: Discuss

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

Section 4.2. , paragraph 3, discuss:
>Since host memory for TCP state is a finite resource, DNS clients and
>servers MUST actively manage their connections.  Applications that do
>not actively manage their connections can encounter resource
>exhaustion leading to denial of service.  For DNS, as in other
>protocols, there is a tradeoff between keeping connections open for
>potential future use and the need to free up resources for new
>connections that will arrive.

For it to contain a MUST-level requirement, this section needs to give a lot
more concrete guidance on what it means to "actively" manage connections. Most
operating systems by default impose some application limits that usually
effectively prevent DOS or other resource exhaustion issues. Is the intent here
that DNS implementations need to do more? If so, what?


--
COMMENT:
--

Section 2.4. , paragraph 1, comment:
> 2.4.  Fragmentation and Truncation

Fragmentation and IP fragments getting dropped is one reason for needing more
retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
doesn't detect or recover from loss of any UDP packets making up the overall
message. That means that a normal packet loss (due to congestion or other
reasons) amplifies into loss of the entire DNS message.

Section 3. , paragraph 1, comment:
> 3.  DNS over TCP Requirements

While the history preceding this section is interesting for context, I think
moving this section up would increase readability significantly.

Section 4.2. , paragraph 3, comment:
>DNS server software SHOULD provide a configurable limit on the total
>number of established TCP connections.  If the limit is reached, the
>application is expected to either close existing (idle) connections
>or refuse new connections.  Operators SHOULD ensure the limit is
>configured appropriately for their particular situation.

Again, the OS generally already imposes limits. Why recommend that DNS
implementations self-impose other (lower?) limits?

Section 4.2. , paragraph 3, comment:
>DNS server software MAY provide a configurable limit on the number of
>established connections per source IP address or subnet.  This can be
>used to ensure that a single or small set of users cannot consume all
>TCP resources and deny service to other users.  Operators SHOULD
>ensure this limit is configured appropriately, based on their number
>and diversity of users.

This limit only begins to establish fairness once the overall number of
permitted connections is reached. Until that point, it possibly limits client
performance without any benefit.

Section 4.2. , paragraph 3, comment:
>DNS server software SHOULD provide a configurable timeout for idle
>TCP connections.  For very busy name servers this might be set to a
>low value, such as a few seconds.  For less busy servers it might be
>set to a higher value, such as tens of seconds.

Ditto.

Section 4.2. , paragraph 3, comment:
>DNS server software MAY provide a configurable limit on the number of
>transactions per TCP connection.

What does that limit protect against?

Section 4.2. , paragraph 2, comment:
>Similarly, DNS server software MAY provide a configurable limit on
>the total duration of a TCP connection.

What does that limit protect against?

Section 4.5. , paragraph 3, comment:
>Most open source DNS server implementations provide a configurable
>limit on the total number of established connections.  Default values
>range from 20 to 150.  In most cases, where the majority of queries
>take place over UDP, 150 is a reasonable limit.  For services or
>environments where most queries take place over TCP or TLS, 5000 is a
>more appropriate limit.

20-150 is orders of magnitude less than I expected. Even 5000 seems very low,
given the capabilities of even low-end servers.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-svcb-https-08: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ctABeNgyI1ywOHNXs17ZO07rLFY).

---
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

"Table of Contents", paragraph 2, nit:
> iding transient connections to a sub-optimal default server, negotiating a pr
>  ^^^
This word is normally spelled as one.

Section 2.4.2. , paragraph 10, nit:
> its SvcParams all comply with each others' requirements. Zone-file implement
>^^^
Did you mean "other's"?

Section 3.2. , paragraph 2, nit:
> ons. 4.2. Recursive resolvers Whether or not the recursive resolver is aware
>   ^^
Consider shortening this phrase to just "Whether". It is correct though if you
mean "regardless of whether".

Section 9.1. , paragraph 5, nit:
> o alt3.example:9443 * Fallback to the the client's non-Alt-Svc connection beh
>   ^^^
Possible typo: you repeated a word.

Section 9.3. , paragraph 2, nit:
> rtext HTTP. If this redirection would result in a loss of functionality (e.g
> 
Consider removing "would". (Usually, "would" does not occur in a conditional
clause, unless to make a request or give a polite order.).

Section 12. , paragraph 3, nit:
> his registry are subject to a First Come First Served registration policy ([
> 
It seems that a comma is missing.

"D.2. ", paragraph 14, nit:
> fy the IANA instructions (pure First Come First Served) - Recommend against
>  
It seems that a comma is missing.

Document references draft-ietf-tls-esni-13, but -14 is the latest available
revision.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-nsec3-guidance-08: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

# GEN AD review of draft-ietf-dnsop-nsec3-guidance-08

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/s5hyTc3FVrHGhUW0kHVOGLVXTgo).

## Comments

### Section 3.2, paragraph 4
```
 Validating resolvers returning an insecure or SERVFAIL answer to
 their client after receiving and validating an unsupported NSEC3
 parameter from the authoritative server(s) SHOULD return an Extended
 DNS Error (EDE) {RFC8914} EDNS0 option of value (RFC EDITOR: TBD).
 Validating resolvers that choose to ignore a response with an
 unsupported iteration count (and do not validate the signature) MUST
 NOT return this EDE option.
```
{RFC8914} looks like a Markdown citation bug.

### Missing references

No reference entries found for: `[RFC8914]` and
`[draft-hardaker-dnsop-nsec3-guidance]`.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Stray characters

The text version of this document contains these HTML entities, which might
indicate issues with its XML source: `č`, `Š`, and `Č`

### Grammar/style

 "Table of Contents", paragraph 1
```
. . . . . . . . . . 10 Appendix D. Github Version of This Document . . . . .
   ^^
```
The official name of this software platform is spelled with a capital "H".

 Section 1.1, paragraph 1
```
lag [RFC5155], which specifies whether or not that NSEC3 record provides pro
   ^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

 Section 2.3, paragraph 1
```
w, ftp, mail, imap, login, database, etc) can be used to quickly reveal a lar
 ^^^
```
A period is needed after the abbreviation "etc.".

 Section 5, paragraph 1
```
y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/R
   ^^^
```
Do not mix variants of the same word ("on-line" and "online") within a single
text.

 Section 7.1, paragraph 2
```
NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements
  ^^
```
Two consecutive dots.

 "Appendix A.", paragraph 2
```
 Vixie * Tim Wicinski Appendix D. Github Version of This Document While this
  ^^
```
The official name of this software platform is spelled with a capital "H".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop