> I support this. DLV was a mistake
yup. but resistance was futile.
randy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> I remember scaring a bunch of people at a NANOG meeting by suggesting
> that we should have an alternate method of establishing trust, and
> that method should be non-hierarchical (or perhaps
> "counter-hierarchical"). I believe I used "DLV-like" to describe it
> and I remember the reactions I go
> The Special-Use Domain Names Problem Statement document unsurprisingly
> contains a list of problems.
is there a companion document with the list of benefits/advantages? or
is thins just one of those ietf documents from on high meant to kill
something?
randy, who does not have a dog in this fi
>>> The Special-Use Domain Names Problem Statement document unsurprisingly
>>> contains a list of problems.
>>
>> is there a companion document with the list of benefits/advantages?
>
> It's a list of problems, not solutions, so there aren't benefits
> and/or advantages.
so there are no advntage
>> is there a companion document with the list of benefits/advantages?
>> or is thins just one of those ietf documents from on high meant to
>> kill something?
>
> This is a very good question. We weren’t asked to answer that
> question, so we didn’t.
how depressing. one obvious curiousity is w
>> how depressing. one obvious curiousity is who asked the one-sided
>> question? otoh, maybe i don't want to know. but i wish you had
>> perceived a wider responsibility to the community.
>
> It was discussed at length in the working group, so I would say that
> you could In principle have rai
>> i would offer to put my keyboard where my mouth is. but i fear that,
>> at the bottom, i would have the unreasonable desire for dns classes
>> to support these kinds of things. i.e. i don't think we have a clean
>> fix. but it would be nice to document the good with the bad.
>
> That sounds
i think avoiding icann is a red herring. if the draft in question had
done a decent job of exploring the taxa of needs for name resolution
outside of the 'normal' topology, we would have the start of a base on
which to discuss this.
randy
___
DNSOP mai
> DNS is not a directory, but when your only off-the-shelf choices are DNS
> or LDAP...
this is the ietf. do not ignore bgp and ldp.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
while i enjoy berating vendors for bugs and poor feature sets as much as
the next person, well maybe more, it's a target rich environment. if we
could come to agreement on what the right thing is, what we actually
want here, we could at least beat them on the right vector.
but as i said at the be
> Complementing what Edmon Chung mentioned that root-servers was already
> reserved in the last new gTLD round, here follows the complete list of
> reserved names:
>
> AFRINIC
> IANA-SERVERS
> NRO
> ALAC
> ICANN
> RFC-EDITOR
> APNIC
> IESG
> RIPE
> ARIN
> IETF
> ROOT-SERVERS
> ASO
> INTERNIC
> RSS
>> this is an amusing list. i can understand EXAMPLE, LOCALHOST, and TEST.
>> maybe even WHOIS and WWW. but the rest sure look as if lawyers wanted
>> and got what is in effect a super trademark.
>
> Its also missing one thats actually really important to be reserved:
> .onion.
very much agree
> What problem are we specifically trying to solve here again?
not break things that are working
randy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
13 matches
Mail list logo
