On Jul 29, 2022, at 16:49, Paul Wouters wrote:
> Interesting history,
>
> I would have expected (and have taught) that this was by design to not
> disrupt systems with new data unless we knew they were ready for it. I didn’t
> realize we first tried to do it without that 😀
By the time we got
Interesting history,
I would have expected (and have taught) that this was by design to not disrupt
systems with new data unless we knew they were ready for it. I didn’t realize
we first tried to do it without that 😀
Paul
Sent using a virtual keyboard on a phone
> On Jul 29, 2022, at 10:06, E
Hi,
On Jul 29, 2022, at 12:53 AM, Petr Špaček wrote:
> By any chance, do you remember in what iteration the DO=1 in query was
> introduced?
Mid- to late 2000/early 2001, after the 2nd iteration (using Ed’s terminology),
but before the third.
> I wonder what sort of disruption was anticipated/
On 7/29/22, 3:53 AM, "Petr Špaček" wrote:
>By any chance, do you remember in what iteration the DO=1 in query was
>introduced? I wonder what sort of disruption was anticipated/feared.
>
>In hindsight is seems that DO=1 requirement for "new" behavior (like,
>say, adding RRSIG to d
On Fri, 2022-07-29 at 13:50 +, Paul Hoffman wrote:
> On Jul 29, 2022, at 8:58 AM, Peter van Dijk
> wrote:
> > The mention of 5011 talks about the root, but 5011 does not mention the
> > root at all. 5011 is not limited to the root.
>
> It is limited to "trust anchors", and essentially all DN
On Jul 29, 2022, at 8:58 AM, Peter van Dijk wrote:
> The mention of 5011 talks about the root, but 5011 does not mention the
> root at all. 5011 is not limited to the root.
It is limited to "trust anchors", and essentially all DNSSEC trust anchors are
for the DNS root. Still, the wording can be
On Jul 28, 2022, at 2:49 PM, Chris Box wrote:
> Proposed text for the last line:
> means version 3 of the protocol initially defined in {{RFC4033}},
> {{RFC4034}}, and {{RFC4035}}.
>
> Is this better?
Yes, definitely. Incorporated.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic
Hello,
On Thu, 2022-07-28 at 15:06 -0400, Tim Wicinski wrote:
> All
>
>
> This starts a Working Group Last Call for aft-ietf-dnsop-dnssec-bcp,
> "DNS Security Extensions (DNSSEC)"
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-b
Hello,
On Tue, 2022-07-26 at 21:13 +, Suzanne Woolf wrote:
> Dear colleagues,
>
>
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-avoid-fragmentation
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The
> requested status is BCP.
>
> Si
Dear intarea WG,
dnsop WG is working on a document to avoid IP fragmentation in DNS.
Now, the draft is on Working Group Last call in dnsop WG (until August 16).
The draft attempt to advance the goals of RFC 8900 IP Fragmentation
Considered Fragile. (Section 5.1 Domain Name System (DNS))
As one o
Hi Andrew,
On Jul 29, 2022, at 11:14, Andrew McConachie wrote:
> We don’t need a useful standard for NAT to recognize that most
> implementations break PMTUD, and that those implementations of NAT are
> deployed enough to make PMTUD significantly broken.
I was really just suggesting that some
On 28 Jul 2022, at 13:19, Joe Abley wrote:
On Jul 28, 2022, at 12:24, Andrew McConachie wrote:
PMTUD doesn’t work through NAT
That's a very definitive statement considering that there's no useful
standard for NAT.
If there's actual research on this to demonstrate that, pragmatically
s
On 28. 07. 22 22:05, Edward Lewis wrote:
On 7/26/22, 3:05 PM, "DNSOP on behalf of Petr Špaček" wrote:
Interesting history lesson, thank you.
Can you elaborate on
> therefore only one can be signed.
please?
What is the reasoning behind it?
There were a few iterations in the developme
13 matches
Mail list logo
