Subject: [weirds] FW: New Version Notification for draft-kucherawy-weirds-requirements-03.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Mar 2012 03:20:12 +0000

No surprises here, just a long overdue shuffle of the material based on some suggestions by Peter Koch.

-MSK

Subject: New Version Notification for draft-kucherawy-weirds-requirements-03.txt
From: "[email-masked]" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Mar 2012 03:19:21 +0000

A new version of I-D, draft-kucherawy-weirds-requirements-03.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Filename:	 draft-kucherawy-weirds-requirements
Revision:	 03
Title:		 Requirements For Internet Registry Services
Creation date:	 2012-03-26
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
   This document enumerates a base set of requirements to be included in
   any system that provides registration information for Internet
   registration entities, i.e., network and/or domain name assignments.
   Some of these, in turn, will define requirements for registrars;
   this, however, is an issue outside of the scope of this document.

   It is hoped that this work will also influence the development of
   requirements and specifications for domain name registries at some
   point in the future.

The IETF Secretariat

---

From: Andy Newton <[email-masked]>
Date: Tue, 27 Mar 2012 07:48:31 +0200

https://datatracker.ietf.org/doc/draft-kucherawy-weirds-requirements/

---

From: Andy Newton <[email-masked]>
Date: Tue, 27 Mar 2012 08:20:32 +0200

Section 1 of the draft speaks to the background of the effort, noting that Whois is widely deployed and that the CRISP effort failed. Then it launches into "here are new requirements" without stating why things will be different this time. I suggest stealing some of the charter text that talks about RESTful whois services that have been deployed and that have seen good adoption, and how that is our last, best hope for mankind, blah blah blah.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 27 Mar 2012 08:35:34 +0200

Section 3.2 talks about classes of service but neglects the users from whom Whois was originally created: resource registrants and network operators. I suggest creatively appropriating the text from sections 2.4.1 and 2.4.2 from RFC 3707. Actually, all of section 2 of RFC 3707 discusses the many actors and registry types being discussed (though it needs a little reorganization). I don't know if that would help with background on the problem space as I'm always confused about the target audience for these requirements documents.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 27 Mar 2012 08:29:38 +0000

Section 3 item 3 says:

       The protocol MUST consist of a reply syntax that uses a well-
       established generic encoding mechanism such as XML or JSON.  [We
       need to choose one and standardize on it.]

There's really nothing about extensibility, as has been discussed on this list. I suggest the following change:

   For replies, the protocol MUST use a data format that is well-established.
   The use of this data format MUST incorporate necessary features so that core
   data classes can be extended easily and without the need to substitute those
   core data classes to accommodate local or non-standard extensions. This
   extensibility MUST NOT require clients to be programmed for local extensions
   to interpret the standardized data classes.

I think this addresses the point Alessandro Vesely brought up.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Tue, 27 Mar 2012 13:39:52 +0200

Section 3.2

	Instead of: "The design of servers supporting the above protocol needs to consider
   support for the following likely classes of service for clients:"

	I would like something more like:

	"The design of servers supporting the above protocol needs to consider
   support for different classes of service, for example:"

	I mention this because the types of services that each operator may support could (or it will) be dictated by policy. 

 	Section 3.3

	I think that some of the content of this section should be documented in the names and numbers data models. I suggest to remove:

"
      *  The date/time on which the record most recently changed owners/
         registrants

      *  The date/time on which any other part of the record was
         modified

      *  The identifier of the registrar that created the record (e.g.,
         the registrar ID)

      *  The identifier of the registrant that created the record (e.g.,
         the registrant ID)

      *  For network registration records, the range of addresses
         comprising the assigned subnet
"

	Also, I am not sure that all RIRs databases have all these data or if by policy those data is published or not. We analized the current output of RIRs whois and not all of the mentioned above is shown, either because the RIR does not have data about it or because of policy.

In either case I think that "The creation date/time of the record" should be the only one mandatory. I am ok with the last one:

 "A server MAY provide different output based on the nature of the
      client, where such can be definitively determined.
"

	For the security considerations, should be add something about privacy, DoS attacks, loops because of redirection, etc. that operators or the protocol itself should take care of? 

Regards,
/as

On 27 Mar 2012, at 05:20, Murray S. Kucherawy wrote:

> <Mail Attachment.eml>_______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: SM <[email-masked]>
Date: Tue, 27 Mar 2012 04:59:14 -0700

Hi Arturo,
At 04:39 27-03-2012, Arturo Servin wrote:
>         Also, I am not sure that all RIRs databases have all these 
> data or if by policy those data is published or not. We analized 
> the current output of RIRs whois and not all of the mentioned above 
> is shown, either because the RIR does not have data about it or 
> because of policy.

It's an implementation detail.  For the purposes of this group, it 
could be viewed as a policy matter.

Regards,
-sm

---

From: James Mitchell <[email-masked]>
Date: Wed, 28 Mar 2012 02:56:18 +1100

On 27/03/12 10:39 PM, "Arturo Servin" <[email-masked]> wrote:

>
> 	Section 3.3
>
>	I think that some of the content of this section should be documented in
>the names and numbers data models. I suggest to remove:
>
>"

+1

>
>In either case I think that "The creation date/time of the record" should
>be the only one mandatory.

+The requirements document should not prescribe mandatory data elements.
I'm going to go further and say that, at least in the names documents, all
data elements are optional to reduce barriers to adoption for all name
registries. This group may decide that certain elements are recommended,
for example the creation date/time for the benefit of automated spam
detection/filtering tools etc, however this is as far as it should go.

As an example, and with hope that this does not turn into a discussion
regarding specific registry policies, consider the response to a .com.au
whois where the creation and expiration dates are withheld as a means to
reduce frequency of fake renewal notices (registrations are for a fixed 2
year period). By mandating the creation date/time element you will force
their hand to either 1, not implement the product of this group, 2, create
a similar but incompatible response format, or 3, change their policy. I
don't think this group should gamble on 3.

Regards

James

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 27 Mar 2012 19:26:08 +0200

> I think this addresses the point Alessandro Vesely brought up.

Yeah, thanks.  Maybe such considerations belong more to Section 3.3, along
with other reply elements.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 19:31:43 +0000

On 27 Mar 2012, at 17:56, James Mitchell wrote:

registries.

+lots

I had this very conversation with Jim Galvin in the corridors after the meeting - mandating elements is a policy decision.

The protocol need to be flexible enough to permit registries to decide for themselves what data is to be published.

This also needs to be supported by the data formats.  If using XML / XSD, _every_ element needs to be optional.  That may make it impossible to directly import EPP-based schemas, which often have mandatory elements.

Ray

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 27 Mar 2012 12:55:00 -0700

I don't think the plan is to import EPP schemas. The spirit of reutilization is to use the same identifiers where applicable, and/or new ones where it makes the most sense.

I'm not sure about making every element optional. But I do understand the need to adapt the output to registry policy.

Francisco

> This also needs to be supported by the data formats.  If using XML / XSD, _every_ element needs to be optional.  That may make it impossible to directly import EPP-based schemas, which often have m…

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 21:17:42 +0000

On 27 Mar 2012, at 21:55, Francisco Obispo wrote:

draft-sheng-weirds-icann-rws-dnrd-01 says:

--8<--8<--

The formal syntax presented here is a complete schema representation
suitable for automated validation of an XML instance.  It is based on
the object schemas from the Extension Provisioning Protocol (EPP), by
Scott Hollenbeck.  It references and includes the following EPP
schemas:

  [RFC5730] - Extensible Provisioning Protocol (EPP)

  [RFC5731] - Extensible Provisioning Protocol (EPP) Domain Name Mapping

  [RFC5732] - Extensible Provisioning Protocol (EPP) Host Mag

  [RFC5733] - Extensible Provisioning Protocol (EPP) Contact Mapping

--8<--8<--

Does "include" not mean "import" in this context?

IMHO the only element we could mandate is the one that includes the "key" on which the search was just performed.  That at least ensures that you know the response you get is based on the query you sent.  *Everything* else should be left to registry policy.

Ray

---

From: Francisco Arias <[email-masked]>
Date: Tue, 27 Mar 2012 14:26:22 -0700

On 3/27/12 11:17 PM, "Ray Bellis" <[email-masked]> wrote:

>IMHO the only element we could mandate is the one that includes the "key"
>on which the search was just performed.  That at least ensures that you
>know the response you get is based on the query you sent.  *Everything*
>else should be left to registry policy.

I appreciate the potential issue of having mandatory elements on the data
model for any type of registry (e.g., names or numbers) in the protocol
spec. On the other hand, I would think the data consumers would benefit of
having a data model (specified by the appropriate/relevant policy maker)
that clearly identifies which fields must be present and which are
optional for an specific registry (e.g., .com, ARIN, .cn).

How do we reconcile the two issues?

__

Francisco.

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 27 Mar 2012 14:28:53 -0700

Hi Ray,

The intent is to use the existing schemas as the starting point, not for the final product:

  It is based on the object schemas from the 
  Extension Provisioning Protocol (EPP), by
  Scott Hollenbeck.  It references and includes 
  the following EPP schemas:

The text might need to be revised to make it clearer, but we can't use the EPP schema directly because there is functionality that does not apply for a whois query, as well as functionality needed by a whois service that is not included in the EPP schemas.

Francisco

Francisco Obispo 
email: [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 22:08:20 +0000

On 27 Mar 2012, at 23:26, Francisco Arias wrote:

> spec.

Great :)

> On the other hand, I would think the data consumers would benefit of

Can you elaborate on that?

There's a world of difference between the complicated data models needed to register a resource and those used to display or gather information about resources.

If you want to register a resource, it matters if you miss out information that's required by the registry.

However I actually don't think there is a benefit to data consumers of having a defined policy for mandatory vs optional fields.  The data is either there, or it's not.  Their client will need to interoperate with other registries that'll have different policies, and it'll just have to cope.

For display applications, you just omit the blank fields.  If on the other hand you're collecting lots of responses into a database the only difference it makes is whether the local schema needs a "NOT NULL" qualifier for that field, and in any event that would only be needed for mandatory fields.

> How do we reconcile the two issues?

By all means ICANN could have a policy document (which could be an RFC) that specifies as a matter of _policy_ all of the fields that all ICANN accredited registries (and registrars, in the thin model) MUST output.

I don't think that document should be a work item of this group, though.

Ray

---

From: Francisco Arias <[email-masked]>
Date: Tue, 27 Mar 2012 15:25:07 -0700

On 3/28/12 12:08 AM, "Ray Bellis" <[email-masked]> wrote:

>There's a world of difference between the complicated data models needed
>to register a resource and those used to display or gather information
>about resources.
>
>If you want to register a resource, it matters if you miss out
>information that's required by the registry.
>
>However I actually don't think there is a benefit to data consumers of
>having a defined policy for mandatory vs optional fields.  The data is
>either there, or it's not.  Their client will need to interoperate with
>other registries that'll have different policies, and it'll just have to
>cope.
>
>For display applications, you just omit the blank fields.  If on the
>other hand you're collecting lots of responses into a database the only
>difference it makes is whether the local schema needs a "NOT NULL"
>qualifier for that field, and in any event that would only be needed for
>mandatory fields.

Right, perhaps I should have asked, is this something of interest for data
consumers?

>By all means ICANN could have a policy document (which could be an RFC)
>that specifies as a matter of _policy_ all of the fields that all ICANN
>accredited registries (and registrars, in the thin model) MUST output.
>

Of course not, I wasn't suggesting that. Actually, perhaps the contracts
would be the easiest vehicle for this.

What I was hoping to hear is what technical mechanisms could we use if we
wanted to do this. But I guess we first need to know if the idea is of
interest for data consumers.

__

Francisco.

---

From: Arturo Servin <[email-masked]>
Date: Wed, 28 Mar 2012 09:14:34 +0200

Why we first forget about XML vs JSON and instead of defining an XML schema we start by defining a data model? Then, we decide how to port it to any output format.

Regards,
.as

On 27 Mar 2012, at 23:28, Francisco Obispo wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]

---

From: Arturo Servin <[email-masked]>
Date: Wed, 28 Mar 2012 09:23:19 +0200

Agree with Ray.

	It is important to have a data model but all fields could be optional.

	It is up the RESTwhois operator to decide which objects of the data model it wants to support (perhaps by policy.)

	I am working in an API (but I am very slow in writing code) and I do not have a problem with optional objects (in fact, in draft-newton-et-al-weirds-rir-json-response-01 all of there are) but it is important to have a data model to know what to expect if it is there.

Regards,
.as

---

From: SM <[email-masked]>
Date: Wed, 28 Mar 2012 01:12:20 -0700

At 00:23 28-03-2012, Arturo Servin wrote:
>         It is up the RESTwhois operator to decide which objects of 
> the data model it wants to support (perhaps by policy.)

During the BoF yesterday, it was mentioned that the document which 
specifies the data (fields) provided could be published in a non-WG 
RFC.  The groups of data providers might be as follows:

   (a) number registries (doable through common policy)

   (b) ICANN affiliated name registries (ICANN might be able to address that)

   (c) non-affiliated name registries (some ccTLDs might be able to 
get together)

I assume that the users of the service do not care whether it is 
RESTful, JSON or XML.  They would like the get the data in a 
standardized format so that they can send DMCA letters, automate 
decisions against domains, IP address ranges, use information as 
input for "trust" decisions.

Would (a) to (c) be an unsolvable problem for stakeholders?

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Mar 2012 08:22:10 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, March 28, 2012 1:12 AM
> To: [email-masked]
> Subject: Re: [weirds] Mandatory vs. optional elements (was Re: New
> Version Notification for draft-kucherawy-weirds-requirements-03.txt)
> 
> RFC.  [...]

Hi SM,

I don't remember the "non-WG RFC" part.  Is there an advantage to doing it outside the WG?

-MSK

---

From: Francisco Arias <[email-masked]>
Date: Wed, 28 Mar 2012 01:35:52 -0700

On 3/28/12 9:14 AM, "Arturo Servin" <[email-masked]> wrote:

>
>	Why we first forget about XML vs JSON and instead of defining an XML
>schema we start by defining a data model? Then, we decide how to port it
>to any output format.

It seems a sensible suggestion to me.

__

Francisco.

---

From: SM <[email-masked]>
Date: Wed, 28 Mar 2012 01:37:56 -0700

Hi Murray,
>I don't remember the "non-WG RFC" part.  Is there an advantage to 

Pete (Applications Area Director) mentioned it as an option.  The 
advantage of not having them as deliverables is that the group does 
not have to discuss whether it should or should not be in the charter 
or gating on policy decisions.  That does not prevent the work from 
being discussed informally on the WG mailing list.

The option does not affect the conditions mentioned in the message 
about deployment commitments ( 
http://www.ietf.org/mail-archive/web/weirds/current/msg00854.html ).

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Mar 2012 08:45:35 +0000

> From: SM [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2012 1:38 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> advantage of not having them as deliverables is that the group does not
> have to discuss whether it should or should not be in the charter or
> gating on policy decisions.  That does not prevent the work from being
> discussed informally on the WG mailing list.

It seems from the discussion yesterday that people think the data elements are pretty key to the output of this working group, so I expect they should be on the milestones list.

It's certainly possible to do this outside the WG, but personally it would seem a strange approach to me given the need.

-MSK

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 28 Mar 2012 05:46:06 -0300

+1

---

From: Francisco Arias <[email-masked]>
Date: Wed, 28 Mar 2012 02:00:35 -0700

On 3/28/12 10:45 AM, "Murray S. Kucherawy" <[email-masked]> wrote:

>It seems from the discussion yesterday that people think the data
>elements are pretty key to the output of this working group, so I expect
>they should be on the milestones list.
>
>It's certainly possible to do this outside the WG, but personally it
>would seem a strange approach to me given the need.

That's why I was asking whether the data consumers think some sort of data
model is needed. But keep in mind that all the protocol can do is define a
standardized name and definition for a list of fields (perhaps the most
common fields). Which fields are served, it's a policy decision on each
registry (.br, LACNIC, .tel, etc.). The protocol cannot define which
fields are mandatory.

__

Francisco.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Mar 2012 09:01:57 +0000

> From: Francisco Arias [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2012 2:01 AM
> To: Murray S. Kucherawy; [email-masked]
> That's why I was asking whether the data consumers think some sort of
> data model is needed. But keep in mind that all the protocol can do is
> define a standardized name and definition for a list of fields (perhaps
> the most common fields). Which fields are served, it's a policy
> decision on each registry (.br, LACNIC, .tel, etc.). The protocol
> cannot define which fields are mandatory.

I'm fine with that compromise.

-MSK

---

From: SM <[email-masked]>
Date: Wed, 28 Mar 2012 02:20:39 -0700

Hi Francisco,
>registry (.br, LACNIC, .tel, etc.). The protocol cannot define which

My previous message on this thread was about which fields are served.

Regards,
-sm

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2012 07:00:58 -0300

On Wed, Mar 28, 2012 at 02:56:18AM +1100, James Mitchell wrote:
...
> don't think this group should gamble on 3.

Agree. It's definitely undesirable to see aberrations as rewrites of
information only for the purpose of obscuring mandatory fields on
mandated by policy protected information or unavailable data.

> James

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2012 07:20:37 -0300

Ray,

On Tue, Mar 27, 2012 at 07:31:43PM +0000, Ray Bellis wrote:
...
> This also needs to be supported by the data formats.  If using XML / XSD, _every_ element needs to be optional.  That may make it impossible to directly import EPP-based schemas, which often have m…

Just to be clear when I mentioned the EPP extensions LACNIC is using
for the purpose of provisioning ASs and Addresses Blocks among
RIR/NIR/ISPs this was to make the point that the numbers and names
registries do share social data objects and it's possible to provide
services for both registries using a single protocol. It was not my
intention to meant the use of their XML elements as an option for the
data format.

For the record these are the last documents describing these
extensions.

ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-asn-02.txt
ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-ipnetwork-02.txt

Fred

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 28 Mar 2012 12:20:55 +0200

> schema we start by defining a data model? Then, we decide how to port it

+1, traditional text templates would be great!

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2012 12:23:36 -0000

>registry (.br, LACNIC, .tel, etc.). The protocol cannot define which

It's fine if not all the fields are present or filled in, but I need
to know what the fields are and what they're supposed to contain.

The key for me is to be able to parse the responses automatically and
reliably.

R's,
John

---

From: James Mitchell <[email-masked]>
Date: Thu, 29 Mar 2012 01:39:24 +1100

Agree that a common data model should be defined for (EPP-based) name registries to avoid variation in core fields. I assume in this case the EPP RFCs plus published extensions would provide a good starting point. Note that I am using the term EPP as being the domain, host and contact object extensions defined in RFCs 5731-5733 and not the Extensible protocol :)

---

From: "John R. Levine" <[email-masked]>
Date: 28 Mar 2012 16:47:13 +0200

> Agree that a common data model should be defined for (EPP-based) name 
> registries to avoid variation in core fields.

This whole exercise is pointless without a data model that a client can 
use to parse the responses that it gets to its queries.  It's OK if
there is a small number of models, e.g., one for numbers and one for 
names, but it better not be one for each of the 900 registrars.

> I assume in this case the EPP RFCs plus published extensions would 
> provide a good starting point.

The ICANN registry agreements for thick registries specify what's supposed 
to be in WHOIS responses, and they're all pretty much the same.  I'd 
suggest starting with them, since that's data the gTLD and sTLD registries 
should already be able to provide.

>> The key for me is to be able to parse the responses automatically and

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: James Mitchell <[email-masked]>
Date: Thu, 29 Mar 2012 02:25:23 +1100

>names, but it better not be one for each of the 900 registrars.

Agree.

>should already be able to provide.

Fine with me.

---

From: Alan Maitland <[email-masked]>
Date: Wed, 28 Mar 2012 09:31:39 -0600

> 	Why we first forget about XML vs JSON and instead of defining an XML schema we start by defining a data model? Then, we decide how to port it to any output format.

Agree.  It might be useful to be able to request a given desired format 
as part of the protocol.  Perhaps initially implemented with some 
established protocols in place (e.g., XML, plain text, flavors of csv, 
etc) and the ability to request supported protocols, thus allowing 
future additions without breaking the current implementations.

As to data fields, perhaps a mechanism to list supported fields and 
basic information (e.g., numeric, text, size, etc) for a given 
implementation would be useful, along with a baseline set of data fields 
that all implementations would offer.

Arguably, there could be some authorization scheme to allow for levels 
of data access.  In other words, some data would be universal, while 
some other data may be accessible within and / or between the registries 
or other needs.

Alan M.

---

From: Andy Newton <[email-masked]>
Date: Wed, 28 Mar 2012 17:36:07 +0200

>> should already be able to provide.

I've heard that an ICANN committee is working on the fields ICANN wishes to see in this and they will be ready with their recommendations in the June timeframe. I can't imagine it will be much different than what can be found in the current agreements, so I think it would be sane to proceed with John's suggestion until then.

In the meantime, if there is an energetic individual wishing to make a name for themselves, said person could look at Nominet and DeNIC and some of the bigger ccTLDs and do a gap analysis to see what is still needed.

-andy

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 29 Mar 2012 06:53:59 -0300

On Wed, Mar 28, 2012 at 05:36:07PM +0200, Andy Newton wrote:
...
> 
> In the meantime, if there is an energetic individual wishing to make
> a name for themselves, said person could look at Nominet and DeNIC
> and some of the bigger ccTLDs and do a gap analysis to see what is
> still needed.

To kick start the process Ray Bellis and I worked for a while on this,
hopefully more will come.

http://goo.gl/uYTZw

Errors and misinterpretations are just mine :-)

Fred

---

From: Arturo Servin <[email-masked]>
Date: Thu, 29 Mar 2012 12:19:30 +0200

Fred, Ray

	I have the RIRs' tables comparing each data model if you wanted to make cross check.

	We used that table for the model in our draft.

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Thu, 29 Mar 2012 12:26:16 +0200

Well, I was thinking that you may not need it anyway. The output model is already in the draft.

	But if you want to take a look, just let me know.

Regards.
as

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 29 Mar 2012 09:52:19 -0400

On 3/28/12 10:47 AM, John R. Levine wrote:
> 
> This whole exercise is pointless without a data model that a client
> can use to parse the responses that it gets to its queries.

well, pointless to some data consumers, not necessarily to all data
producers. that i appreciate john's point may be more obvious in a
subsequent note.

>                                                         ... It's OK if

the risk of repeating the bazillions of registrars nonsense (over two
thirds are registrar operated shells and if the drop pool access rule
had allowed more threads/subnets at an equivalent price these might
never have existed as iana id'd "registrars" at all) is present here.

it is not likely that rsp backends are offering their tenent-clients
freedom to create unbounded implementation cost, marketing overhead,
and regulatory compliance risk.

so if we could focus on the independent providers, e.g., vgrs is
independent of afilias, etc., and not on their similar or identical
(now or conjectural) instances of branded registry services, our
number would be smaller, and correlate to actual variation.

>> I assume in this case the EPP RFCs plus published extensions would provide a good starting point.
> 
> The ICANN registry agreements for thick registries specify what's supposed to be in WHOIS responses, and they're all pretty much the same.  I'd suggest starting with them, since that's data the gTLD and sTLD registries should already be able to provide.

correct, for a general _class_ of registries, which may include some
"other contractual registries" which are in fact tenent-clients of
backend service providers which operate "icann contractual
registries". so this is a useful starting point.

-e