IETF Logo Mail Archive

Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

Andy Newton <andy@arin.net> Wed, 29 October 2014 23:24 UTC

Return-Path: <andy@arin.net>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A81ACD05; Wed, 29 Oct 2014 16:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJcw-YvMMxdC; Wed, 29 Oct 2014 16:24:31 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id E960A1A6F93; Wed, 29 Oct 2014 16:24:30 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id 695F7165005; Wed, 29 Oct 2014 19:24:30 -0400 (EDT)
Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id D2CF6164FF8; Wed, 29 Oct 2014 19:24:29 -0400 (EDT)
Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 29 Oct 2014 19:26:52 -0400
Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 29 Oct 2014 19:24:29 -0400
From: Andy Newton <andy@arin.net>
To: Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)
Thread-Index: AQHP86jbPycVGSxOaEags5rtlyoB6ZxH79KAgAAD+wCAAAbogA==
Date: Wed, 29 Oct 2014 23:24:28 +0000
Message-ID: <7EEC5E39-E7B7-4407-9634-9D13F4EE8075@arin.net>
References: <20141029184749.10576.92440.idtracker@ietfa.amsl.com> <8CD1C8CB-38B4-44AF-A90D-9792FE62EBA3@arin.net> <18AD51DF-27E5-4E8E-85A2-FAB95A5B8EA2@nominum.com>
In-Reply-To: <18AD51DF-27E5-4E8E-85A2-FAB95A5B8EA2@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.149.252.96]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8C083EEFB43D004788D40A8AB2EB938B@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NOrKjiQCvLEPeELsRJIWWGtrl1Y
Cc: "weirds-chairs@tools.ietf.org" <weirds-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-weirds-rdap-query@tools.ietf.org" <draft-ietf-weirds-rdap-query@tools.ietf.org>, "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds/>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2014 23:24:32 -0000

On Oct 29, 2014, at 6:59 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> It should be the case that there isn't more than one way to represent the IP address.   Or else it should be the case that the server is required to accept the IP address no whether it is canonicalized or not.  You have to tell the client what to expect.   If it's okay for the client to send any old syntactically valid IP address, that's fine, but the document doesn't currently say that, and so a server implementor might _assume_ that you mean that only addresses canonicalized according to section 4 of RFC 5952 are permitted.   The point of normative language is to make sure that we don't rely on the implementor to make the same assumptions we made.

Now I understand. Thanks.

>> Nameserver searches return nameserver objects. I don’t know how useful that would be a to a spammer, but to a nameserver operator trying to determine which registrations are pointing to their nameserver, that seems useful.
> 
> Wouldn't they already know, since they configured the name server?

Not necessarily. How a nameserver object is mapped in a registry is not a detail needed to configure a nameserver to accept queries for a domain.

-andy

v2.23.0 | Report a Bug | By Email