On 02.08.22 10:35, Joe Abley wrote:
Had I wanted to do so, I would not have approached dnsop in the first place.
Had you wanted to which? I'm confused.
I came to this group because of concerns that Warren raised, and because
the draft sits before me. I have reviewed what discussion I
Interesting bit: the current -gns draft even uses the .pet TLD in an
example, which is a TLD that actually exists in the official global DNS.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi,
Excerpts from Peter Thomassen's message of 2022-08-01 16:57:45 -0400:
>
> On 8/1/22 12:01, Paul Vixie wrote:
> >>
> >> I agree and I think publication of these drafts would be a good idea
> >> (may be with status Experimental since, as Joe Abley said, there is
> >> clearly no IETF
Hi Eliot,
On Aug 2, 2022, at 07:59, Independent Submissions Editor (Eliot Lear)
wrote:
> But what is not reasonable to expect researchers to attempt to enter the
> ICANN arena in order to facilitate a the safe use of a new naming system that
> doesn't require use of the DNS.
This argument
On Aug 2, 2022, at 10:26, Independent Submissions Editor (Eliot Lear)
wrote:
> On 02.08.22 09:56, Joe Abley wrote:
>>
>> If the position of the ISE is to ignore the prior discussion and publish one
>> set of opinions regardless then perhaps it would be more straightforward
>> just to say so.
This is not an oversight (altough I have to admin it did not occur to me
that this a valid DNS TLD at the time of writing).
You can see in Section 7.1 that we also use "www.example.org" in the
draft.
We address the namespace topic in Section 9.9.
As mentioned, the draft currently goes all-in with
Aaaagain
On 02.08.22 09:56, Joe Abley wrote:
If the position of the ISE is to ignore the prior discussion and publish one
set of opinions regardless then perhaps it would be more straightforward just
to say so.
Had I wanted to do so, I would not have approached dnsop in the first
On Aug 2, 2022, at 7:57 AM, Vladimír Čunát
wrote:
>
> Hello.
>
> This line is misleading, I believe:
>
>
>> - RFC8198 describes how a validating resolver can emit fewer queries in
>> signed zones that
>> use NSEC for negative caching.
>
> That RFC describes aggressive caching also for
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7065
> On 2 Aug 2022, at 2:15 am, Independent Submissions Editor (Eliot Lear)
> wrote:
>
>
> On 02.08.22 10:35, Joe Abley wrote:
>>
>>> Had I wanted to do so, I would not have approached dnsop in the first place.
>> Had you wanted to which? I'm confused.
>
> I came to this group because of
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7068
Hello.
This line is misleading, I believe:
- RFC8198 describes how a validating resolver can emit fewer queries
in signed zones that
use NSEC for negative caching.
That RFC describes aggressive caching also for NSEC3 and (positive)
wildcards. (Of course, opt-out NSEC3 records are
On 02/08/2022 13.53, Martin Schanzenbach wrote:
This is not an oversight (altough I have to admin it did not occur to me
that this a valid DNS TLD at the time of writing). [...]
Oh, I understood that this DNSOP thread - notably the first post -
originated as an attempt to reduce collisions
> On 2. Aug 2022, at 14:39, Vladimír Čunát wrote:
>
> On 02/08/2022 13.53, Martin Schanzenbach wrote:
>> This is not an oversight (altough I have to admin it did not occur to me
>> that this a valid DNS TLD at the time of writing). [...]
>>
> Oh, I understood that this DNSOP thread - notably
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7064
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7066
The ISE started this thread with a discussion that included "Whether that means
using TLD labels that begin with _ or whether that means suffixing them with
".ALT", I leave to you experts to sort." There is another forthcoming option
that could be used in draft-schanzen-gns, namely the
This looks correct to me.
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
This should also be RFC 7553 since SCTP is a transport.
On Tue, 2 Aug 2022, RFC Errata System wrote:
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
This looks correct, too.
On Tue, 2 Aug 2022, RFC Errata System wrote:
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report
Hi,
On Aug 2, 2022, at 8:00 AM, Geoff Huston wrote:
>> I came to this group because of concerns that Warren raised, and because the
>> draft sits before me. I have reviewed what discussion I could find in the
>> logs relating to Warren's draft, which amounts to either (a) this is ICANN's
>>
On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" wrote:
>I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism
>in RFC 8198. I left off NSEC3 because I thought that basically all use of
>NSEC3 was with opt-out, but if I'm wrong, I could put it in the text.
Just
Disclaimer: I work for the Internet Society but I am not speaking for them.
On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:
recommends that the ICANN board to pick a string that will never be put into
the DNS root, and thus is usable for systems like GNS.
This was, of course,
This also looke correct.
On Tue, 2 Aug 2022, RFC Errata System wrote:
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report
I just read it and on page 5 it specifically excludes .onion and .gnu as
those do not use the DNS protocol (citing also the alt draft here).
So this is equivalent to the .alt draft only if the private-use TLD is
not limited to private-use DNS queries as investigated in the document.
I find this to
I believe the correct reference is RFC 7553, where section 4.1 says the
name of a URI record is _service._transport, just like SRV, and DCCP is a
transport.
On Tue, 2 Aug 2022, RFC Errata System wrote:
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS
On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:
recommends that the ICANN board to pick a string that will never be put
into the DNS root, and thus is usable for systems like GNS.
This was, of course, the whole point of the .alt draft in the first place, at
least when I was
Again RFC 7553 since they're transportts.
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
On Aug 2, 2022, at 1:29 PM, Edward Lewis wrote:
>
> On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman"
> wrote:
>> I would rather mention NSEC/NSEC3 so the reader gets an idea for the
>> mechanism in RFC 8198. I left off NSEC3 because I thought that basically all
>> use of NSEC3 was with
John Levine wrote on 2022-08-01 15:22:
It appears that Paul Vixie said:
i'm particularly interested in whether the root zone should have an NS
for the private-label tld(s) (.alt or ._alt or whatever) with an NS of
"localhost" and a dnssec "opt out" indicator so that these private tlds
can
30 matches
Mail list logo
