On Mon, Jul 10, 2017 at 11:14:26AM +1000, Mark Andrews wrote:
> b) For DNS tools to add support for allocated data types within X
>months of them being assigned by IANA. Allocated types are
>supposed to have stable wire and presentation formats.
>
> for a reasonable value of X (<= 12?).
In message , Randy Bush writes:
> 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 t
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
On 8 Jul 2017, at 20:58, Mark Andrews wrote:
In message ,
Pete Resnic
k writes:
On 7 Jul 2017, at 19:18, Mark Andrews wrote:
Well use nsupdate. That also ships with the Mac.
Of course doing that likely means I'll have records that don't show
up
in the server UI. Not entirely thrilling. A
On Sun, Jul 09, 2017 at 11:58:51AM +1000, Mark Andrews wrote:
> One can do something similar in any scripting language.
Sure. The people on this list can, and many others too. Still, all of
us together are a tiny proportion of the users that would need to be
able to.
> So no it isn't hard to us
In message , Pete Resnic
k writes:
> On 7 Jul 2017, at 19:18, Mark Andrews wrote:
>
> > In message ,
> > Pete Resnick writes:
> >>
> >> On 6 Jul 2017, at 16:52, Mark Andrews wrote:
> >>
> >>> Or you could stop trying to reinforce the myth that new RR types
> >>> are hard to deploy. They really
On 7 Jul 2017, at 19:18, Mark Andrews wrote:
In message ,
Pete Resnick writes:
On 6 Jul 2017, at 16:52, Mark Andrews wrote:
Or you could stop trying to reinforce the myth that new RR types
are hard to deploy. They really aren't. They actually get used
all the time.
I'm running the latest
On Thu, Jul 6, 2017 at 11:15 AM, John C Klensin wrote:
>
>
> --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
> wrote:
>
> > There are changes to the DNS that are practical and those that
> > are not. For better or worse, I can't see any way that
> > teaching DNS to use new classes m
In message , Pete
Resnick writes:
> [Apologies for the re-send. Using the correct address.]
>
> On 6 Jul 2017, at 16:52, Mark Andrews wrote:
>
> > Or you could stop trying to reinforce the myth that new RR types
> > are hard to deploy. They really aren't. They actually get used
> > all the ti
On Fri, Jul 07, 2017 at 11:27:45AM -0700, william manning wrote:
> You need a better imagination then. mDNS is a crippled DNS implementation
> that was hobbled on purpose. HS was/is an entirely different addressing
> scheme that emerged from project Athena @ MIT. To the extent that when all
>
[Apologies for the re-send. Using the correct address.]
On 6 Jul 2017, at 16:52, Mark Andrews wrote:
Or you could stop trying to reinforce the myth that new RR types
are hard to deploy. They really aren't. They actually get used
all the time.
I'm running the latest version of MacOS Server.
You need a better imagination then. mDNS is a crippled DNS implementation
that was hobbled on purpose. HS was/is an entirely different addressing
scheme that emerged from project Athena @ MIT. To the extent that when all
you have been given is the IN class and it's associated rooted hierarchy,
Mark,
On Jul 6, 2017, 11:56 PM -0700, Mark Andrews , wrote:
> > > Or you could stop trying to reinforce the myth that new RR types
> > > are hard to deploy. They really aren't.
Please stop trying to minimize the amount of work here. They really are. Not
for you, but for the folks who make domain
On Fri, Jul 07, 2017 at 03:32:21PM +0200, David Cake wrote:
> > On 5 Jul 2017, at 10:47 am, Randy Bush wrote:
> >
> > 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' topolog
On Fri, Jul 07, 2017 at 11:37:39AM -0500, Nico Williams wrote:
> On Fri, Jul 07, 2017 at 08:09:30AM -0700, Paul Vixie wrote:
> > Nico Williams wrote:
> > >...
> >
> > ...
> >
> > i know which future i'd rather live in. i also feel in-year pressure to get
> > my work done. i vacillate as to who ge
On Fri, Jul 07, 2017 at 08:09:30AM -0700, Paul Vixie wrote:
> Nico Williams wrote:
> >...
> >
> >I'm well aware that as to clients and servers, deploying new RR types is
> >easy. The hard part is the management backend and UIs. Not all of them
> >allow you to enter raw RDATA (hex-encoded or whate
On Fri, Jul 07, 2017 at 04:56:37PM +1000, Mark Andrews wrote:
> In message <20170707055315.GC3393@localhost>, Nico Williams writes:
> > We've struggled with this in KITTEN WG. Deploying the URI RR type when
> > you're using a hosting service can be anywhere from annoying (must enter
> > raw RDATA)
Nico Williams wrote:
...
I'm well aware that as to clients and servers, deploying new RR types is
easy. The hard part is the management backend and UIs. Not all of them
allow you to enter raw RDATA (hex-encoded or whatever).
We've struggled with this in KITTEN WG. Deploying the URI RR type
If you have a single centralised root for your new class, you will probably
either recreate the problems of ICANN, or create one or more of the problems
that ICANN has very consciously tried to avoid.
If you have a system of name resolution that avoids the need for a centralised
root, you probab
In message <20170707055315.GC3393@localhost>, Nico Williams writes:
> On Fri, Jul 07, 2017 at 07:52:36AM +1000, Mark Andrews wrote:
> > In message <20170706153955.GB3393@localhost>, Nico Williams writes:
> > > So new classes will only be useful to extend the IN-class RR type
> > > namespace. We w
On Fri, Jul 07, 2017 at 07:52:36AM +1000, Mark Andrews wrote:
> In message <20170706153955.GB3393@localhost>, Nico Williams writes:
> > So new classes will only be useful to extend the IN-class RR type
> > namespace. We won't get there. New RR types can be very difficult to
> > deploy due to lack
As for those that think deploying a new class would be hard the
tools that start to lookup records in the class would need to react
to error responses like this with a message saying "please install
root hints for class50 in your DNS recursive server".
[rock:~/git/bind9] marka% dig class50 type1
In message <20170706153955.GB3393@localhost>, Nico Williams writes:
> So new classes will only be useful to extend the IN-class RR type
> namespace. We won't get there. New RR types can be very difficult to
> deploy due to lack of interest by registrars and domain hosting
> services. TXT RRs fo
On Thu, 6 Jul 2017, Randy Bush wrote:
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.
+1
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinf
> 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
On Thu, Jul 06, 2017 at 11:15:34AM -0400, John C Klensin wrote:
> --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
> wrote:
> > The X.500 and UDDI models were broken because there is no
> > point in putting information into a directory if the service
> > can return it in a service hand
--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
wrote:
> There are changes to the DNS that are practical and those that
> are not. For better or worse, I can't see any way that
> teaching DNS to use new classes makes any sense at this point.
> The only point at which it would have
There are changes to the DNS that are practical and those that are not. For
better or worse, I can't see any way that teaching DNS to use new classes
makes any sense at this point. The only point at which it would have made
sense was when internationalization happened. But the path chosen makes
mor
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
In message <7dca3daf1993a2e66915d...@jck-hp5.jck.com>, John C Klensin writes:
>
>
> --On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid
> wrote:
>
> >> On 4 Jul 2017, at 18:49, Paul Vixie wrote:
> >>
> >> while IETF governs the protocol, ICANN only governs the IN
> >> class. i expect that the
John C Klensin wrote:
--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid
wrote:
On 4 Jul 2017, at 18:49, Paul Vixie wrote:
while IETF governs the protocol, ICANN only governs the IN
class. i expect that there will be other classes some day, in
order to avoid some aspect of ICANN.
Attemp
--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid
wrote:
>> On 4 Jul 2017, at 18:49, Paul Vixie wrote:
>>
>> while IETF governs the protocol, ICANN only governs the IN
>> class. i expect that there will be other classes some day, in
>> order to avoid some aspect of ICANN.
>
> Attempts have
Paul,
On Jul 4, 2017, 10:59 AM -0700, Paul Vixie , wrote:
> > > On 4 Jul 2017, at 18:49, Paul Vixie wrote:
> > > while IETF governs the protocol, ICANN only governs the IN class.
Sorry, could you point me to anything that documents this? My impression has
always been that ICANN governs (I'd pr
Jim Reid wrote:
On 4 Jul 2017, at 18:49, Paul Vixie wrote:
while IETF governs the protocol, ICANN only governs the IN class. i
expect that there will be other classes some day, in order to avoid
some aspect of ICANN.
Attempts have already been made to do just that. It would be nice not
to h
On Jul 4, 2017, at 1:53 PM, Jim Reid wrote:
> Attempts have already been made to do just that. It would be nice not to have
> to put out those fires all over again.
Realistically, at some point the damage the ICANN process has done will have to
get fixed, just like the damage the itu did got so
> On 4 Jul 2017, at 18:49, Paul Vixie wrote:
>
> while IETF governs the protocol, ICANN only governs the IN class. i expect
> that there will be other classes some day, in order to avoid some aspect of
> ICANN.
Attempts have already been made to do just that. It would be nice not to have
to
There is no reason USE RULES on the addresses resolved cannot be
published (except perhaps that certain parties in this group doesnt want
that to happen for some reason).
For instance - one could publish a OPT-OUT Statement for Mailing Use
Rules, something that is critically needed in dealing
On Thu, Apr 18, 2013 at 10:10:53AM +0100,
Jim Reid wrote
a message of 15 lines which said:
> > Do people even contemplate new classes anymore?
>
> Yes. A now dead Swiss(?)
He was French. An analysis (in french) of his work is here:
http://www.bortzmeyer.org/net4d.html
__
On 18 Apr 2013, at 04:31, Erik Kline wrote:
> Do people even contemplate new classes anymore?
Yes. A now dead Swiss(?) academic got paid by the ITU to promote this idea 4-5
years ago after he presented it at WSIS and IGF. The concept was to "increase
competition" in the DNS name space. Which w
39 matches
Mail list logo
