Subject: [eppext] Review of draft-ietf-eppext-reg-05

From: Chris Wright <[email-masked]>
Date: Sat, 21 Jun 2014 13:14:33 +0000

Hi all,

I have finally sat down and had a look at draft-ietf-eppext-reg-05. I am only concerned about one section (admittedly probably the core section of the document). The following text in 3.1.1

"A request to register a new, undeployed extension that duplicates the functionality of an existing, deployed extension should be rejected with guidance provided to the requestor to consider the existing, deployed extension."

In my opinion is too strong and should be revised to something along the lines of the following (I am sure someone else can wordsmith this better than I can):

"A person/entity requesting to register a new, un-deployed extension that includes similar functionality to an existing, registered extension should have that fact pointed out to them and be asked to reconsider their request for registration. Should the person/entity still feel they have a compelling reason to register the extension (which they don't necessarily need to disclose), as long as all other requirements are met, the mere fact of similarity should not be a sufficient reason for rejection." 

Essentially my intention is that any well documented extension specification should be allowed in the registry for a number of reasons:

- 1. If two parties develop extensions in parallel, one shouldn't be locked out just because the other got in first - I certainly would not want to throw away all my engineering effort. Anyone developing a decent extension will actually build it in code first and test it to see if it works properly - before they try to register it (we don't want the registry filling up with abandoned extensions that are going nowhere, not maintained and blocking other extensions). In fact it probably should be a requirement that an extension is deployed in the wild for it to remain registered. Perhaps extensions need more elaborate status than the currently proposed 'active', 'inactive. They almost have a life-cycle:
-- a.  'in-development' - so if two parties are working on the same thing at the same time they can see that
-- b. 'registered' - once it is complete
-- c. 'in-use' - at least one domain name registry is actively using the extension
-- d. 'depreciated' - the extension has been superseded by another extension that enhances the functionality
-- e. 'archived' - an extension that was once 'in-use' but is no longer actively used by any registries
Of course this complicates matters for how we should manage the status' and may not be worth the overhead, but it certainly would make things a lot clearer. I would probably leave it to the person who registered the extension to manage, with expert to step in when required. (Probably with a post to the list first)

- 2. Who is to say that the existing extension is right for another operator - all too often extensions are tightly coupled to implementation details/limitations etc. of the underlying registry., I would not want to find myself in a position of needing to significantly re-engineer a production system to retro-fit someone else extension into it, simply because they got there first. There is always going to be a cost benefit trade of for each individual registry to make, I know there is a dream of creating a single unified set of extensions, but I don't think we can force this (I just don't think it is reality). There can be legal reasons (For example in Australia we have GST not VAT (they are effectively the same thing) but we legally must refer to it as GST. If someone had a VAT extension in the registry, would a GST extension not be allowed as it is a duplicate?), technical reasons and other reasons why it might not always be possible. Having a centralised registry for people to look for prior work before embarking on their own is a good thing, and will help to reduce the number of extensions but forcing it is not the right thing to do, and just won't work, registries will end up just ignoring the extension registry, do what they want to do, and we will be no better off - my view is that being more permissive is a better approach. Just like what happens with software libraries. Look at java libraries, Maven Central is effectively a (limited) registry of the available java libraries, and any good java developer worth there salt will look for an existing library that meets their needs before trying to implement their own, but maven central doesn't disallow libraries that do similar or the same thing from registering themselves. It allows the developers to do the right thing, just as we should trust registries to 'do the right thing' (we are really talking about developers here anyway, so it's built in there DNA) - and know that when they are not 'doing the right thing' they have a damn good reason. With Java libraries eventually popularity wins and a good library becomes the most popular or the most used, and if there is enough outside pressure (in our case registrars) it will become the norm to use a particular ones. It is not our job to become the extension police - we should just facilitate the user community (broader than the IETF community) to be able to influence one another as appropriate. If this is really a big problem, the users (registrars) will unite and force a fix. Having a registry is a good start to that.

- 3. I also think that the text 'duplicates the functionality of' is a very tricky concept to qualify. What if a new extension does part of what an already registered extension does but adds something logical to it, adds enhanced functionality, where it would just be silly to create a further separate extension for? Is this a duplicate? What if an already registered extension is found to be wrong, or unworkable, and a new one is required? These are just two examples I can think of where this defining a 'duplicate' will be hard to judge, I am sure there is many more.

Thanks

Chris

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 22 Jun 2014 15:33:49 +0000

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Chris Wright
> Sent: Saturday, June 21, 2014 9:15 AM
> To: [email-masked]
> Cc: James M. Galvin
> Subject: [eppext] Review of draft-ietf-eppext-reg-05
> 
> Hi all,
> 
> I have finally sat down and had a look at draft-ietf-eppext-reg-05. I
> am only concerned about one section (admittedly probably the core
> section of the document). The following text in 3.1.1
> 
> "A request to register a new, undeployed extension that duplicates the
> functionality of an existing, deployed extension should be rejected
> with guidance provided to the requestor to consider the existing,
> deployed extension."
> 
> In my opinion is too strong and should be revised to something along
> the lines of the following (I am sure someone else can wordsmith this
> better than I can):
> 
> "A person/entity requesting to register a new, un-deployed extension
> that includes similar functionality to an existing, registered
> extension should have that fact pointed out to them and be asked to
> reconsider their request for registration. Should the person/entity
> still feel they have a compelling reason to register the extension
> (which they don't necessarily need to disclose), as long as all other
> requirements are met, the mere fact of similarity should not be a
> sufficient reason for rejection."
> 
> Essentially my intention is that any well documented extension
> specification should be allowed in the registry for a number of
> reasons:
> 
> - 1. If two parties develop extensions in parallel, one shouldn't be
> locked out just because the other got in first - I certainly would not
> want to throw away all my engineering effort. Anyone developing a
> decent extension will actually build it in code first and test it to
> see if it works properly - before they try to register it (we don't
> want the registry filling up with abandoned extensions that are going
> nowhere, not maintained and blocking other extensions). In fact it
> probably should be a requirement that an extension is deployed in the
> wild for it to remain registered. Perhaps extensions need more
> elaborate status than the currently proposed 'active', 'inactive. They
> almost have a life-cycle:
> -- d. 'depreciated' - the extension has been superseded by another
> extension that enhances the functionality
> Of course this complicates matters for how we should manage the status'
> and may not be worth the overhead, but it certainly would make things a
> lot clearer. I would probably leave it to the person who registered the
> extension to manage, with expert to step in when required. (Probably
> with a post to the list first)
> 
> - 2. Who is to say that the existing extension is right for another
> operator - all too often extensions are tightly coupled to
> implementation details/limitations etc. of the underlying registry., I
> would not want to find myself in a position of needing to significantly
> re-engineer a production system to retro-fit someone else extension
> into it, simply because they got there first. There is always going to
> be a cost benefit trade of for each individual registry to make, I know
> there is a dream of creating a single unified set of extensions, but I
> don't think we can force this (I just don't think it is reality). There
> can be legal reasons (For example in Australia we have GST not VAT
> (they are effectively the same thing) but we legally must refer to it
> as GST. If someone had a VAT extension in the registry, would a GST
> extension not be allowed as it is a duplicate?), technical reasons and
> other reasons why it might not always be possible. Having a centralised
> registry for peop!
>  le to loo
>  k for prior work before embarking on their own is a good thing, and
> will help to reduce the number of extensions but forcing it is not the
> right thing to do, and just won't work, registries will end up just
> ignoring the extension registry, do what they want to do, and we will
> be no better off - my view is that being more permissive is a better
> approach. Just like what happens with software libraries. Look at java
> libraries, Maven Central is effectively a (limited) registry of the
> available java libraries, and any good java developer worth there salt
> will look for an existing library that meets their needs before trying
> to implement their own, but maven central doesn't disallow libraries
> that do similar or the same thing from registering themselves. It
> allows the developers to do the right thing, just as we should trust
> registries to 'do the right thing' (we are really talking about
> developers here anyway, so it's built in there DNA) - and know that
> when they are not 'doing !
>  the right
>   thing' they have a damn good reason. With Java libraries eventually
> popularity wins and a good library becomes the most popular or the most
> used, and if there is enough outside pressure (in our case registrars)
> it will become the norm to use a particular ones. It is not our job to
> become the extension police - we should just facilitate the user
> community (broader than the IETF community) to be able to influence one
> another as appropriate. If this is really a big problem, the users
> (registrars) will unite and force a fix. Having a registry is a good
> start to that.
> 
> - 3. I also think that the text 'duplicates the functionality of' is a
> very tricky concept to qualify. What if a new extension does part of
> what an already registered extension does but adds something logical to
> it, adds enhanced functionality, where it would just be silly to create
> a further separate extension for? Is this a duplicate? What if an
> already registered extension is found to be wrong, or unworkable, and a
> new one is required? These are just two examples I can think of where
> this defining a 'duplicate' will be hard to judge, I am sure there is
> many more.

I want to give as much guidance to whomever ends up providing the designated expert function if/when the registry becomes reality. They will certainly encounter requests that we haven't considered, and I'll concede the it may be difficult to accurately define functional duplication - but that's why we're asking people to perform the task. So, I'm more or less OK with Chris' proposal but I do want to question one part of it:

"Should the person/entity still feel they have a compelling reason to register the extension (which they don't necessarily need to disclose)"

I'm OK with the "compelling reason" part, but if the designated expert asks a question and the response is "sorry, I'm not going to explain" (or silence), why do we need designated experts at all? We're currently asking a human (or group of humans) to make a qualitative assessment of every registration request. That task may require dialog. The expert should have the ability to reject a request in the absence of satisfactory answers to their questions. So, I'll make a counter proposal:

"A potential registrant who submits a request to register a new, un-deployed extension that includes similar functionality to an existing, registered extension should be made aware of the existing extension. The registrant should be asked to reconsider their request given the existence of a similar extension. Should they decline to do so perceived similarity should not be a sufficient reason for rejection as long as all other requirements are met."

I think this addresses the spirit of Chris' suggested text while preserving the ability of the expert to assess the request.

Scott

---

From: Chris Wright <[email-masked]>
Date: Sun, 22 Jun 2014 15:50:07 +0000

Thanks Scott,

I like your suggested wording. If we added that I think the document is in a good place.

Thanks

Chris

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]] 
Sent: Monday, 23 June 2014 1:34 AM
To: Chris Wright; [email-masked]
Cc: James M. Galvin
Subject: RE: Review of draft-ietf-eppext-reg-05

> -- e. 'archived' - an extension that was once 'in-use' but is no 
> longer actively used by any registries Of course this complicates 
> matters for how we should manage the status'
> and may not be worth the overhead, but it certainly would make things 
> a lot clearer. I would probably leave it to the person who registered 
> the extension to manage, with expert to step in when required. 
> (Probably with a post to the list first)
> 
> would not want to find myself in a position of needing to 
> significantly re-engineer a production system to retro-fit someone 
> else extension into it, simply because they got there first. There is 
> always going to be a cost benefit trade of for each individual 
> registry to make, I know there is a dream of creating a single unified 
> set of extensions, but I don't think we can force this (I just don't 
> think it is reality). There can be legal reasons (For example in 
> Australia we have GST not VAT (they are effectively the same thing) 
> but we legally must refer to it as GST. If someone had a VAT extension 
> in the registry, would a GST extension not be allowed as it is a 
> duplicate?), technical reasons and other reasons why it might not 
> always be possible. Having a centralised registry for peop!
>  le to loo
> popularity wins and a good library becomes the most popular or the 
> most used, and if there is enough outside pressure (in our case 
> registrars) it will become the norm to use a particular ones. It is 
> not our job to become the extension police - we should just facilitate 
> the user community (broader than the IETF community) to be able to 
> influence one another as appropriate. If this is really a big problem, 
> the users
> what an already registered extension does but adds something logical 
> to it, adds enhanced functionality, where it would just be silly to 
> create a further separate extension for? Is this a duplicate? What if 
> an already registered extension is found to be wrong, or unworkable, 
> and a new one is required? These are just two examples I can think of 
> where this defining a 'duplicate' will be hard to judge, I am sure 
> there is many more.

Scott

---

From: Frederico A C Neves <[email-masked]>
Date: Mon, 30 Jun 2014 10:30:40 -0300

Sorry for the late answer,

> > Subject: [eppext] Review of draft-ietf-eppext-reg-05
...
> I think this addresses the spirit of Chris' suggested text while preserving the ability of the expert to assess the request.

I support Chris's suggestions and Scott's text.

Fred