On 5 July 2017 at 13:19, Mark Andrews wrote:
>
> In message
> , Matthew
> Kerwin writes:
>> On 5 July 2017 at 10:02, Mark Andrews wrote:
>> >
>> > Who owns a name is a different question to what machines serve the
>> > tuple and how do you reach those machines. There
>> > is absolutely no rea
In message
, Matthew
Kerwin writes:
> On 5 July 2017 at 10:02, Mark Andrews wrote:
> >
> > Who owns a name is a different question to what machines serve the
> > tuple and how do you reach those machines. There
> > is absolutely no reason why the zones and
> > need to be served by the same
Most of the other application (besides dns) presume a single class, IN,
hence the URL presumption of "DNS name" will -always- be in the IN class.
Technically imprecise and sloppy, but pragmatically it works... until some
loons come along and do something creative with classes. Then all bets
are
On 5 July 2017 at 10:02, Mark Andrews wrote:
>
> Who owns a name is a different question to what machines serve the
> tuple and how do you reach those machines. There
> is absolutely no reason why the zones and
> need to be served by the same machines. There is a argument for
> them both bein
Spencer Dawkins has entered the following ballot position for
draft-ietf-dnsop-sutld-ps-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://
In message <1681359.zi93O8g9E0@tums.local>, Paul Vixie writes:
> On Tuesday, July 4, 2017 8:29:53 PM GMT Ray Bellis wrote:
> > My argument against using an NSEC style bitmap was that in the vast
> > majority of cases it would result in a longer record (and one that's
> > more complicated to decode
In message <2df1afc7-643b-4610-8eb8-0616d3d0b...@fugue.com>, Ted Lemon writes:
> On Jul 4, 2017, at 1:32 PM, william manning
> wrote:
> > I find Randys line of discussion mirroring my own thoughts.
> > And to answer your question above, technically, the TLD org. is a
> > member of the IN class,
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
On Tuesday, July 4, 2017 8:29:53 PM GMT Ray Bellis wrote:
> My argument against using an NSEC style bitmap was that in the vast
> majority of cases it would result in a longer record (and one that's
> more complicated to decode) than a simple list of QTYPEs.
not only that, but the nsec bitmap is c
On 04/07/2017 20:25, Paul Wouters wrote:
> I think the bitmap would be great. Limiting it to some artificial
> special record types just causes people to avoid new records and
> abuse existing records.
My proposed option just uses the QTYPE number directly, so there's no
limitation on record ty
On Tue, 4 Jul 2017, Dave Lawrence wrote:
While for my own imagined use cases three is adequate, such as for
querying MX, A and simultaneously, I also don't see any
compelling reason to drop it from his proposed seven. In my own
scheme I had planned on using a NSEC-like type bitmap, but hav
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
Ted Lemon wrote:
On Jul 4, 2017, at 1:32 PM, william
manning wrote:
I find Randys line of discussion mirroring my own thoughts. And to
answer your question above, technically, the TLD org. is a member
of the IN class, so in the OF class, it is credible to posit the
existence of a org. TLD.
On Jul 4, 2017, at 1:32 PM, william manning wrote:
> I find Randys line of discussion mirroring my own thoughts.
> And to answer your question above, technically, the TLD org. is a member of
> the IN class, so in the OF class, it is credible to posit the existence of a
> org. TLD. TLDs are
On 7/4/17 6:13 AM, Paul Wouters wrote:
>> Although, we should also be a bit careful not to create a new ANY
>> type query that will get abused for amplification, so it should
>> really all have source verified IP transports (DNS-COOKIES, TCP, etc)
Ray Bellis writes:
> I'd rather not constraint thi
I find Randys line of discussion mirroring my own thoughts.
And to answer your question above, technically, the TLD org. is a member
of the IN class, so in the OF class, it is credible to posit the existence
of a org. TLD. TLDs are per class... :)
/Wm
On Tue, Jul 4, 2017 at 7:01 AM, Ted Lemo
Hi folks,
We've posted a new draft on algorithm negotiation which we're hoping to
discuss at IETF99 (and on list of course). I've discussed this topic with
several folks at DNS-OARC recently.
https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00
A New Internet-Draft is available from t
On Jul 4, 2017, at 10:03 AM, Randy Bush wrote:
> maybe it would have helped if i had put UNREASONABLE DESIRE in
> upper case.
My point was just that this wouldn’t be a description of what we might want to
accomplish with special-use names.
___
DNSOP m
>> 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
On Jul 4, 2017, at 9:53 AM, Randy Bush wrote:
> 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 documen
>> 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
On Jul 4, 2017, at 9:37 AM, Randy Bush wrote:
> 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 sa
>> 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
On Jul 4, 2017, at 3:39 AM, Randy Bush wrote:
> 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. It is
>>> 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
On 04/07/2017 11:40, Tim Wicinski wrote:
>
> On 7/4/17 6:13 AM, Paul Wouters wrote:
>>
>> Although, we should also be a bit careful not to create a new ANY
>> type query that will get abused for amplification, so it should
>> really all have source verified IP transports (DNS-COOKIES, TCP,
>> e
Hi
We've uploaded the initial agenda for IETF99. Please take a look and
make sure we didn't miss any requests. We'll flesh this out over the
coming days. If you contacted and are not on the list, please drop us a
note.
The Tuesday Meeting is focused on Current/Existing WG business.
Thursd
The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
___
DNSOP mailing list
DNSOP@ietf.org
> On Jul 4, 2017, at 3:39 AM, Randy Bush wrote:
>
>> 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 a
On 04-07-17 10:35, Mukund Sivaraman wrote:
BIND's resolver ECS does not cache SOA against an address prefix, but on
the authoritative side, note that there is no master file or zone
representation for zones with ECS. It is quite possible that if the auth
side is using different zone sources for
On 7/3/17 12:55 PM, Paul Hoffman wrote:
On 3 Jul 2017, at 5:34, Marc Groeneweg wrote:
Can we drop this claim, and proceed this draft to standard?
There is no need to "drop this claim" in order to move the draft
forward. Plenty of documents in the IETF have claims like this
associated wi
On 7/4/17 6:13 AM, Paul Wouters wrote:
On Mon, 3 Jul 2017, Dave Lawrence wrote:
This is just a "keep alive" so as to keep this draft in consideration as
one of the multiple solutions in this problem space while DNSOP decides
whether this is a problem worth solving.
I still think it's the mos
On Mon, 3 Jul 2017, Dave Lawrence wrote:
This is just a "keep alive" so as to keep this draft in consideration as
one of the multiple solutions in this problem space while DNSOP decides
whether this is a problem worth solving.
I still think it's the most elegant of those proposed ;-)
I whole-
Hi Matthijs
On Tue, Jul 04, 2017 at 09:30:55AM +0200, Matthijs Mekking wrote:
> Hi,
>
> I already said this in private, but will also mention it here: I like
> this idea.
>
> Some initial comments:
>
>
> 1. Why actually define a new option for this. Since the option only uses
> one bit to requ
> 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
Hi,
I already said this in private, but will also mention it here: I like
this idea.
Some initial comments:
1. Why actually define a new option for this. Since the option only uses
one bit to request/acknowledge opportunistic refresh, can't we use one
bit from the Z field from the OPT Record TT
41 matches
Mail list logo
