IETF Logo Mail Archive

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

Michael Graff <mgraff@isc.org> Tue, 02 February 2010 19:29 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 2BB5A3A68C3; Tue, 2 Feb 2010 11:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2GJG4zDvJlYW; Tue, 2 Feb 2010 11:29:03 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3A8983A68B9; Tue, 2 Feb 2010 11:29:03 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcONI-000JrE-TB for namedroppers-data0@psg.com; Tue, 02 Feb 2010 19:25:24 +0000
Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <mgraff@isc.org>) id 1NcONG-000JqG-JB for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 19:25:22 +0000
Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 082C117D1A4; Tue, 2 Feb 2010 19:25:22 +0000 (UTC)
Received: from bigmac.home.flame.org (unknown [IPv6:2001:4f8:fff9:13:21d:4fff:fe47:6790]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id C0A0C17D192; Tue, 2 Feb 2010 19:25:20 +0000 (UTC)
Message-ID: <4B687C20.1040305@isc.org>
Date: Tue, 02 Feb 2010 13:25:20 -0600
From: Michael Graff <mgraff@isc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
CC: Matthew Dempsky <matthew@dempsky.org>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <973B1F15-E822-491E-89BF-F09FC7E67509@ICSI.Berkeley.EDU> <6e04e83a1002011109u1cd55c99k8b584648184cdc73@mail.gmail.com> <162E0DB1-EC86-4206-AB36-6FEFA786B24C@ICSI.Berkeley.EDU> <6e04e83a1002011402u395f599g74180d28fdbe5707@mail.gmail.com> <939BB577-FDBE-4573-9129-8CA29B0FB493@sackheads.org> <7B06A582-38E3-4387-BA16-932825A4A62B@rfc1035.com> <F2E927AA-B07C-45D0-9D26-AFE8115F2CC2@icsi.berkeley.edu> <B7A5F1C5-E972-4915-A90F-E561B041A133@rfc1035.com> <23AAB144-AF85-45C7-A99C-C1E7A5334F9C@ICSI.Berkeley.EDU> <d791b8791002021046i5049c50anb74273eb0e45b984@mail.gmail.com> <D2A67E02-13DC-452C-8F7C-ABCFF36CD438@ICSI.Berkeley.EDU>
In-Reply-To: <D2A67E02-13DC-452C-8F7C-ABCFF36CD438@ICSI.Berkeley.EDU>
X-Enigmail-Version: 1.0
OpenPGP: id=BE9E0FA6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
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/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010-02-02 12:49 PM, Nicholas Weaver wrote:
> To me it sounds like it should:
> 
> 5.3. Responders who do not understand these protocol extensions are
>      expected to send a response with RCODE NOTIMPL, FORMERR, or
>      SERVFAIL.  Therefore use of extensions should be "probed" such that
>      a responder who isn't known to support them be allowed a retry with
>      no extensions if it responds with such an RCODE.  If a responder's
>      capability level is cached by a requestor, a new probe should be
>      sent periodically to test for changes to responder capability.

"These extensions" means "ENDS0 data type" really.  It is badly worded,
and I will ensure it is corrected in the update I'm (still) working on.

This is a lot like DHCP options, really.  The client can request option
55, but there is no reason the server must understand that, or reply
with option 55 configuration.  The client has to be able to adapt here.

- --Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktofB8ACgkQ+NNi0s9NRJ0fyQCfXT9tqdjUgECIg67VxuSPSzJ6
e18An3ELLEVEPtk2q7ux/yZlAAgWUKja
=Ksoz
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email