On Dec 14, 2022, at 11:29, Eliot Lear wrote:
>
>
> We're off in the woods again. Let's keep these two principles in mind:
>
> The DNS resolution mechanisms are not expected to resolve, let alone secure
> names ending in .ALT.
> How other resolution mechanisms secure names is their affair.
I
Hi,
On Dec 14, 2022, at 9:33 AM, Jim Reid wrote:
> If these principles apply, why is the IETF bothering with .alt at all?
My impression has been the primary intent is to ensure .ALT is not allocated
for DNS use and secondarily, to try to curtail future discussions of this topic.
FWIW, if my
We're off in the woods again. Let's keep these two principles in mind:
* The DNS resolution mechanisms are not expected to resolve, let alone
secure names ending in .ALT.
* How other resolution mechanisms secure names is their affair.
Therefore, any collisions that occur within .ALT are
> On 14 Dec 2022, at 16:28, Eliot Lear wrote:
>
> We're off in the woods again. Let's keep these two principles in mind:
>
> • The DNS resolution mechanisms are not expected to resolve, let alone
> secure names ending in .ALT.
> • How other resolution mechanisms secure names is
On Dec 14, 2022, at 05:37, Martin Schanzenbach wrote:
>
>
> I think my main issue is the word "wholly".
> The developer cannot be "wholly" responsible.
> I can choose a label (e.g. "foo.alt") that is not already taken right
> now.
> But I cannot really do anything if somebody else comes along
As a note, Warren and I are opening tickets for each suggestion for updates to
the wording in the draft in the GitHub repo for the draft
(https://github.com/wkumari/draft-wkumari-dnsop-alt-tld/issues). When WG Last
Call concludes, we can issue a -20 based on this discussion if the chairs want
On Dec 14, 2022, at 10:27 AM, David Conrad wrote:
>
> Hi,
>
> On Dec 14, 2022, at 9:33 AM, Jim Reid wrote:
>> If these principles apply, why is the IETF bothering with .alt at all?
>
> My impression has been the primary intent is to ensure .ALT is not allocated
> for DNS use
That is
On 14.12.22 12:25, Paul Wouters wrote:
> On Dec 14, 2022, at 11:29, Eliot Lear wrote:
> >
> >
> > We're off in the woods again. Let's keep these two principles in mind:
> >
> > The DNS resolution mechanisms are not expected to resolve, let alone secure
> > names ending in .ALT.
> > How
On 15.12.22 03:51, Paul Wouters wrote:
I don't interpret it as "the person responsible for fixing the
conflict". I think if one opts to use a name under .alt, one has to
engineer in how to deal with conflicts in that namespace. It is a
fundamental feature/bug of it.
That is true with *any*
On Thu, 15 Dec 2022, Martin Schanzenbach wrote:
I am not looking for that. What I said that what this sentence
insinuates is that as a developer I am "wholly responsible" for dealing
with collisions that may occur.
Maybe it is because English is my 2nd language but this rubs me the
wrong
On 14.12.22 10:19, Joe Abley wrote:
> Hi Martin,
>
> On Wed, Dec 14, 2022 at 10:08, Martin Schanzenbach
> wrote:
>
> > "Developers are wholly responsible for dealing with any collisions"
> >
> > I think this is an impossible task and as a developer that is addressed
> > here I have to say that
I think the point here is that collisions within the alt name space are
beyond the scope of this document. Perhaps that's what should be said.
Eliot
On 14.12.22 11:08, Martin Schanzenbach wrote:
Hi Paul,
the draft lgtm. But, the passage regarding collisions because of
the missing registry
Hi Paul,
the draft lgtm. But, the passage regarding collisions because of
the missing registry now contains a regression IMO:
"Developers are wholly responsible for dealing with any collisions"
I think this is an impossible task and as a developer that is addressed
here I have to say that we
Hi Martin,
On Wed, Dec 14, 2022 at 10:08, Martin Schanzenbach
wrote:
> "Developers are wholly responsible for dealing with any collisions"
>
> I think this is an impossible task and as a developer that is addressed
> here I have to say that we cannot do that unilaterally for our
>
14 matches
Mail list logo
