All
Thanks for all the comments on this draft. While we saw many comments
addressing the contents, and Daniel was very quick to address, the chairs
did not hear consensus in support of moving the draft forward.
We talked about this with our AD, and he agrees with our assessment.
We are going to
Hi,
Please find the new version that addresses Christina comments. It includes
a secure transport section and the security considerations section has been
consolidated by adding a trust model section.
As always, comments are welcome!
Hi,
I have just drafted a secure transport and a security considerations
section, that I believe provide sufficient guidance to a DRO. I expect to
further review these sections and publish a new version very soon. As
always, comments are welcome.
Hi Christina,
Thanks for the review and the suggestions. Please see my comments inline.
Yours,
Daniel
On Wed, Jun 14, 2023 at 11:56 AM Christian Huitema
wrote:
> I know that the feedback was due last Sunday, but here comes mine
> anyhow, after looking at the latest iteration of the draft.
>
>
Hi Florian,
Thanks for the feed back. One motivation for this document was to provide
guidance to deploy a DNSSEC resolver and implicitly encourage those not
doing it already. I think that your comment was very helpful as it clearly
indicated that we were achieving the opposite of what we were
Hi Andrew,
Thanks for the comment, the current document is much shorter than the
initial document. Regarding grammar, and linguistic issues - I am adding
explanations hard to follow - have been removed and largely rewritten from
scratch. I believe the current version addresses your concerns.
On 6/15/23 15:32, Viktor Dukhovni wrote:
I agree that client-side validation would be ideal. One important
aspect here is to save on the latency caused by extra queries; my
impression is that this extra cost is generally considered
prohibitive.
Not sure what you mean by "generally" (is that
On Wed, Jun 14, 2023 at 12:09:23PM -0400, Peter Thomassen wrote:
> > But the focus changes. For example, if we consider that "spoofing by
> > recursive server" is a threat, then having the recursive set bits to
> > affirm that the response is verified is not much of a protection --
> > the
Hi Christian,
On 6/14/23 11:55, Christian Huitema wrote:
In the old model, we are very concerned about third parties spoofing responses
and polluting resolver caches. In a secure transport model, the only parties
that can spoof responses are the resolvers themselves: authoritative resolvers
I know that the feedback was due last Sunday, but here comes mine
anyhow, after looking at the latest iteration of the draft.
The draft makes a number of recommendations, which seem all reasonable,
but what struck me was the weak tie between these recommendations and
the security
On 2023-06-07 13:08 -04, Tim Wicinski wrote:
> Just a reminder we're looking for any feedback on continuing work on this
> document. The Chairs/OverLord Warren feel significant work on this
> document is needed, but that may not be relevant.
The document seems to have a rather pessimistic view
Just a reminder we're looking for any feedback on continuing work on this
document. The Chairs/OverLord Warren feel significant work on this
document is needed, but that may not be relevant.
We're wrapping this feedback up this Sunday 11 June.
(and Thanks Andrew for your comments)
tim
On
As this document’s shepherd, FWIW I think that if the document does
proceed in the WG it needs significant love and attention. The document
in its current state is not well written and it would require
significant labor to resolve its numerous grammar and linguistic issues.
It’s also very long
All,
The chairs want to thank everyone for the feedback on this document
recently. We've been in discussions with Warren and the authors about this
document, and we have some questions we'd like the working group to help us
resolve.
While this work was relevant when it was first written and
14 matches
Mail list logo
