Tony Finch writes:
> The draft is operational advice, so I think the relevant advice here is
> that if you are signing your zone with slw NSEC3 parameters, make sure
> your secondaries are willing to serve such a zone first.
[this is sort of unrelated to the call for adoption, is good discus
On Thu, May 20, 2021 at 11:29 AM Ralf Weber wrote:
> Moin!
>
> On 20 May 2021, at 19:59, Eric Orth wrote:
>
> > A big selling point behind why we have client implementers planning to
> > query HTTPS records is the expectation that this will be the only query
> > type we will need to add and that
All
The WGLC has been closed.
There will also be an IETF LC to raise concerns.
tim
On Fri, May 21, 2021 at 2:17 PM Brian Dickson
wrote:
>
>
> On Thu, May 20, 2021 at 11:29 AM Ralf Weber wrote:
>
>> Moin!
>>
>> On 20 May 2021, at 19:59, Eric Orth wrote:
>>
>> > A big selling point behind why
I think there is a need for something similar to RFC3597, except for fields
in a record rather than a BLOB for the record itself.
RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
not for complex RRs.
Context: there is a general problem on sub-field encodings (i.e. which has
I support adoption of this document to provide guidance for operators to
pick sensible NSEC3 parameters and for expected resolver behavior.
-Puneet
On Mon, May 10, 2021 at 4:56 AM Benno Overeinder wrote:
> Hi all,
>
> As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP
> m
