headers
Hollenbeck, Scott | 18 Jan 2012 13:50
Picon
Favicon

Standard Extensions

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?

If there really is interest I will offer to help us get organized.

Scott
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Keith Gaughan | 18 Jan 2012 14:20
Favicon
Gravatar

Re: Standard Extensions

On 18/01/12 12:50, Hollenbeck, Scott wrote:

> 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?
> 
> If there really is interest I will offer to help us get organized.

I'm interested. I've already proposed the garbage collection mechanism and
both James Gould and I have proposed a mechanism for registrars to get
registry policy information, though I proposed it be done separately from
EPP (though ultimately linked to EPP, and possibly listed in the greeting),
and James proposed the use of an object mapping. Those two are things I
personally would like to see developed, and I'm planning on writing up an
I-D on the former at the very least.

--

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Bruno Prémont | 18 Jan 2012 14:36
Picon
Favicon

Re: Standard Extensions

On Wed, 18 Jan 2012 12:50:11 Hollenbeck, Scott wrote:
> 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?
> 
> If there really is interest I will offer to help us get organized.

Another extension that could be useful and was requested by one of our
registrars would be for them to check their status.

It would need:
- their contact data, similar to aggregation of one or more contact
  objects [admin, tech, billing]
- their credit balance (the most important information)
  it should be possible to add extra information such as soft/hard
  limits and possibly some forecast of probable future needs).
- extra key/value pairs, preferably with a few pre-defined types
  (string, currency, number, array) for further information

--

-- 
Bruno Prémont <bruno.premont <at> restena.lu>
Ingénieur système et développements

Fondation RESTENA
6, rue Coudenhove-Kalergi
L-1359 Luxembourg

Tél: (+352) 424409
Fax: (+352) 422473
(Continue reading)

Permalink | Reply |
headers
Mike O'Connell | 19 Jan 2012 12:15
Picon

Re: Standard Extensions

We (.co.za EPP) have had a few requests for the credit balance from our registrars too, as well as the ability
to fetch an invoice or statement (which I think should remain out-of-band).

Leading from that I think a synchronization extension would be very helpful which could possibly include:

  Domain Listing: I know domain listing functions have come up before but the sheer volume is staggering. 
    What about fine tuning a listing to search by contact and/or creation date? 
    Or retrieving the data in batches and fetching the delta at the end?

  Contact Listing: To list all contacts associated with the registrar as well as very basic information. 

These commands would only be run by a registrar to retrieve their own objects.

--

Michael O'Connell

On 18 Jan 2012, at 3:36 PM, Bruno Prémont wrote:

> On Wed, 18 Jan 2012 12:50:11 Hollenbeck, Scott wrote:
>> 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?
>> 
>> If there really is interest I will offer to help us get organized.
> 
> Another extension that could be useful and was requested by one of our
> registrars would be for them to check their status.
>
(Continue reading)

Permalink | Reply |
headers
MICHAEL YOUNG | 18 Jan 2012 14:48
Picon

Re: Standard Extensions

Happy to help.  Some things on my interest list:

IDNs
Launch Activities
Possibly Trademark extensions and interactions with the Trademark
Clearinghouse
Possibly some work around compliance enforcement measures (in response to
abuse)

Michael Young

On 12-01-18 6:50 AM, "Hollenbeck, Scott" <shollenbeck <at> verisign.com> wrote:

>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?
>
>If there really is interest I will offer to help us get organized.
>
>Scott
>_______________________________________________
>provreg mailing list
>provreg <at> ietf.org
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
(Continue reading)

Permalink | Reply |
headers
Michele Neylon :: Blacknight | 18 Jan 2012 14:50
Picon
Gravatar

Re: Standard Extensions

Wasn't there already some work being done by Gavin Brown and Wil Tan on handling sunrises etc?


On 18 Jan 2012, at 13:48, MICHAEL YOUNG wrote:

> Happy to help.  Some things on my interest list:
> 
> IDNs
> Launch Activities
> Possibly Trademark extensions and interactions with the Trademark
> Clearinghouse
> Possibly some work around compliance enforcement measures (in response to
> abuse)
> 
> 
> Michael Young
> 
> 
> 
> 
> On 12-01-18 6:50 AM, "Hollenbeck, Scott" <shollenbeck <at> verisign.com> wrote:
> 
>> 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?
>> 
>> If there really is interest I will offer to help us get organized.
>> 
>> Scott
(Continue reading)

Permalink | Reply |
headers
Gavin Brown | 18 Jan 2012 15:23
Gravatar

Re: Standard Extensions


On 18/01/2012 13:50, Michele Neylon :: Blacknight wrote:
> Wasn't there already some work being done by Gavin Brown and Wil Tan on handling sunrises etc?

We still intend to develop the LaunchPhase extension draft, but both Wil
and I are very busy right now. Apparently there's a new gTLD round!

One other thing on my wishlist for EPP is an extension to add a
legal/personal attribute to contact objects, for EU data protection laws.

G.

--

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Gould, James | 18 Jan 2012 15:19
Picon
Favicon

Re: Standard Extensions

Scott,

I mirror Michael's interest list with some small additions:

IDNs
Launch Activities (EPP mappings / extensions)
	1. Registrar to Trademark Clearinghouse
	2. Registry to Trademark Clearinghouse
	3. Registrar to Registry
Registry Mapping - Provide features and policies for a TLD or set of
TLD's.  
Consolidate / Standardize Custom Extensions - For example some of the ones
we have created:
	1. IDN Language Tag - Already being worked on with
draft-obispo-epp-idn-00.txt
	2. RGP Poll Mapping
	3. ConsoliDate Mapping
	4. NameStore Mapping - Renamed
	5. Low Balance Mapping
	6. WhoWas Mapping
	7. Client Object Attribute Mapping

I fully support this effort.

--

JG

 
James Gould
(Continue reading)

Permalink | Reply |
headers
Keith Gaughan | 18 Jan 2012 17:47
Favicon
Gravatar

Re: Standard Extensions

On 18/01/12 14:19, Gould, James wrote:

> I mirror Michael's interest list with some small additions:

<snip>

> Launch Activities (EPP mappings / extensions)
> 	1. Registrar to Trademark Clearinghouse
> 	2. Registry to Trademark Clearinghouse
> 	3. Registrar to Registry

Wil Tan's work covers at least the Registrar to Registry part of this well
enough.

> 	2. RGP Poll Mapping

Might it be best to fold this into a revised version of RFC 3915?

> 	5. Low Balance Mapping

This might be best generalised into an account information mapping. It'd be
nice to be able to programmatically update various notification addresses
and balance watermarks in addition to querying or being notified of the
balance.

K.

--

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
(Continue reading)

Permalink | Reply |
headers
Gould, James | 18 Jan 2012 17:56
Picon
Favicon

Re: Standard Extensions

> Wil Tan's work covers at least the Registrar to Registry part of this
>well
> enough.

I believe Wil's work is a good starting point, but it is highly dependent
on the flow of sunrise and the rights periods.  All 3 interfaces are
dependent on each other based on the TMCH flow that has yet been fully
defined.  

> Might it be best to fold this into a revised version of RFC 3915?

I originally asked for this to be in RFC 3915 but there was objection to
it, so I had to create my own custom extension.  Combining these would be
a good item to discuss.

--

JG

 
James Gould
Principal Software Engineer
jgould <at> verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 1/18/12 11:47 AM, "Keith Gaughan" <keith <at> blacknight.com> wrote:
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 18 Jan 2012 15:50
Picon
Gravatar

Re: Standard Extensions

I am happy to help but want live extensions harmonized and standardized before we add even more bloat to the protocol.

   Patrik

On 18 jan 2012, at 14:48, MICHAEL YOUNG <michael <at> mwyoung.ca> wrote:

> Happy to help.  Some things on my interest list:
> 
> IDNs
> Launch Activities
> Possibly Trademark extensions and interactions with the Trademark
> Clearinghouse
> Possibly some work around compliance enforcement measures (in response to
> abuse)
> 
> 
> Michael Young
> 
> 
> 
> 
> On 12-01-18 6:50 AM, "Hollenbeck, Scott" <shollenbeck <at> verisign.com> wrote:
> 
>> 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?
>> 
>> If there really is interest I will offer to help us get organized.
>>
(Continue reading)

Permalink | Reply |
headers
Eric Brunner-Williams | 18 Jan 2012 14:50
Favicon

Re: Standard Extensions

On 1/18/12 7:50 AM, Hollenbeck, Scott wrote:
> If there really is interest I will offer to help us get organized.

I don't know that there is, but if there is I think your offer is both
generous and useful.

Eric
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Ulrich Wisser | 18 Jan 2012 15:09
Picon

Re: Standard Extensions

Definition on notifications from the registry to registrars. (Like i 
proposed i my earlier mail).

The earlier proposed sunrise-period extension

Most european registries have some kind of extension for VAT numbers 
and/or tax-id.

/Ulrich

> 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?
>
> If there really is interest I will offer to help us get organized.
>
> Scott
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Theo Kramer | 18 Jan 2012 15:20
Picon
Favicon

Re: Standard Extensions


On 18 Jan 2012, at 2:50 PM, Hollenbeck, Scott wrote:

> 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?

Zone policy definitions

--

-- 
Regards
Theo

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Howard Eland | 18 Jan 2012 15:26

Re: Standard Extensions

I'll be glad to help as well.

-Howard Eland
Afilias

On Jan 18, 2012, at 6:50 AM, Hollenbeck, Scott wrote:

> 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?
> 
> If there really is interest I will offer to help us get organized.
> 
> Scott
> _______________________________________________
> provreg mailing list
> provreg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Patrick Mevzek | 19 Jan 2012 01:10

Re: Standard Extensions

Hollenbeck, Scott <shollenbeck <at> verisign.com> 2012-01-18 13:51
> 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?

First and foremost, finding an incentive for current registry
operators to implement those extensions instead of their own
proprietary, otherwise we will just have even more extensions and even
less consolidations.
To me, it looks more difficult and more important, than creating the
extensions themselves.

At the very minimum any new extension created that is a factorisation
of extensions already existing should have a section explaining how it
will replace the current existing ones.

You will also soon, I think, hit the kind of question like "is this
not a limit of the protocol, and should'nt the protocol itself be
amended" aka EPP v2.0 ?
I'm thinking for example about result codes that each registry extend
in some way with new values, more or less properly...
Same for object status.

And for something a little more new, handling of contacts and DNSSEC
related content during a domain:transfer.

As for the extensions themselves, the whole section 3 of
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt
may give ideas.
Or the source of the opensource client that made me write this draft
(Continue reading)

Permalink | Reply |
headers
Mike O'Connell | 19 Jan 2012 12:18
Picon

Re: Standard Extensions

> And for something a little more new, handling of contacts and DNSSEC
> related content during a domain:transfer.

This would be extremely handy, if we can specify the future contact and DNSSEC information when performing
the domain:transfer we would save on contact GC (touchy subject). I'll happy assist here...

--

Michael O'Connell
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Hollenbeck, Scott | 19 Jan 2012 13:17
Picon
Favicon

Re: Standard Extensions

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Patrick Mevzek
> Sent: Wednesday, January 18, 2012 7:11 PM
> To: provreg <at> ietf.org
> Subject: Re: [provreg] Standard Extensions
> 
> You will also soon, I think, hit the kind of question like "is this
> not a limit of the protocol, and should'nt the protocol itself be
> amended" aka EPP v2.0 ?
> I'm thinking for example about result codes that each registry extend
> in some way with new values, more or less properly...
> Same for object status.

We've actually considered that question more than once in recent years. I'm still unconvinced that
there's a need to reopen the core protocol, especially for niche data structures that can be specified in
an extension. I don't yet see the benefit outweighing the cost. Having said that, maybe it makes sense to
create a standard extension for additional result codes and status values.

Scott
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Patrick Mevzek | 24 Jan 2012 00:59

Re: Standard Extensions

Hollenbeck, Scott <shollenbeck <at> verisign.com> 2012-01-19 13:18
> Having said that, maybe it makes sense to create a standard extension for additional result codes and
status values.

I believe so.

And then, if you make it happen that everyone switch from their
current homegrown version to this extension, you may find out that all
registries or almost all of them need this extension, which in a way
shows that the feature should be in the core protocol.
But things will technically work out the same way while in an extension.

*If* everyone switches to it.

Which I'm far to believe.

Hence another argument to include it in some EPPv2 if there is some
work on that one day, because then the feature will be "free" when you
switch to this version, no more extension. And in that way it is
really an incentive (one extension less to code for registrars).

--

-- 
Patrick Mevzek
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Hollenbeck, Scott | 24 Jan 2012 12:59
Picon
Favicon

Re: Standard Extensions

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Patrick Mevzek
> Sent: Monday, January 23, 2012 6:59 PM
> To: provreg <at> ietf.org
> Subject: Re: [provreg] Standard Extensions
> 
> Hollenbeck, Scott <shollenbeck <at> verisign.com> 2012-01-19 13:18
> > Having said that, maybe it makes sense to create a standard extension
> for additional result codes and status values.
> 
> I believe so.
> 
> And then, if you make it happen that everyone switch from their
> current homegrown version to this extension, you may find out that all
> registries or almost all of them need this extension, which in a way
> shows that the feature should be in the core protocol.
> But things will technically work out the same way while in an
> extension.
> 
> *If* everyone switches to it.
> 
> Which I'm far to believe.

I'm with you on the switching part, but I'm not convinced that there really is significant demand. How many
registries are using custom result codes and status values?

Scott
_______________________________________________
provreg mailing list
(Continue reading)

Permalink | Reply |
headers
Gould, James | 24 Jan 2012 14:04
Picon
Favicon

Re: Standard Extensions

We haven't had the need for an extension for result codes or status values
for root, .com, .net, .edu, .cc, .tv, .jobs and our additional services
(name suggestion, whowas, etc.).  For .name we only needed to include a
sub-result code of 2305 "Object association prohibits operation" on the
create response of domain and emailfwd for providing more clarity on which
object prohibits the operation (1 "Corresponding service exists" or 2
"Conflicting defensive registration exists").  I'm not sure if any of the
Registrars for .name are utilizing this feature of the "Personal
Registration" extension to drive their client-side logic.  In general we
stick with the result codes and status values defined in the RFC's.

--

JG

 
James Gould
Principal Software Engineer
jgould <at> verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 1/24/12 6:59 AM, "Hollenbeck, Scott" <shollenbeck <at> verisign.com> wrote:

>> -----Original Message-----
>> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
>> Behalf Of Patrick Mevzek
(Continue reading)

Permalink | Reply |
headers
Patrick Mevzek | 25 Jan 2012 01:01

Re: Standard Extensions

Hollenbeck, Scott <shollenbeck <at> verisign.com> 2012-01-24 13:01
> How many registries are using custom result codes and status values?

Indeed, I rewrote myself saying almost any registry, because I had in
mind VeriSign which does not need custom codes.

However as an EPP client implementor I've seen registries using their
own result codes/status values in such ways:
- either just adding items to the associated lists, breaking the EPP
  XML Schema validation (for the brave souls doing it live)
- or adding "sub" values, that is besides standard ones
- or creating a true EPP extension, in the RFC 3735 sense, with new
  values.

Looking at my code I see at least the following:
.FR
.AT / IENUMAT
.BE
.EU
.LU
.NO
.NL
.CA

but I'm not really keeping track of list of specific statuses, so
there may be some more, maybe some registrars could provide more info.

--

-- 
Patrick Mevzek
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Edward Lewis | 19 Jan 2012 17:21
Favicon

Re: Standard Extensions

At 1:10 +0100 1/19/12, Patrick Mevzek wrote:

>First and foremost, finding an incentive for current registry
>operators to implement those extensions instead of their own
>proprietary, otherwise we will just have even more extensions and even
>less consolidations.
>To me, it looks more difficult and more important, than creating the
>extensions themselves.

I think that is a very important point.  In Oct 2009 I began a short 
look into EPP 2 after comments at a CENTR Tech meeting.  There was a 
"bar bof" at the IETF in March 2010 and a follow up discussion at the 
CENTR Tech meeting in May 2010.  (Dates given to set date context.) 
At the follow up, the consensus was that the cost to upgrade from an 
EPP 1 to an EPP 2 was not worth any perceived benefit.

I'm not saying there will never be a need for EPP 2 but Patrick is 
very right.  We have to justify the move to an upgraded EPP, not just 
define a new EPP version.  Analogously, DNSSEC stalled until 
Kaminsky's work increased the "perceived benefit".  DNSSEC didn't 
change and the basic problem it was meant to solve didn't change, but 
the perception of the benefit shifted.  And, to borrow from IPv6, we 
need to consider the transition from EPP as it is today to any follow 
on version.

And I should add this.  Before significant work happens on this list, 
the list has to be publicized as widely as needed.  Part of what was 
learned in 2009-2010 was that once the WG that used to cover this 
list was closed, few newcomers learned of the list.  I'm not saying, 
don't do work but keep in mind there may be interested and informed
(Continue reading)

Permalink | Reply |
headers
Keith Gaughan | 19 Jan 2012 17:49
Favicon
Gravatar

Re: Standard Extensions

On 19/01/12 16:21, Edward Lewis wrote:

> At 1:10 +0100 1/19/12, Patrick Mevzek wrote:
> 
>> First and foremost, finding an incentive for current registry
>> operators to implement those extensions instead of their own
>> proprietary, otherwise we will just have even more extensions and even
>> less consolidations.
>> To me, it looks more difficult and more important, than creating the
>> extensions themselves.

That reminds me of this: http://xkcd.com/927/

> I think that is a very important point.  In Oct 2009 I began a short look into
> EPP 2 after comments at a CENTR Tech meeting.  There was a "bar bof" at the
> IETF in March 2010 and a follow up discussion at the CENTR Tech meeting in May
> 2010.  (Dates given to set date context.) At the follow up, the consensus was
> that the cost to upgrade from an EPP 1 to an EPP 2 was not worth any perceived
> benefit.
> 
> I'm not saying there will never be a need for EPP 2 but Patrick is very
> right.  We have to justify the move to an upgraded EPP, not just define a new
> EPP version.  Analogously, DNSSEC stalled until Kaminsky's work increased the
> "perceived benefit".

Any new extension or object mappings we come up with do have one advantage
given ICANN's new gTLD program. ccTLDs and gTLDs differ in that ccTLDs have
captive national audiences and can largely do what they like. gTLDs are
different: as they're global, they lack the inherent registrant audience of a
new ccTLD would have. Thus any new gTLD is going to be competing with other
(Continue reading)

Permalink | Reply |
headers
Eric Brunner-Williams | 19 Jan 2012 18:39
Favicon

Re: Standard Extensions

On 1/19/12 11:49 AM, Keith Gaughan wrote:
> ... the consensus was
>> that the cost to upgrade from an EPP 1 to an EPP 2 was not worth any perceived
>> benefit. ...

YMMV, but there may a fundamental difference of interests between
registrars selling VGRS inventory and hoping to cover as many other
protocol-and-logically distinct sources of inventory at the lowest
cost and registrars (possibly co-owned by registry market entrants)
hoping to cover some distinct sources of inventory, and incidentally
also selling inventories for which protocol-and-logic clients exist.

Consensus among legacy-centric-registrars isn't in itself attractive
to a registry operator sharing no fate with legacy registry operators,
and adequately served by OT&E interoperable registrars.

Eric

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Ning Kong | 20 Jan 2012 04:18
Picon

Re: Standard Extensions


> 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?
I'm very interested in developing EPP extensions for IDNs (especially for
variant IDNs) in order to simplify the synchronization of some or all the
attributes among variant IDNs. I'd like to write such drafts based on the
ideas of draft-kong-epp-cdn-mapping-00 and
draft-kong-epp-cdn-dnssec-mapping-00.

> If there really is interest I will offer to help us get organized.
Thanks, Scott.
You know, there are a few guys interested in EPP extensions for variant IDNs
on this list. So I was going to organize a bar bof  <at>  IETF 83 to discuss EPP
extensions for (variant) IDNs. But I would be glad if there could be a more
general bof to discuss EPP extensions.

Cheers,
Ning

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Jay Daley | 25 Jan 2012 01:02
Picon
Favicon

Re: Standard Extensions


On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote:

> 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?

Two extensions that are on my todo list to write up but never get to the top:

1.  Cryptographic signatures.   Lots of XML apps do this using a variety of mechanisms:

	- PGP in special tags <pgp></pgp>
	- S/MIME as used in XMPP (Jabber)
	- SAMLv2.0 HTTP POST 'SimpleSign’ Binding
	- Detached PGP signatures (as per .nz DNRS protocol)
	- but not XML-Dsig – complete disaster (http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt)

2.  Delegation errors/warnings.  A variety of TLDs check the delegation data and the nameservers before
entering the data into their zones (note, in .nz we do not).  Such checks include whether the nameserver are
serving the zone, whether the serial numbers are the same, whether all the authorities reported are being
configured in the parent zone and so on.  

A standard extension around this would be useful for
- a TLD that does checks advertising that fact (and what those checks are)
- reporting failures if doing checks
- optional support for a TLD that will provide this information to a registrar upon request, but not run
proactive checks or interfere with the delegation process

Then there is the big change to the core protocol I've always wanted to do:
(Continue reading)

Permalink | Reply |
headers
Gavin Brown | 25 Jan 2012 10:43
Gravatar

Re: Standard Extensions


On 25/01/2012 00:02, Jay Daley wrote:
> 
> On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote:
> > Two extensions that are on my todo list to write up but never get to
the top:
> 
> 1.  Cryptographic signatures.   Lots of XML apps do this using a variety of mechanisms:
> 
> 	- PGP in special tags <pgp></pgp>
> 	- S/MIME as used in XMPP (Jabber)
> 	- SAMLv2.0 HTTP POST 'SimpleSign’ Binding
> 	- Detached PGP signatures (as per .nz DNRS protocol)
> 	- but not XML-Dsig – complete disaster (http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt)

I had a stab at an Internet-Draft for this:

https://raw.github.com/jodrell/draft-brown-eppSig/master/draft-brown-eppsig.txt

There's PHP code that implements signing and validation here:

https://github.com/jodrell/draft-brown-eppSig/tree/master/tests

it uses XML-DSig, which I accept has some issues.

G.

--

-- 
Gavin Brown
Chief Technology Officer
(Continue reading)

Permalink | Reply |
headers
Gould, James | 25 Jan 2012 15:10
Picon
Favicon

Re: Standard Extensions

Jay,

<4.  Currently EPP *defines* a data model for domain name registrations,
which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz
data model).   If the <ICANN data model changes at any point then amending
EPP will require lots of effort all round.  It might be better to pre-empt
this by moving to an alternative <approach where the EPP protocol is used
to *describe* the registration data expected.  If then it was agreed that
all gTLD registrations must include say a <registrant type as they have in
.uk, then this could be added merely by updating the description the
servers send rather than the protocol.

Could this item be addressed with a Registry EPP Mapping, as I've shortly
described previously, that provides the meta-data (features and policies)
for each TLD supported by the EPP server?  Examples of attributes that
could be included in a Registry Info Response is defined below.  This EPP
Mapping would be large and it would need to be flexible to define the
features and policies of Registries that support the RFC's.  I would like
to have the working group, if formed, help define this mapping so that
multiple registries support it and it is useful for the registrars.

O name 
O phase 
	- sunrise? (Optional to support existing TLD's)
		+ startDate
		+ endDate
	- rights? (Optional to support existing TLD's)
		+ startDate
		+ endDate
	- open
(Continue reading)

Permalink | Reply |
headers
Theo Kramer | 25 Jan 2012 15:32
Picon
Favicon

Re: Standard Extensions


On 25 Jan 2012, at 4:10 PM, Gould, James wrote:

> Jay,
> 
> <4.  Currently EPP *defines* a data model for domain name registrations,
> which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz
> data model).   If the <ICANN data model changes at any point then amending
> EPP will require lots of effort all round.  It might be better to pre-empt
> this by moving to an alternative <approach where the EPP protocol is used
> to *describe* the registration data expected.  If then it was agreed that
> all gTLD registrations must include say a <registrant type as they have in
> .uk, then this could be added merely by updating the description the
> servers send rather than the protocol.

and

> On 1/24/12 7:02 PM, "Jay Daley" <jay <at> nzrs.net.nz> wrote:
> 
>> And finally something for us to think about:
>> 
>> 4.  Currently EPP *defines* a data model for domain name registrations,
>> which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz
>> data model).   If the ICANN data model changes at any point then amending
>> EPP will require lots of effort all round.  It might be better to
>> pre-empt this by moving to an alternative approach where the EPP protocol
>> is used to *describe* the registration data expected.  If then it was
>> agreed that all gTLD registrations must include say a registrant type as
>> they have in .uk, then this could be added merely by updating the
>> description the servers send rather than the protocol.
(Continue reading)

Permalink | Reply |
headers
Jay Daley | 26 Jan 2012 01:48
Picon
Favicon

Re: Standard Extensions


On 26/01/2012, at 3:10 AM, Gould, James wrote:

> Could this item be addressed with a Registry EPP Mapping, as I've shortly
> described previously, that provides the meta-data (features and policies)
> for each TLD supported by the EPP server?

Possibly, though that is widening it as I was only thinking of registration data.  Specifically I meant an
alternative to RFC 5733 that provides a syntax for a registry to specify what data is expected for their
contact objects.  e,g.

	<field name="name" type="text" pattern="..." mandatory="yes" />
	<field name="voice" type="tel" mandatory="no" />

Using the HTML5 syntax for type, pattern etc so we don't need to reinvent it and so that a registrar can
extract the data and directly create a web form from it.

>  Examples of attributes that
> could be included in a Registry Info Response is defined below.  This EPP
> Mapping would be large and it would need to be flexible to define the
> features and policies of Registries that support the RFC's.  I would like
> to have the working group, if formed, help define this mapping so that
> multiple registries support it and it is useful for the registrars.

Reading your mapping below I would suggest that it might be useful split this out into different chunks and
tackle each one separately.  My initial split would be

(a)  Registration data requirements
(b)  Nameserver data requirements
(c)  Nameserver configuration requirements
(Continue reading)

Permalink | Reply |
headers
Jay Daley | 26 Jan 2012 02:32
Picon
Favicon

Re: Standard Extensions


On 25/01/2012, at 1:02 PM, Jay Daley wrote:

> Then there is the big change to the core protocol I've always wanted to do:
> 
> 3.  Change the command extension mechanism to use SubstitutionGroup to give first class extensions.  

To explain this a bit better, here is some XML Schema:

  <!-- New types and elements to support substitutionGroup -->

  <complexType name="abstractCommandType" abstract="true"/>

  <!-- We need an element here that is the target of a substitutiongroup attribute later on -->
  <element name="abstractCommand" type="epp:abstractCommandType" />

  <complexType name="commandType">
    <sequence>
      <element ref="epp:abstractCommand"/>
      <element name="extension" type="epp:extAnyType"
        minOccurs="0"/>
      <element name="clTRID" type="epp:trIDStringType"
        minOccurs="0"/>      
    </sequence>
  </complexType>

  <element name="check" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="create" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="delete" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="info" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
(Continue reading)

Permalink | Reply |
headers
Hollenbeck, Scott | 22 Aug 2012 13:32
Picon
Favicon

Re: Standard Extensions

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.
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 22 Aug 2012 13:36
Picon
Gravatar

Re: 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 <at> 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*.
(Continue reading)

Permalink | Reply |
headers
Hollenbeck, Scott | 22 Aug 2012 13:44
Picon
Favicon

Re: Standard Extensions

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?

Scott

> -----Original Message-----
> From: Patrik Fältström [mailto:patrik <at> frobbit.se]
> Sent: Wednesday, August 22, 2012 7:37 AM
> To: Hollenbeck, Scott
> Cc: provreg <at> 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 <at> 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
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 22 Aug 2012 13:58
Picon
Gravatar

Re: Standard Extensions

22 aug 2012 kl. 13:44 skrev "Hollenbeck, Scott" <shollenbeck <at> 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/
(Continue reading)

Permalink | Reply |
headers
Antoin Verschuren | 22 Aug 2012 14:16
Picon

Re: Standard Extensions


On 22-08-12 13:58, Patrik Fältström wrote:

> 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

Apart from the DS/DNSKEY question for the delegation, there is also a
request to have an EPP extension for registrars to send ZSK
information (a KEY) to be relayed by the registry in case of a
dns-operator change
(http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04).

As this is a rather new topic, after some registries made their
initial decision to use DS in stead of DNSKEY, I think this might
influence consensus on using DNSKEY. We actually need the "key to be
relayed" as an EPP extension to facilitate automated DNSSEC secure
transfers, and will implement it regardless of standardisation.

But if it needs a request: We would like the "key to be relayed" as a
standard EPP extension. It contains a KEY.

--

-- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands
(Continue reading)

Permalink | Reply |
headers
Linlin Zhou | 23 Aug 2012 06:02
Picon

Re: Standard Extensions

Now we already had the draft-kong-epp-cdn-dnssec-mapping, which is the
DNSSEC mapping for the provisioning and management of Chinese Domain Names.
We also want to do a DNSSEC extension for IDN based on the above draft.

Regards,
Linlin Zhou

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On Behalf
> Of Hollenbeck, Scott
> Sent: Wednesday, August 22, 2012 7:45 PM
> To: Patrik Fältström
> Cc: provreg <at> ietf.org
> Subject: Re: [provreg] Standard Extensions
> 
> 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?
> 
> Scott
(Continue reading)

Permalink | Reply |
headers
Kevin Tse | 23 Aug 2012 06:14
Picon

Re: Standard Extensions

Hello all,

    We have several private extensions which are not summited as rfc
drafts and some extensions which are summited as rfc drafts.

Not summit:
1.Real information extension for the contact object.
2.Information for purveyor for both contact and domain objects.
If you are interest in these, I'd like to share some information.

RFC Draft:
1.CDN(chinese domain name) extension for the domain
object;(draft-kong-epp-cdn-mapping)
2.CDN DNSSEC extension for the domain
object;(draft-kong-epp-cdn-dnssec-mapping)
3.IDN extension for the domain object;(draft-kong-epp-idn-mapping)

BTW,we have interest to form a working group focused on the development
of a set of standard EPP extensions.

Kind regards,
--

-- 
Kevin Tse <xiejiagui <at> cnnic.cn>
CNNIC

On Thu, 2012-08-23 at 12:02 +0800, Linlin Zhou wrote:
> Now we already had the draft-kong-epp-cdn-dnssec-mapping, which is the
> DNSSEC mapping for the provisioning and management of Chinese Domain Names.
> We also want to do a DNSSEC extension for IDN based on the above draft.
>
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 23 Aug 2012 07:37
Picon
Gravatar

Re: Standard Extensions


On 23 aug 2012, at 06:14, Kevin Tse <xiejiagui <at> cnnic.cn> wrote:

>    We have several private extensions which are not summited as rfc
> drafts and some extensions which are summited as rfc drafts.

Btw, I do not as registrar care much whether extensions are RFCs or not, but whether extensions are actually
implemented by all(!) registries, and whether I can communicate with a specific registry without
implementing the extensions that registry support.

I already see registries that require extensions (compared to registries that have features that are
optional implemented as extensions) do not end up being as popular among registrars as other registries.

So, I want to see registries harmonize their implementations. Talk with each other. Coordinate. Have
someone say "we have a cool extension, but we will not implement this before we have ten other registries
also agreeing to implementing it".

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Gavin Brown | 23 Aug 2012 16:50
Gravatar

Re: Standard Extensions

> 11. An extension for cryptographic signatures.

I did a draft for this and mentioned it on this list, it's not been
published as an I-D:

https://raw.github.com/jodrell/draft-brown-eppSig/master/draft-brown-eppsig.txt

G.

--

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
James Mitchell | 24 Aug 2012 03:29
Picon

Re: Standard Extensions

I am having trouble identifying the problem that this extension aims to
solve. Is the use case for this consider transport mechanisms other than
TCP with TLS (and client authentication)? Perhaps someone can enlighten me?

On 24/08/12 12:50 AM, "Gavin Brown" <gavin.brown <at> centralnic.com> wrote:

>> 11. An extension for cryptographic signatures.
>
>I did a draft for this and mentioned it on this list, it's not been
>published as an I-D:
>
>https://raw.github.com/jodrell/draft-brown-eppSig/master/draft-brown-eppsi
>g.txt
>
>G.
>
>-- 
>Gavin Brown
>Chief Technology Officer
>CentralNic Ltd
>Innovative, Reliable and Flexible Registry Services
>for ccTLD, gTLD and private domain name registries
>https://www.centralnic.com/
>
>CentralNic Ltd is a company registered in England and Wales with company
>number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
>_______________________________________________
>provreg mailing list
>provreg <at> ietf.org
>https://www.ietf.org/mailman/listinfo/provreg
(Continue reading)

Permalink | Reply |
headers
Gavin Brown | 24 Aug 2012 10:42
Gravatar

Re: Standard Extensions

On 24/08/2012 02:29, James Mitchell wrote:
> I am having trouble identifying the problem that this extension aims to
> solve. Is the use case for this consider transport mechanisms other than
> TCP with TLS (and client authentication)? Perhaps someone can enlighten me?

The use cases I came up with are described in the draft. ⌘C, ⌘V:

2.  Use Cases

   Digital signatures may be useful in a number of scenarios, such as:

   1.  a registry which charges a very high fee for object provisioning,
       where the cost of refunds and chargebacks is sufficiently high
       that it is necessary to deter frivolous registration requests.

   2.  a registry operating at a high level of security, where defence-
       in-depth and the need to provide a full audit trail require
       strong authenticity of provisioning requests.

   3.  future extensions to EPP may permit use of transport protocols
       such as SMTP [RFC5321] or XMPP [RFC6120], which cannot provide
       end-to-end authenticity of frames.

G.

--

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
(Continue reading)

Permalink | Reply |
headers
Klaus Malorny | 24 Aug 2012 12:35
Picon
Favicon

Re: draft-brown-eppsig, was: Standard Extensions

On 24/08/12 10:42, Gavin Brown wrote:
> On 24/08/2012 02:29, James Mitchell wrote:
>> I am having trouble identifying the problem that this extension aims to
>> solve. Is the use case for this consider transport mechanisms other than
>> TCP with TLS (and client authentication)? Perhaps someone can enlighten me?
>
> The use cases I came up with are described in the draft. ⌘C, ⌘V:
>
> 2.  Use Cases
>
>     Digital signatures may be useful in a number of scenarios, such as:
>
>     1.  a registry which charges a very high fee for object provisioning,
>         where the cost of refunds and chargebacks is sufficiently high
>         that it is necessary to deter frivolous registration requests.
>
>     2.  a registry operating at a high level of security, where defence-
>         in-depth and the need to provide a full audit trail require
>         strong authenticity of provisioning requests.
>
>     3.  future extensions to EPP may permit use of transport protocols
>         such as SMTP [RFC5321] or XMPP [RFC6120], which cannot provide
>         end-to-end authenticity of frames.
>
> G.
>

Hi,

well, I do not consider myself a security expert, but I don't see how XML
(Continue reading)

Permalink | Reply |
headers
Gould, James | 23 Aug 2012 18:39
Picon
Favicon

Re: Standard Extensions

Scott,

Let me add a few more to the list, since we have some custom extensions
that could be of general interest:

1. Account finance (balance, credit limit, available credit, low credit
thresholds) information.  Our custom Low Balance Mapping for poll
messaging of low balance conditions and the Balance Mapping for on-demand
balance commands. 
2. General Key / Value Pair attribute extension which is defined by our
custom Client Object Attribute Extension.
3. A registry routing extension for servers that support more than one
TLD.  Our custom NameStore Extension handles this.
4. Additional domain attributes needed to support transfers.  Our custom
Whois Info Extension supports returning the domain's registrar name, the
registrar whois server, and the registrar URL to support transfers without
the need to hit whois for the information.
5. Add poll messaging for the expiry of restore commands due to not
receiving the restore report command in RFC 3915.  Our custom RGP Poll
Mapping addresses this.
6. Registry mapping that support returning the list of supported TLD's of
the server along with features and policy information for the TLD's.  Past
postings on the list recommended to do this out-of-band, but I still
believe that this information can and should be provided in-band.
7. Support for .NAME objects elsewhere.  Specifically if there is interest
in support for Defensive Registration or NameWatch objects in other
registries.  
8. We have a custom IDN Language Tag extension that can be discussed with
the "An IDN Extension" item.
9. ConsoliDate Mapping (sync command) that supports synchronizing domain
(Continue reading)

Permalink | Reply |
headers
Gavin Brown | 24 Aug 2012 10:42
Gravatar

Re: Standard Extensions

> 10. Premium Domain Extension for dealing with the registration of premium
> domains (is a domain a premium domain, what is the price, etc.).  Our
> custom Premium Domain Extension addresses this.

We have an extension that allows querying of pricing data:

https://www.centralnic.com/company/labs/epp/ext/pricing

G.

--

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |

Gmane