On May 7, 2014, at 1:13 PM, Suzanne Woolf wrote:
> This sounds to me like a) support for working on edns-client-subnet (and
> possibly things like it in the future), with b) a resulting RFC as
> "Informational".
>
> I've found this discussion very helpful in solidifying the thoughts Tim
> al
Dear colleagues,
On the principle that I should work on something instead of talking
about it, I had a look at draft-vandergaast-edns-client-subnet-02. I
have a couple questions and remarks.
First, I'm a little uncomfortable with "optimized reply" as the name
for this. It seems to me that one c
On May 7, 2014, at 3:37 PM, Paul Vixie wrote:
> an rfc is seen by sellers and buyers as an unalloyed good. we can (and i do)
> criticize uneducated people making appeals to authority, but that's a far cry
> from pretending it won't happen or that any undesirable result from its
> happening is
Hi Paul,
On Wed, May 07, 2014 at 03:37:45PM -0700, Paul Vixie wrote:
> keep it civil, please.
I think I was being civil. If you're going to quote simplistic
bromides from the pages of a comic book as the basis of your argument,
you should expect to be teased.
> let me show you something wro
Nicholas Weaver wrote:
> On May 7, 2014, at 10:23 AM, P Vixie wrote:
>
>> Joe... To clarify... Client subnet is not what I an complaining about. It's
>> wide area rdns itself that I think is a bad idea. One reason wide area rdns
>> is a bad idea is that it needs client subnet options.
>>
>> Ce
Andrew Sullivan wrote:
> Dear Uncle Ben,
keep it civil, please.
> On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote:
>> The architectural context of a feature should not be divorced from its
>> specification. RFC is an imprimatur. With great power comes great
>> responsibility.
>>
>
> I
On May 7, 2014, at 12:23 PM, P Vixie wrote:
> Centralized rdns is not necessary and it makes the internet brittle. Better
> alternatives exist. The architecture of DNS assumes localized rdns. If we're
> going to document client subnet then all that advice will have to go into it.
While I am sur
Dear Uncle Ben,
On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote:
> The architectural context of a feature should not be divorced from its
> specification. RFC is an imprimatur. With great power comes great
> responsibility.
>
I disagree with this point of view. I see nothing at all wr
On May 7, 2014, at 10:23 AM, P Vixie wrote:
> Joe... To clarify... Client subnet is not what I an complaining about. It's
> wide area rdns itself that I think is a bad idea. One reason wide area rdns
> is a bad idea is that it needs client subnet options.
>
> Centralized rdns is not necessary
The architectural context of a feature should not be divorced from its
specification. RFC is an imprimatur. With great power comes great
responsibility.
On May 7, 2014 7:18:14 PM CEST, Andrew Sullivan wrote:
>On Wed, May 07, 2014 at 07:12:21PM +0200, P Vixie wrote:
>> Ouch. Well so if a large b
On Wed, May 07, 2014 at 07:12:21PM +0200, P Vixie wrote:
> Ouch. Well so if a large body of ietf participators think wide area rdns is a
> bad idea and that this option should never be recommended then we would
> presumably have to say so in the document which standardized the option.
> Strange.
Joe... To clarify... Client subnet is not what I an complaining about. It's
wide area rdns itself that I think is a bad idea. One reason wide area rdns is
a bad idea is that it needs client subnet options.
Centralized rdns is not necessary and it makes the internet brittle. Better
alternatives
On 7 May 2014, at 13:12, P Vixie wrote:
> Ouch. Well so if a large body of ietf participators think wide area rdns is a
> bad idea and that this option should never be recommended then we would
> presumably have to say so in the document which standardized the option.
> Strange.
I think docu
This sounds to me like a) support for working on edns-client-subnet (and
possibly things like it in the future), with b) a resulting RFC as
"Informational".
I've found this discussion very helpful in solidifying the thoughts Tim already
wrote about, particularly with regards to carrying out our
Ouch. Well so if a large body of ietf participators think wide area rdns is a
bad idea and that this option should never be recommended then we would
presumably have to say so in the document which standardized the option.
Strange.
On May 7, 2014 7:09:26 PM CEST, Andrew Sullivan wrote:
>On Wed
On Wed, May 07, 2014 at 07:06:34PM +0200, P Vixie wrote:
> If ietf documents client-subnet then it should be an FYI.
Can't do that. https://tools.ietf.org/html/rfc6360, "Conclusion of FYI RFC
Sub-Series".
A
--
Andrew Sullivan
a...@anvilwalrusden.com
I think if we want good engineering then we should recommend on host or on net
validating resolvers.
I think if we want interoperability then we have to standardize anything
anybody is doing.
If ietf documents client-subnet then it should be an FYI. That's hardly a death
sentence... Look what
On Wed, May 07, 2014 at 12:36:18PM -0400, Joe Abley wrote:
>
> (a) use of edns-client-subnet effectively involves a large depth of
> undocumented experience and knowledge about specific implementations and
> where those specific implementations are used.
> NAT *is* a bad idea. And the amount of
On 6 May 2014, at 22:34, Doug Barton wrote:
> You could say that I'm arguing 'ad absurdum' here, but I'm not. There really
> are such things as bad ideas, and it's perfectly reasonable for the IETF to
> decide that something is a bad idea, and shouldn't be done. Or at least,
> shouldn't be ma
On Tue, 6 May 2014, Doug Barton wrote:
So NAT is an interesting case, since there's no doubt that the IETF dropped
the ball on that. But the problem there was not that the IETF chose not to
act in order to not support NAT, the problem there was that the collective
decision process failed by de
On 7 May 2014, at 15:11, Stephane Bortzmeyer wrote:
> If I were to document the way the Internet is really working, the RFC
> would be full of "do not forget to insert bugs here", "please do not
> document" and "throw a dice before making a choice".
Surely the experience of getting DNSSEC out th
On May 7, 2014, at 10:11, Stephane Bortzmeyer wrote:
> This is not "standards", it is journalism :-)
>
> If I were to document the way the Internet is really working, the RFC
> would be full of "do not forget to insert bugs here", "please do not
> document" and "throw a dice before making a choi
On Wed, May 07, 2014 at 10:04:13AM -0400,
Edward Lewis wrote
a message of 105 lines which said:
> to record the way in which the Internet is working
This is not "standards", it is journalism :-)
If I were to document the way the Internet is really working, the RFC
would be full of "do not f
On May 6, 2014, at 21:44, Jiankang Yao wrote:
> One view about this issue based on the previous discussion years ago is that
> the dns implementors may choose to tailor the dns response in their own way,
> but ietf is unlikely to standardize it.
At the risk of repeating an unpopular opinion, wh
On Wed, May 07, 2014 at 10:32:46PM +1000,
Mark Andrews wrote
a message of 52 lines which said:
> It's not forbidding single label domain names.
It does and it is explicit about it:
These rules do not make possible the resolution of TLD as Single-
Label Domain Name.
___
In message <20140507103639.ga28...@nic.fr>, Stephane Bortzmeyer writes:
> On Mon, Apr 14, 2014 at 09:41:10PM +0200,
> Daniel Migault wrote
> a message of 63 lines which said:
>
> > Please find draft-mglt-dnsop-search-list-processing-00.txt [1]
>
> > a single label that is 63 characters or l
On Mon, Apr 14, 2014 at 09:41:10PM +0200,
Daniel Migault wrote
a message of 63 lines which said:
> Please find draft-mglt-dnsop-search-list-processing-00.txt [1]
> a single label that is 63 characters or less, starts with a letter,
> ends with a letter or digit, and has as interior character
27 matches
Mail list logo
