Top-reply (not apologizing for doing so, either):
If I read the actual draft correctly, it is _not_ intended to be a DNS
drop-in replacement.
Instead, it is meant to be an _alternative_ to DNS.
So, why even use DNS-compatible label strings? That is an obviously
conflict-causing choice, which is
On Wed, 3 Aug 2022, Dave Crocker wrote:
Original Text
-
| URI| _acct | [RFC6118] |
Corrected Text
--
| URI| _acct | [RFC7566] |
In Spring, 2018 and again in Fall, 2018, there was some focused discussion
(see:
It appears that said:
>Shouldn't the labels for Subtypes also go to this (initial) URI Registry?
Nope. The intent of this registry is to list all of the _tags that one
might run into when setting up a new thing, so you don't collide with
tags that other things already use. The subtype tags only
On 8/3/2022 9:48 AM, Tim Wicinski wrote:
This seems to be the mail thread which discusses 7566/6118 :
https://mailarchive.ietf.org/arch/msg/dnsop/d5KQEP1Ud1TxQpanNMY2_b0CpL8/
that's the second and more substantial thread.
The first brief one began with:
This seems to be the mail thread which discusses 7566/6118 :
https://mailarchive.ietf.org/arch/msg/dnsop/d5KQEP1Ud1TxQpanNMY2_b0CpL8/
On Wed, Aug 3, 2022 at 12:13 PM Dave Crocker wrote:
> On 8/2/2022 8:04 AM, RFC Errata System wrote:
>
> Type: Editorial
> Reported by: Bernie Hoeneisen
>
>
>
Hi Dave
Not sure there is yet another issue around the Enumservices derived URI
label registrations.
As I understand this document (RFC 8552) is based on RFC 7553 regarding
Enumservices, which states:
The Enumservice Registration [RFC6117] parameters are
reversed (i.e., subtype(s)
On 8/2/2022 8:04 AM, RFC Errata System wrote:
Type: Editorial
Reported by: Bernie Hoeneisen
Section: 4.1.2.
Original Text
-
| URI| _acct | [RFC6118] |
Corrected Text
--
| URI| _acct | [RFC7566] |
Notes
-
On Aug 3, 2022, at 8:09 AM, Schanzenbach, Martin
wrote:
> https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00
> does not seem to be a predecessor of
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
You are correct; this was my mistake. draft-wkumari-dnsop-internal
> On 3. Aug 2022, at 16:46, Paul Hoffman wrote:
>
> On Aug 3, 2022, at 12:36 AM, Schanzenbach, Martin
> wrote:
>>
>> Having now read further I am pretty convinced that the advisory is not
>> useful in the context of this thread discussion.
>> Ist sais at the end that [1] was the "impetus"
Perfect, thanks Paul.
On Wed, Aug 3, 2022, 07:50 Paul Hoffman wrote:
> On Aug 3, 2022, at 6:48 AM, Gavin McCullagh wrote:
> >
> >
> > > Nonetheless, the significant deployment of
> > > DNSSEC within some top-level domains (TLDs), and the near-universal
> > > deployment of DNSSEC in the TLDs,
On Aug 3, 2022, at 6:48 AM, Gavin McCullagh wrote:
>
>
> > Nonetheless, the significant deployment of
> > DNSSEC within some top-level domains (TLDs), and the near-universal
> > deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable
> > for implementation by both ordinary and
On Aug 3, 2022, at 12:36 AM, Schanzenbach, Martin
wrote:
>
> Having now read further I am pretty convinced that the advisory is not useful
> in the context of this thread discussion.
> Ist sais at the end that [1] was the "impetus" for the advisory.
Reading a five-year old version of a draft
> Nonetheless, the significant deployment of
> DNSSEC within some top-level domains (TLDs), and the near-universal
> deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable
> for implementation by both ordinary and highly sophisticated domain
> owners.
Maybe it's my lack of dns
Having now read further I am pretty convinced that the advisory is not useful
in the context of this thread discussion.
Ist sais at the end that [1] was the "impetus" for the advisory.
However, [1] states that
"Why not use .alt?
The proposed .alt presudo-TLD is specifically only for use as a
14 matches
Mail list logo
