Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

Carlo Contavalli <ccontavalli@google.com> Fri, 29 January 2010 17:41 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008773A6A3A; Fri, 29 Jan 2010 09:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG+D1hbxRS8S; Fri, 29 Jan 2010 09:41:28 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3688E3A6A2A; Fri, 29 Jan 2010 09:41:28 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Naukw-0000qX-4C for namedroppers-data0@psg.com; Fri, 29 Jan 2010 17:35:42 +0000
Received: from [216.239.33.17] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <ccontavalli@google.com>) id 1Naukt-0000ov-63 for namedroppers@ops.ietf.org; Fri, 29 Jan 2010 17:35:39 +0000
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o0THZaIO015127 for <namedroppers@ops.ietf.org>; Fri, 29 Jan 2010 17:35:37 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264786537; bh=8+yrXmt/sxhfw/H0TcTfivQpCE0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fD7NX+L5pS77tdiDsbYWdJfX5gyOUXSf4NP7OuIAMc7AG+c0OlYYhO8C5MVeIOd6c uFYduzpg+CFlZ/5aL/hdA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=l9DlsFVvMtQrk7H6MOoEetsX9u4AYEom2oCRy7DLK6+DKsVl50SgbQhZJ+MAKQcST YbghO9Bhw3C/JWQQrcn4Q==
Received: from pxi38 (pxi38.prod.google.com [10.243.27.38]) by wpaz37.hot.corp.google.com with ESMTP id o0THZZE3011483 for <namedroppers@ops.ietf.org>; Fri, 29 Jan 2010 09:35:35 -0800
Received: by pxi38 with SMTP id 38so1698764pxi.28 for <namedroppers@ops.ietf.org>; Fri, 29 Jan 2010 09:35:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.8.19 with SMTP id 19mr712426wfh.77.1264786535099; Fri, 29 Jan 2010 09:35:35 -0800 (PST)
In-Reply-To: <20100129113254.GA32401@nic.fr>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <6184.1264657589@nsa.vix.com> <20100129113254.GA32401@nic.fr>
From: Carlo Contavalli <ccontavalli@google.com>
Date: Fri, 29 Jan 2010 17:35:15 +0000
Message-ID: <4966825a1001290935v760f26f6r8b236396d988f0de@mail.gmail.com>
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Fri, Jan 29, 2010 at 11:32 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 1) A small an reasonable one, deleting every mention of the
> load-balancing algorithm and just describing an EDNS option for
> carrying the IP address of the desktop client to the authoritative
> name server (which, being authoritative, could do what it wants with
> it). This would suppress one opportunity to troll and would be in line
> with the general IETF rule "protocol, not policy".
That was the intention :-), we'll try to review the document, and
clean up references to any such algorithm if there's still any.

> 2) A more ambitious one (may be too ambitious), to have an EDNS option
> code "Client info", with sub-codes and various fields (and a registry
> at IANA to register these fields) to carry absolutely everything from
> the desktop client to the authoritative name server. IP address
> information would then be just a special case.

Personally, I'd rather have different EDNS options. Eg, we're now
/trying/ to standardize an option to carry the user ip, there's 16 bit
of space to register other options, it's already possible to register
an option to carry my location, or whatever else I want to carry
there?

So we wouldn't have to create a new register, and we wouldn't have to
nest another header that would look very similar to the enclosing
edns0 header, and we wouldn't have to write more code to parse or
handle those options.

But I don't feel strongly, it's just my 2 cents,
Carlo