Dear all,
This latest version 07 of draft-ietf-dnsop-ns-revalidation has all
feedback from DNS Directorate early review, the mailing list, the room
and hallways, since it was presented at the last IETF119 in Brisbane,
processed. The authors believe the draft is ready for working group last
ca
Hi Willem,
We've got a peer-reviewed reference[0] that can help back up some of
the claims in the draft.
```
2. Motivation
There is wide variability in the behavior of deployed DNS resolvers
today with respect to how they process delegation records. Some of
them prefer the pare
my bad, forgot to add the ref:
[0] https://par.nsf.gov/servlets/purl/10186683
or
https://catalog.caida.org/paper/2020_when_parents_children_disagree
On 08-07-2024 12:55, Giovane C. M. Moura wrote:
Hi Willem,
We've got a peer-reviewed reference[0] that can help back up some of
the claims
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Initializing a DNS Resolver
with Priming Queries'
as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this actio
Thanks for the comments. They are all addressed in the revised draft coming out
shortly.
--Paul Hoffman
> On Jun 26, 2024, at 13:31, James Mitchell wrote:
>
> All,
> Please find my comments below.
> The draft introduces a new optional field PublicKey without providing a
> versioning mechani
Thanks for the comments. They are all addressed in the revised draft coming out
shortly.
--Paul Hoffman
On Jun 30, 2024, at 15:31, John R Levine wrote:
>
> I took a look and didn't find anything particularly troubling. I agree that
> adding the new optional DNSKEY element doesn't need a vers
On Jul 3, 2024, at 07:50, Ben Schwartz wrote:
> Section 1.1
>
> I like the "assumed and not derived" notion for a "trust anchor", but it's
> tricky and bears a bit more explanation. Rather than repeating it in the
> following sentence, perhaps you could say "the decision to trust this entity
Thanks for the comments. Some are addressed in the revised draft coming out
shortly. I have noted below only the ones that are not.
--Paul Hoffman
> On Jul 1, 2024, at 11:08, Peter Thomassen wrote:
> Section 2.2
> ---
>
> OLD
> The Zone element in the TrustAnchor element states to w
Hi Paul,
On 7/8/24 20:08, Paul Hoffman wrote:
OLD
The Zone element in the TrustAnchor element states to which DNS zone
this container applies. The root zone is indicated by a single
period (.) character without any quotation marks.
This is underspecified w.r.t. to format, for labels c
Thanks for the quick responses!
On Jul 8, 2024, at 11:21, Peter Thomassen wrote:
>
> On 7/8/24 20:08, Paul Hoffman wrote:
>>> OLD
>>> The Zone element in the TrustAnchor element states to which DNS zone
>>> this container applies. The root zone is indicated by a single
>>> period (.) char
Greetings all,
After the good discussion previously about the right levels of
recommendations for deployment/usage vs implementation requirements,
Warrn and I have put together three new documents that we believe find a
good middle ground in all cases and look forward to further discussion.
- ht
Hi Patrick,
First of all, thank you very much for this very comprehensive review. It's been
very valuable, and we have incorporate a lot of your feedback into the new
revision -02 that was just uploaded.
Below some more responses.
On 3/14/24 08:32, Patrick Mevzek via Datatracker wrote:
§1.2
Hi Warren,
tl;dr: The erratum is correct, and I think can be verified.
The situation described in the second-to-last paragraph of RFC 6781 Section
4.3.5.1 (and illustrated in Appendix D) amounts to
- adding operator B as a multi-signing party according to RFC 8901 Model,
- removing operator A.
Does this resolve the type mismatch? Do you have any other concerns?
R3. UDP responders should compose response datagrams whose size does not
exceed the requestor's offered buffer size (EDNS bufsize) or, after
packetization by the UDP and IP/IPv6 layers, does not exceed the interface
MTU, the rout
All,
the changes from draft-ietf-dnsop-zoneversion-09 to -10 address or incorporate
the following points recently raised:
- Removed from abstract (Roman Danyliw)
- RFC 8499 -> RFC 9499 (Roman Danyliw)
- Incorporated Joe Abley's proposed text for "enclosing zone"
- Instruct responders to return
All
I wanted to call your attention to the most recent update on this
document. The authors have worked through a number of open issues
primarily around editorial clarity and reorganization of the
recommendations. I want to personally thank the authors for working
through these issues, and my co
16 matches
Mail list logo
