Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary

"John Levine" <johnl@taugh.com> Mon, 22 July 2013 02:58 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C557721F85EB for <apps-discuss@ietfa.amsl.com>; Sun, 21 Jul 2013 19:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.867
X-Spam-Level:
X-Spam-Status: No, score=-110.867 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iodObnnK96zb for <apps-discuss@ietfa.amsl.com>; Sun, 21 Jul 2013 19:58:11 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B02B921F86BE for <apps-discuss@ietf.org>; Sun, 21 Jul 2013 19:58:10 -0700 (PDT)
Received: (qmail 49568 invoked from network); 22 Jul 2013 02:58:09 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2013 02:58:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ec9fc1.xn--9vv.k1307; i=johnl@user.iecc.com; bh=fXxzuwJFJQci0NxcEg9owNWD8EB5klI3EKPO4ZKSZ0A=; b=3ceR2i2WMbVkW4yDZJjQPZdwAGIi3KQQT+vReXUvqsItiXhuei6tHpnAJACsLJ1rY4BmuUNqi0sGJwb87Swk+BoW0AobqYGqDiMOvGGYbLl7Per8pvjtSPIlTuiOK4bh3SrO+QgEFm9YGhrR2ndnXyWxeGG1gW6srYH8mSacgbE5GK3tzw/CQMjFuE2ZwH7Apl6e265cZnQhaVS7Vb74RzFMuLx9om6fZVvsbRwWOEHDwIBhQHmPxA7wzejv9Ker
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51ec9fc1.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=fXxzuwJFJQci0NxcEg9owNWD8EB5klI3EKPO4ZKSZ0A=; b=IwMUeCqIM801d5N6/6mXuKI77MQgoAh8JQTsLl9pbStAnTCZvErQ3D+9vYSPCRgCYb1TLZUbnlLs3bVYTpZFQ7hZ3NPPDQdzE/g0x3f4dvYiqq20/Mf+k4cw1LA635oylSGlQQiWfDc1u/aKQ8QsJ4SUaKnB/6Tf0Xs8W54ImzFE1XSVLDsNCsv8zfJGdIt+XxRErAx6u5bKRbstHvZRZwvZ8U4ra/AI1VB6THAx22w5xTUBx1WsXM/UT3Mn1XAd
Date: Mon, 22 Jul 2013 02:57:47 -0000
Message-ID: <20130722025747.55027.qmail@joyce.lan>
From: John Levine <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <20130722024014.GA40429@mx1.yitter.info>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 02:58:14 -0000

>>   aaa.foo.on.ca and bbb.foo.on.ca are the same entity
>> 
>>   aaa.toronto.on.ca and bbb.toronto.on.ca are not
>
>To be clear if slightly pedantic about the example, the current
>registration rules don't permit the first case any more.  Also as I
>understand it, case (2) sort of depends on what you mean by "same
>entity".  Everything of the form [municipality].[province].ca under
>the current rules must be a department of the municipality.  You can't
>register (for instance) somecompany.toronto.on.ca.  This is under the
>CIRA rules for the delegation of [municipality].[province].ca.

That may be the current rule, but I know someone whose domain is
<something>.montreal.qc.ca.  There are of course plenty of other
ccTLDs with irregular registration boundaries, e.g., trieste.it is a
geographic delegation point while triste.it is a registration.

>Now, none of that obviates your basic point, which is that this
>pattern is still possible.  But that argument, it seems to me, leads
>almost inexorably to the conclusion that you almost certainly need to
>descend the tree;

You can use my grosse hackque with the wildcards, where the closest
encloser rule finds the deepest relevant delegation point.

R's,
John