Hello.
I'm quite surprised that the IANA section of the draft includes that
registering *flags* is also changed from "Standards Action" to "RFC
Required". While the algorithm space is rather large, that certainly
doesn't apply to the NSEC3 and NSEC3PARAM flags (only 7 remain free).
--Vladim
On Mar 11, 2021, at 2:41 AM, Vladimír Čunát wrote:
>
> I'm quite surprised that the IANA section of the draft includes that
> registering *flags* is also changed from "Standards Action" to "RFC
> Required". While the algorithm space is rather large, that certainly doesn't
> apply to the NSEC3
> On 11 Mar 2021, at 15:38, Paul Hoffman wrote:
>
> The size of the namespace isn't all that relevant in that, for any namespace,
> if it is filling up "too fast", one can quickly change the requirements to be
> more stringent. I'm pretty sure that has happened in the thousands of IANA
> reg
On 3/11/21 4:38 PM, Paul Hoffman wrote:
I'm quite surprised that the IANA section of the draft includes that registering*flags* is also
changed from "Standards Action" to "RFC Required". While the algorithm space
is rather large, that certainly doesn't apply to the NSEC3 and NSEC3PARAM flags
I have a very minor comment on this (excellent) draft:
Assuming it gets approved and published, could the relevant elements also
be filed as "Errata" on the respective RFCs, so they are easy to find and
apply?
Not sure if that is appropriate, but given the implications of not doing
what this draft
Sorry for not thinking of these earlier, not sure if they would add
anything or clarify anything or potentially protect resolvers from DOS
attacks:
- Maybe some text warning about queries with excessive numbers of
labels, and suggestions for limiting their impact? E.g. "If NUM_LABELS is
m
>From the status updates today, I see this draft has expired. I really like
it (and it is quite simple), and would like to see it picked up and
completed (adopted, rough consensus reached, published).
Having reread it and the discussion, I am wondering if useful guidance can
be provided regarding
On Fri, Oct 30, 2020 at 10:03 AM Roy Arends wrote:
> Dear DNS Operations folk,
>
> Matt Larson and I wrote up a method that warns a domain owner of an issue
> with their configuration. The idea is loosely based on DMARC (RFC7489), and
> on Trust Anchor signalling (RFC8145).
>
> The method involve
On Fri, Feb 19, 2021 at 10:58 AM Wes Hardaker wrote:
>
> Greetings all,
>
> Viktor and I have been working on a BCP to provide guidance on selecting
> reasonable NSEC3 parameters. We'd love your feedback and for dnsop to
> consider adopting it.
>
>
> A new version of I-D, draft-hardaker-dnsop-ns