Re: [provreg] Standard Extensions

Patrik Fältström <patrik@frobbit.se> Wed, 22 August 2012 11:58 UTC

Return-Path: <patrik@frobbit.se>
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 AE10821F8625 for <provreg@ietfa.amsl.com>; Wed, 22 Aug 2012 04:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.766
X-Spam-Level:
X-Spam-Status: No, score=-100.766 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu4-cTIXajxi for <provreg@ietfa.amsl.com>; Wed, 22 Aug 2012 04:58:30 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3615721F8624 for <provreg@ietf.org>; Wed, 22 Aug 2012 04:58:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B3E5A14FDC6F3; Wed, 22 Aug 2012 13:58:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpvgnd4epAXG; Wed, 22 Aug 2012 13:58:17 +0200 (CEST)
Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 5460714FDC648; Wed, 22 Aug 2012 13:58:17 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: Patrik Fältström <patrik@frobbit.se>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Date: Wed, 22 Aug 2012 13:58:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <57F5CC66-8DF9-40A1-B771-9C8BC4E684C2@frobbit.se>
References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <E18937C9-F2A8-4092-BCC7-375E05E8906C@nzrs.net.nz> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
X-Mailer: Apple Mail (2.1485)
Cc: "provreg@ietf.org" <provreg@ietf.org>
Subject: Re: [provreg] Standard Extensions
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: Wed, 22 Aug 2012 11:58:35 -0000

22 aug 2012 kl. 13:44 skrev "Hollenbeck, Scott" <shollenbeck@verisign.com>:

> At least one person did that, Patrik (and I inadvertently missed them when compiling the list below):
> 
> http://www.ietf.org/mail-archive/web/provreg/current/msg06776.html
> 
> I didn't see any follow-up to the list provides by James. I believe that some of the items in the list below *are* implemented private extensions. Yes, it would be helpful to identify those.
> 
> Could you identify any extensions you've had to implement to work with different registries?

If your question is "what where you forced to implement differently with different registries" the answer is so far for me:

- DNSSEC, clarification if DS or DNSKEY is to be passed to registry
- Notifications (as you listed)
- Deletion of domain names (before expiration)
- Management of NS records when a transfer occurs
- Management of dates for expiration, deactivation etc
- Addition of personal or organisational number (i.e. identifier of the registrant)
- VAT information of registrant
:
:

Let me phrase things differently.

This list...

http://search.cpan.org/~pmevzek/Net-DRI/

...have too many entries.

Make that 25% of what it is now, and you have success.

I.e. OF COURSE I thing it is good if IETF work is starting on these issues that you list, or else we will get even more extensions that are specific per registry. What I am worried about is the lack of interest from registries to try to minimize the number of extensions they have that are private.

Of course, many of these I have now implemented which implies that if they change towards a standard, I have to change my code again :-P, but I rather do that than continue to spend time on endless (as it seems) specific implementations for specific registries.

If there was ONE epp flavor to move towards.

   Patrik

> Scott
> 
>> -----Original Message-----
>> From: Patrik Fältström [mailto:patrik@frobbit.se]
>> Sent: Wednesday, August 22, 2012 7:37 AM
>> To: Hollenbeck, Scott
>> Cc: provreg@ietf.org
>> Subject: Re: [provreg] Standard Extensions
>> 
>> I think registries should first list whatever private extensions they
>> have, and see whether they can not be standardized. Do not increase the
>> number of extensions...
>> 
>>   Patrik
>> 
>> 22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott"
>> <shollenbeck@verisign.com>:
>> 
>>> It's been a long time since I started this thread back in January.
>> Someone recently asked me a question about an EPP extension, so I
>> thought it wise to see if I could revisit the discussion and post a
>> summary. Here's the original question:
>>> 
>>>> Let's assume for a moment that we have enough interest to form a
>>>> working group focused on the development of a set of standard EPP
>>>> extensions. If we had to start writing a charter today, what
>>>> functionality would people most like to see included?
>>> 
>>> and here's a summary of the suggestions (my apologies if I missed
>> any), including new efforts that have recently surfaced:
>>> 
>>> 1. A garbage collection mechanism.
>>> 
>>> 2. Extension for registrars to get registry/zone policy information.
>>> 
>>> 3. Extension to provide account status information to registrars.
>>> 
>>> 4. An IDN extension*.
>>> 
>>> 5. A TLD launch extension*.
>>> 
>>> 6. A trademark management extension*.
>>> 
>>> 7. Standardized registry-to-registrar notifications.
>>> 
>>> 8. An extension for VAT and/or tax ID information.
>>> 
>>> 9. An extension for a legal/personal attribute on contact objects.
>>> 
>>> 10. An extension for additional status value and/or result codes,
>> perhaps with an associated IANA registry.
>>> 
>>> 11. An extension for cryptographic signatures.
>>> 
>>> 12. An extension for delegation errors/warnings.
>>> 
>>> Those that are described in a draft I've seen are marked with an
>> asterisk. IMHO twelve is probably too many to bootstrap a new working
>> group. If we could whittle this down to 6 or 7 AND we have actual
>> drafts written for consideration it may be possible for us to get
>> something going.
>>> 
>>> Which of the above topics has been addressed in a draft? Who is
>> willing to write drafts for those topics that haven't yet been
>> addressed?
>>> 
>>> Scott
>>> _______________________________________________
>>> 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
>