Section 3, you expand DoT and DoQ here but, they have already been used
> without expansion in 2.2
Fixed.
>
> - Section 4, s/in failed resolutions or significant delay/in failed
> resolutions
> or significant delays/
Fixed.
Again, thanks!
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
value" to
indicate why one would want to do the modeling. If you think we need to say
more, we can do so in the next draft.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
rvers, and that it is
likely that if one server has a failure such as a timeout, the resolver will
try the other nameservers (which may or may not be encrypting).
Are you proposing a shorter value for "damping", or a note saying "1 day is
just the suggested value, you might choose
(or not)? - It would be nice if the examples in Section 4.5 that
> don’t list both IPv4 and IPv6 example addresses chose IPv6 as the primary
> example.
>
Yeah, that section got sidetracked. Can fix.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Sep 7, 2023, at 6:58 PM, Bron Gondwana wrote:
>
> On Fri, Sep 8, 2023, at 02:18, Paul Hoffman wrote:
>> Thanks for the review!
>>
>> On Sep 7, 2023, at 7:16 AM, Bron Gondwana via Datatracker
>> wrote:
>>
>> > My only concern is th
ected.
Yes, exactly. Even if you can't stop your library from verifying, you must be
able to ignore the verification failures.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
t; I don't think this is an operational consideration
> for unilateral probing.
True, but it didn't exist in any other RFC we could find to reference, so it
seemed reasonable to state it here rather than ignore it.
>
> ### NITS:
>
> awkward sentence: The simplest deployment would sim
> On Sep 20, 2023, at 2:32 PM, Paul Wouters wrote:
>
> On Tue, 19 Sep 2023, Paul Hoffman wrote:
>
>> We don't know. It was pointed out in the WG discussion that some PKIX
>> libraries do different types of verification regardless of what you want
>> them t
IETF 114 (we're in a slot with the ADD WG, and
they have three draft that about to go to IESG ballot), but it would be great
if we can spend it working on issues instead of the typical slideware
presentation just listing the issues.
--Paul Hoffman
smime.p7s
Description: S/MI
Belated thanks for your proposed changes! It has taken this time for the three
document authors to be around at the same time.
On Aug 30, 2022, at 2:09 PM, Puneet Sood wrote:
> Suggest DoET or DoQTH as abbreviations for encrypted transports. Using
> DoET in my comments below for conciseness.
) as they
review and hopefully implement the document.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Implementation Requirements) and 9210 (DNS Transport over TCP
> - Operational Requirements).
The document is talking about both. The mechanics have to be in the
implementation, but they have to be turned on in configuration by the operator
deploying the implementation.
--Paul Hoffman
__
lks at the Hackathon
have time to write up their comments.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Mar 2, 2023, at 10:11 AM, Hollenbeck, Scott
wrote:
>
>> -Original Message-
>> From: Paul Hoffman
>> Sent: Wednesday, March 1, 2023 2:51 PM
>> To: Hollenbeck, Scott
>> Cc: dpr...@ietf.org
>> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] Inte
of course we're happy to
revise it during or after WG Last Call if issues are raised.
--Paul Hoffman (also for dkg and Joey)
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Arrrgh, I turned in the wrong version. Please hold for -05.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
catch! We will fix that in the new draft that should
be coming out in a day or so.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
document
be more useful.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
some operational
observations, and move it to standards track".
I'll issue a new draft with the new status, and add text about recursive
resolvers doing DoT and/or DoQ for stub resolvers, as well as being
authoritative servers on the same address.
--Pa
On Jun 12, 2023, at 1:46 AM, Florian Obser wrote:
>
> On 2023-06-10 22:48 UTC, Paul Hoffman wrote:
>> On Jun 10, 2023, at 1:38 PM, Philip Homburg
>> wrote:
>>>
>>>> In such a case, resolvers following
>>>> this protocol will look
;Connection Handling")
>
> should be
>
> | Section 5.5 of [RFC9250] ("Connection Handling")
Fixed.
>
> * 4.6.11. Maintaining Connections
> | Some recursive resolvers looking to amortize connection costs, and to
> | minimize latency MAY choose to synthesize queries to a particular
> | resolver to keep an encrypted transport session active.
>
> s/particular resolver/particular authoritative server/
Fixed.
>
> * 5. IANA Considerations
> odd boiler plate
There is no standard for NXIANA boiler plate. IANA always double-checks the
section when documents move to IETF Last Call.
Thanks again for the thorough review!
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Jul 3, 2023, at 11:19 AM, Peter van Dijk wrote:
>
> On Mon, 2023-07-03 at 10:50 +0200, Peter van Dijk wrote:
>> On Fri, 2023-06-30 at 16:32 +, Paul Hoffman via dnsdir wrote:
>>> The current wording at the end of 4.6.9 is:
>>>But if `R` is unsuccessf
t doesn't mention probing at all, and the root zone that
>> does no probing.
>>
>> I think this section should be removed before publication.
I'd like to follow RFC 7942 (which is also BCP 202) so we don't get in trouble
during the IESG review.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
rs that I didn't know of any IPR on the draft. I make no
assertion whether or not the Verisign IPR even applies to the draft.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
o move to the IESG for publication.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
deals with all of the WG Last Call issues raised, except
one. We didn't understand "## E" in Yorgos' message from April 7. Yorgos: could
you reformulate that concern based on the -06 draft?
> Thanks to everyone who has provided feedback to date!
Indeed! The draft feels much tighter no
resolver on 853. Should we
> | explicitely ban this practice?
Thanks for the specifics! We do explicitly ban this practice, but it is
definitely also worth noting in the document that this could happen. It is
definitely one of the operational considerations.
ple of this?
I was; now I'm not.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
rlier in that same document, it says what is an expriemental protocol, and
this draft doesn't match that description at all.
> So I think it best to no longer delay this draft, publish it as experimental
> and gain experience in how this actually works.
Without more detail about what you want to observe or measure in this
experiment that wouldn't be observed or measured for any normal standard, it's
hard to agree with that assessment.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
inimized.
How would you put that (legitimate!) concern into a criterion for the
experiment?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
xperiment, and then create an updated document that
> becomes a standard.
Yep, that's what we are discussing. What criteria would you use to determine
the success of the experiment?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ess when there are others who have already implemented it.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
n. This is a known problem with the RFC series today.
>
> 4.6.11 “a encrypted” -> “an encrypted”
Fixed, and in a few other places.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
We have turned in -07, which covers Yorgos' issues (thanks!) and the int-dir
review (thanks!). We believe it is ready to move to IETF Review.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns
Here is my first cut of wording for a new operational considerations section to
deal with systems that are both recursive and authoritative on port 853.
Comments are welcome.
As recursive resolvers implement this protocol, authoritative servers will see
more probing on port 853 of IP addresses
53.
The feeling that I got from the other messages is that the server on 853 is not
lame: it is being authoritative for some names and recursive for all others. If
so, it's not lame at all.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
are no criteria that say "this
experiment succeeded" or "this experiment failed".
It will take much less IETF effort to fix the charter now than it will to move
the already-deployed protocol to standards track. We might as well bit the
bureaucratic bullet now and just f
Please see the -10 that was just submitted. Let us know if we need to make more
changes before you want to move this on to IETF Last Call.
--Paul Hoffman (for dkg and Joey as well)
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org
itization scheme in this section while there were two in
> section 3.4
Section 3 is about authoritative servers, Section 4 is about resolvers. In
general, no one gets too concerned about resource exhaustion in resolvers.
After the deployment experiemt, maybe that will change.
We will tu
l make a run at that for -10 as well.
> # Section 4.2
>
> Is there any chance to also use an IPv6 example ?
>
> EV> Obviously, there was no chance ;-)
We chose to keep the examples consistent with each other.
I'll prep a -10, and we'll submit it next week.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
is that uncommon for a name server to have one A record and one record?
I'd rather not go all-IPv6 because some readers might think that the discussion
is for v6-only systems. If possible, I'd rather just say "(with one A record
and one record)".
--Paul Hoffman
___
Belated thanks for this review. I've accepted many of the nits without note,
but some notes below.
--Paul Hoffman
On Jun 9, 2023, at 1:20 PM, Rich Salz via Datatracker wrote:
>
> Reviewer: Rich Salz
> Review result: Has Nits
>
> Sec 2.2 Is the main point of the first p
On Jun 14, 2023, at 10:08 AM, Florian Obser wrote:
>
> On 2023-06-12 19:48 UTC, Paul Hoffman wrote:
>> On Jun 12, 2023, at 1:46 AM, Florian Obser wrote:
>>>
>>> On 2023-06-10 22:48 UTC, Paul Hoffman wrote:
>>>> On Jun 10, 202
al comments already in the repo, and can
put out a new draft with all the current text, then one final one with the
results of the steps above.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
llowing would fix the problem you
describe:
But if `R` is unsuccessful (RCODE other than 0, timeout, connection closed):
Does that fix your case and not break other cases?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
easurement and descriptions of observed attack traffic, if any.
>
Are there additional key metrics we should add to the document?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ot server identifiers), a social media site, some DNS software
developers, and others
=
Can everyone who contributed to this list earlier please verify that their
entry is (entries are) still correct?
Are there other early implementations that we should add?
--Pau
Please accept with a status of "hold for update".
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
201 - 248 of 248 matches
Mail list logo
