Hi Joe,
At 10:58 18-02-2014, Joe Abley wrote:
I had some experience with this recently with the document that
became RFC 7043.
Code-point assignment was swift. Implementation in major nameservers
was swift (although one or two of them left the types commented out
in the source until the RFC w
In message
, George Michaelson writes:
>
> in OID space, It was my experience that Russ ran the registry pretty
> open-minded. Its a classic dewey-decimal growing numberfield, so the cost
> burden of carving out a new OID is low, and he was minded to ask basic
> questions, steer you, but in the
in OID space, It was my experience that Russ ran the registry pretty
open-minded. Its a classic dewey-decimal growing numberfield, so the cost
burden of carving out a new OID is low, and he was minded to ask basic
questions, steer you, but in the end, assign a unique value for the wider
public bene
> > I see now that some newer CPE defaults to 8.8.8.8 - at least that
> > eliminates the local implementation bugs...
>
> And I would have gone ahead and implemented it as Autralian Consumer
> Law
Probably true for most jurisdictions running u-verse modems too as
they too had breakage in my (not
In message <20140218234946.10461.qm...@f5-external.bushwire.net>, "Mark Delany"
writes:
> On 19Feb14, Mark Andrews allegedly wrote:
> > The process for getting a new type hasn't been *hard* for a decade
> > now.
> >
> > Nameserver developers have been deploying new types quickly for
> > over a d
On 19Feb14, Mark Andrews allegedly wrote:
> The process for getting a new type hasn't been *hard* for a decade
> now.
>
> Nameserver developers have been deploying new types quickly for
> over a decade now.
>
> Recursive servers have had the bugs w.r.t. handling unknown types
> removed over a dec
On 2014-02-18 19:58, Joe Abley wrote:
> I appreciate that knowing the process made things easier (mainly; I
> was wrong about some things and had to be educated). But I would not
> describe the process as difficult, and certainly not insurmountable.
Agree, and correct (I did the same with URI RR-T
In message <5b5ae40c-6d26-419c-a16a-392af2c33...@hopcount.ca>, Joe Abley writes
:
> On 2014-02-18, at 10:54, SM wrote:
>
> > Seriously, it may take some effort to get things deployed but that is
> not an insurmountable task [1]. One of the problems is that there isn't
> any money in doing that.
On 2014-02-18, at 10:54, SM wrote:
> Seriously, it may take some effort to get things deployed but that is not an
> insurmountable task [1]. One of the problems is that there isn't any money
> in doing that.
>
> [...]
>
> 1. I actually looked into it some time back.
I had some experience
On Feb 18, 2014, at 12:10 PM, Suzanne Woolf wrote:
> Is that a problem you (generically, not just Andrew) see as a concern? If so,
> do you see any general principles for navigating it?
I certainly think it's an important concern. We have the same problem with
DHCP, which is a much simpler p
Hi Andrew,
At 08:44 17-02-2014, Andrew Sullivan wrote:
I am not convinced that DNS belongs in the Internet area. It's an
application. I think if we need a place to discuss broader DNS
innovation, then it should be in Applications.
To say it differently, DNS has a higher impact on applications
On Feb 18, 2014, at 11:57 AM, Andrew Sullivan wrote:
> No. This was precisely my point. For most of the stuff people want,
> the work should be in a WG that does not have "DNS" in its name.
> That's the _key_ point. We protocol weenies need to get out of our
> comfy chair and go learn why in
On Mon, Feb 17, 2014 at 12:57:40PM -0500, Ted Lemon wrote:
>
> Sure. If dnsop wants to do this work, that's fine.
No. This was precisely my point. For most of the stuff people want,
the work should be in a WG that does not have "DNS" in its name.
That's the _key_ point. We protocol weenies n
Hi Patrik,
At 23:15 15-02-2014, Patrik Fältström wrote:
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT resource record.
In other words, it is only possible to use one of
the co
On Feb 17, 2014, at 1:58 PM, Olafur Gudmundsson wrote:
> The problem with long lived groups is you never know when new useful work
> will show up,
> killing groups or just the threat of killing a WG seems to bring out
> innovation.
Yup, that's how DNSIND turned into DNSEXT. :}
_
On Feb 17, 2014, at 1:44 PM, David Conrad wrote:
> Perhaps this is the problem that should be solved?
I don't know how practical that is. Brian and I have talked about doing
one-off meetings when we want to discuss DNS extensions at IETF meetings, since
we have the dnsext mailing list for ema
On Feb 17, 2014, at 11:22 AM, Ted Lemon wrote:
> On Feb 16, 2014, at 9:03 PM, Paul Wouters wrote:
>> DNSOP needs
>> to broaden its charter, or we need to revive some kind of DNSEXT group.
>
> We would need to find some volunteers to act as co-chair. I don't think
> adding the work to the DN
On 2/17/14, 1:35 PM, Ted Lemon wrote:
On Feb 17, 2014, at 1:15 PM, David Conrad wrote:
Given experiences, I have to wonder if the whole idea of a long-term working
group just leads to dysfunction -- perhaps the IETF version of an echo chamber
(or perhaps even inbreeding). Perhaps a better a
On Feb 17, 2014, at 1:15 PM, David Conrad wrote:
> Ted,
>
> On Feb 17, 2014, at 9:57 AM, Ted Lemon wrote:
>> If dnsop wants to do this work, that's fine.
>
> Given the various topics being discussed in DNSOP and the relatively high
> interest/reviews/comments/etc being shown, I think DNSOP i
On Feb 17, 2014, at 10:35 AM, Ted Lemon wrote:
> However, creating working groups is a pretty heavyweight process
Perhaps this is the problem that should be solved?
> Possibly rotating working group chairs more frequently would work in such
> cases.
This seems to imply the working group chairs
On Feb 17, 2014, at 1:38 PM, Paul Hoffman wrote:
> Given your second paragraph, why create a new WG which will be an attractive
> nuisance? Andrew's proposal of letting WGs that want the innovations seems
> less likely to rekindle the dysfunction.
Then you're just moving the dysfunction to the
On Feb 17, 2014, at 9:57 AM, Ted Lemon wrote:
> On Feb 17, 2014, at 11:44 AM, Andrew Sullivan wrote:
>> Why shouldn't that work go on in the WGs that want the innovations in
>> question? Why shouldn't people who know about the DNS involve
>> themselves in the protocols that want to use these in
On Feb 17, 2014, at 1:15 PM, David Conrad wrote:
> Given experiences, I have to wonder if the whole idea of a long-term working
> group just leads to dysfunction -- perhaps the IETF version of an echo
> chamber (or perhaps even inbreeding). Perhaps a better approach would be to
> use something
Ted,
On Feb 17, 2014, at 9:57 AM, Ted Lemon wrote:
> If dnsop wants to do this work, that's fine.
Given the various topics being discussed in DNSOP and the relatively high
interest/reviews/comments/etc being shown, I think DNSOP is working fine.
> Unfortunately, the dysfunction will arise wher
On Feb 17, 2014, at 11:44 AM, Andrew Sullivan wrote:
> Why shouldn't that work go on in the WGs that want the innovations in
> question? Why shouldn't people who know about the DNS involve
> themselves in the protocols that want to use these innovations so
> that, instead of being Defenders of th
On 2014-02-17, at 11:58, joel jaeggli wrote:
> On 2/16/14, 8:48 AM, Joe Abley wrote:
>
>> We can't do anything that will cause larger responses, because EDNS
>> support is not widespread, and in any case the network can't reliably
>> deliver fragments.
>
> in the context of reflection attacks
On 2/16/14, 8:48 AM, Joe Abley wrote:
>
> We can't do anything that will cause larger responses, because EDNS
> support is not widespread, and in any case the network can't reliably
> deliver fragments.
in the context of reflection attacks (next paragraph) more packets is
perhaps not the most he
I am not convinced that DNS belongs in the Internet area. It's an
application. I think if we need a place to discuss broader DNS
innovation, then it should be in Applications.
But I also have pretty strong doubts that "DNS innovation" needs a
place for such discussion, on the grounds that when w
On Feb 16, 2014, at 9:03 PM, Paul Wouters wrote:
> DNSOP needs
> to broaden its charter, or we need to revive some kind of DNSEXT group.
We would need to find some volunteers to act as co-chair. I don't think
adding the work to the DNSOP charter is the right thing to do, although I am
not wed
On 17/02/2014, at 5:48 am, Joe Abley wrote:
>
> On 2014-02-16, at 11:39, Patrik Fältström wrote:
>
>> - We can not use new RR Types, lets use A and TXT
>> - DNSSEC will never take off
>> - Lets just use HTTP for transport
>
> I think we are suffering from a knee-jerk instinct to say no to id
>The largest problem for IETF and DNS innovation is that the consensus in
>IETF seems to be that innovation of DNS is not possible unless it
>involves reuse of the TXT resource record.
Yes, sort of. The consensus in one part of the IETF is that adding
new RR types is too hard due to DNS server up
On 2/15/14, 9:04 PM, David Conrad wrote:
[perpass dropped from ccs]
On Feb 15, 2014, at 11:57 AM, Paul Wouters wrote:
At ietf87 it was planned to have a discussion at dnsop about this
continued problem of drafts that fall between operations and extensions
and the fact that dnsext closed down
On Sun, 16 Feb 2014, Dave Crocker wrote:
On 2/16/2014 6:03 AM, Patrik Fältström wrote:
I think this email make exactly my point.
Please explain.
By way of anticipating your response, I should not have removed your key
conclusion:
"Unless that is put to rest, we can not do much at all.
Joe Abley wrote:
> ...
> If we believe all these problems are intractable, then we might as well just
> accept that overloading TXT records and reflection attacks are a fact of
> life, and stop worrying about them.
reflection attacks aren't a fact of life. DNS RRL does not require a
forklift u
On 2014-02-16, at 11:39, Patrik Fältström wrote:
> - We can not use new RR Types, lets use A and TXT
> - DNSSEC will never take off
> - Lets just use HTTP for transport
I think we are suffering from a knee-jerk instinct to say no to ideas that we
assume will never work in the real world.
We c
On 2014-02-16 17:39, Patrik Fältström wrote:
> On 2014-02-16 16:52, Paul Hoffman wrote:
>> On Feb 15, 2014, at 11:15 PM, Patrik Fältström wrote:
>>
On 2014-02-16 03:04, David Conrad wrote:
>> Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a
>> seeding ground)?
>>
On 2014-02-16 16:52, Paul Hoffman wrote:
> On Feb 15, 2014, at 11:15 PM, Patrik Fältström wrote:
>
>> > On 2014-02-16 03:04, David Conrad wrote:
>>> >> Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a
>>> >> seeding ground)?
>> >
>> > The largest problem for IETF and DNS in
On 2/16/2014 6:03 AM, Patrik Fältström wrote:
I think this email make exactly my point.
Please explain.
By way of anticipating your response, I should not have removed your key
conclusion:
"Unless that is put to rest, we can not do much at all."
That is demonstrably not true, as well
On 02/16/2014 04:52 PM, Paul Hoffman wrote:
> Sorry, friend, but this is trolling. Or do you believe that DANE is not an
> innovation?
Well, I personally am not so sure that the delta to CERT records (RFC
4398) is all that big,
so is this really the best example you have? ;-).
__
On Feb 15, 2014, at 11:15 PM, Patrik Fältström wrote:
> On 2014-02-16 03:04, David Conrad wrote:
>> Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a
>> seeding ground)?
>
> The largest problem for IETF and DNS innovation is that the consensus in
> IETF seems to be that inno
On 2014-02-16 14:45, Dave Crocker wrote:
> On 2/15/2014 11:15 PM, Patrik Fältström wrote:
>> The largest problem for IETF and DNS innovation is that the consensus in
>> IETF seems to be that innovation of DNS is not possible unless it
>> involves reuse of the TXT resource record.
>
>
> That asser
On 2/15/2014 11:15 PM, Patrik Fältström wrote:
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT resource record.
That assertion is quite wrong on both process and technical groun
On 2014-02-16 03:04, David Conrad wrote:
> Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding
> ground)?
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT
[perpass dropped from ccs]
On Feb 15, 2014, at 11:57 AM, Paul Wouters wrote:
> At ietf87 it was planned to have a discussion at dnsop about this
> continued problem of drafts that fall between operations and extensions
> and the fact that dnsext closed down. Nothing happened at ietf87 or
> ietf8
44 matches
Mail list logo
