IETF Logo Mail Archive

Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt

Michael Young <michael@mwyoung.ca> Thu, 05 January 2012 19:00 UTC

Return-Path: <michael@mwyoung.ca>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB2921F8755 for <provreg@ietfa.amsl.com>; Thu, 5 Jan 2012 11:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level:
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 Pu3tevaHclVA for <provreg@ietfa.amsl.com>; Thu, 5 Jan 2012 11:00:13 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6636321F8742 for <provreg@ietf.org>; Thu, 5 Jan 2012 11:00:13 -0800 (PST)
Received: by vcbfk13 with SMTP id fk13so713463vcb.31 for <provreg@ietf.org>; Thu, 05 Jan 2012 11:00:13 -0800 (PST)
Received: by 10.220.153.134 with SMTP id k6mr1820816vcw.23.1325790012886; Thu, 05 Jan 2012 11:00:12 -0800 (PST)
Received: from [10.98.71.210] ([207.164.79.82]) by mx.google.com with ESMTPS id hk9sm24233633vdb.13.2012.01.05.11.00.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 11:00:12 -0800 (PST)
References: <CB2A85EE.20A23%michael@mwyoung.ca> <B8DCAD5F-5774-4E63-8165-F3E25D8EFD85@frobbit.se>
In-Reply-To: <B8DCAD5F-5774-4E63-8165-F3E25D8EFD85@frobbit.se>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca>
X-Mailer: iPhone Mail (9A405)
From: Michael Young <michael@mwyoung.ca>
Date: Thu, 05 Jan 2012 14:00:06 -0500
To: Patrik Fältström <patrik@frobbit.se>
Cc: "<provreg@ietf.org>" <provreg@ietf.org>
Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2012 19:00:14 -0000

Interesting thoughts - I'm really a big fan of avoiding multiple extensions that effectively do the same thing. I think we could benefit by having some more structure around how ICANN works/depends with IETF efforts. Right now it seems pretty reactive to industry needs versus maybe trying to anticipate needs. 

Michael Young

M:647-289-1220

On 2012-01-05, at 1:49 AM, Patrik Fältström <patrik@frobbit.se> wrote:

> On 5 jan 2012, at 04:44, MICHAEL YOUNG wrote:
> 
>> Sorry do you mean if you were designing this from scratch this is what you
>> would do? Or do you mean this is how you read one of the existing
>> proposals (and by that I mean any of the ones mentioned so far)?
> 
> If we designed epp from the beginning:
> 
> - We would not have the ability for registries to invent their own extensions without IETF review (i.e. like other protocols)
> 
> - We would have optimized a few of the commands (specifically create) so that it is closer to the business models
> 
> Example of the 2nd are all the registries that require delegation at time of registration (something that should be forbidden, but now some registries are like that), that required creation of contact objects and host objects before the domain object is created and glued together. If at that point in time the create fails, the creation of the other objects would have automatically been undone. Maybe as a transaction, I do not know. We should have thought about it harder.
> 
>  Patrik
> 
>> Michael
>> 
>> 
>> 
>> 
>> On 12-01-04 10:34 PM, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
>> 
>>> On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote:
>>> 
>>>> the use cases. Somewhere in all that I noted you were ok with the
>>>> check ext being optional :-)
>>> 
>>> Actually, you misread, then.  I think servers (implementing this
>>> extension) MUST support the extension to check.  Clients MAY send it
>>> or not (which means that implementation is for practical purposes
>>> optional for them.
>>> 
>>> Best,
>>> 
>>> Andrew
>>> _______________________________________________
>>> provreg mailing list
>>> provreg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/provreg
>> 
>> 
>> _______________________________________________
>> provreg mailing list
>> provreg@ietf.org
>> https://www.ietf.org/mailman/listinfo/provreg
>> 
>

v2.23.0 | Report a Bug | By Email