[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Patrik Fältström <paf@cisco.com>, Andrew Sullivan <ajs@shinkuro.com>
CC: EPP Provreg <ietf-provreg@cafax.se>
From: James Gould <jgould@verisign.com>
Date: Mon, 18 Jan 2010 14:00:14 -0500
In-Reply-To: <A0018B43-25D1-4388-A10E-B95DA259B911@cisco.com>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcqYXhqT7GEIBqXCSMu5GqbrK99YRAAElzMI
Thread-Topic: [ietf-provreg] a question for the list
User-Agent: Microsoft-Entourage/12.23.0.091001
Subject: Re: [ietf-provreg] a question for the list

Title: Re: [ietf-provreg] a question for the list
I personally don’t believe that the creation of a large number of additional mappings and extensions represents an issue with the base protocol, but more of meeting one of the goals of the base protocol in being flexible.  There is no way that everyone could foresee all of the possible needs of a provisioning system, so the ability to create mappings and extensions without touching the base protocol is a huge benefit.  I would like to see as the goal of a working group be the following:

  1. Identify the custom EPP mappings and extensions out there.  Look for overlap and for the potential of some of them moving up the standards track.     
  2. Identify common patterns followed in creating extensions and mappings and document them for consistency.  For example, adding a new verb has been done by creating an extension to an empty update.  I would call the pattern “New EPP Verb” or something like that :-)
  3. Collaborate on additional mappings and extensions for the standards track.  I have a few that I would like to discuss around key management but it would require a good cross-cutting representation of the EPP community.  
  4. Identify areas of improvement of the base protocol that could be addressed by common conventions, extensions, or even on update to the base protocol.

It would be good if each of us could recommend goal items that can be clearly listed in the charter.  

--


JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  
This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.



From: Patrik Fältström <paf@cisco.com>
Date: Mon, 18 Jan 2010 11:21:13 -0500
To: Andrew Sullivan <ajs@shinkuro.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] a question for the list



On 18 jan 2010, at 16.56, Andrew Sullivan wrote:

> Since I'm playing devil's advocate, however (and let me emphasise that
> I'm pushing mostly because I think the best way to make a strong
> argument is to find all its weak points and press on them), where were
> these voices when the protocol was moving along the standards track?

In short, I did rise my voice exactly like this, but the document moved forward, and I thought I was in the minority. I also explicitly then brought up the issue that exist that some policy issues are not well defined, for example on what a transfer (of a domain name) implies regarding sponsor of the contact object that is the holder of the domain.

The conclusion then was that epp _as_defined_ was implemented as nice and clean and obviously works.

The question now is whether we should do eppV2, so I think the questions are different. Or, that I was told ;-)

   Patrik


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se



Home | Date list | Subject list