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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Aug 2011 11:55:30 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 09, 2011 11:51 AM
To: Murray S. Kucherawy
Cc: Murray S. Kucherawy
Subject: New Version Notification for draft-kucherawy-weirds-requirements-01.txt

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

Filename:	 draft-kucherawy-weirds-requirements
Revision:	 01
Title:		 Requirements For Internet Registry Services
Creation date:	 2011-08-09
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
   This document enumerates a base set of requirements that should be
   included in any system that provides registration information for
   Internet entities, be they network assignments 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.

The IETF Secretariat

---

From: Peter Koch <[email-masked]>
Date: Sun, 14 Aug 2011 00:04:00 +0200

> Creation date:	 2011-08-09

i have reviewed this updated version with the discussion in mind.
The clarification in section 4.3 is a step forward, but still i think
these operational and policy requirements, while representing a real
constituency, need to be rephrased.

> 2.  Document Series

>    This memo represents the introduction to a series of others that
>    define the overall problem and some available solutions.  The series
>    is as follows:

>    1.  RFCxxxx: Requirements for Internet Registry Services (this memo)

>    2.  RFCxxxx+1: The ICANN Internet Registry Service API

>    3.  RFCxxxx+2: The RIPE Internet Registry Service API

>    4.  RFCxxxx+3: The ARIN Internet Registry Service API

>    5.  RFCxxxx+4: RESTful WHOIS

>    The intent is to publish one of the API specifications as a standards
>    track document, and the remainder (including this memo) as
>    informational documents.

Not sure the collection of API descriptions is sufficient to meet
requirements either as layed out in this current version or any
subsequent result of a potential working group, mostly because they
appear kind of ready already.
However, the headlines (related to the other drafts circulated before
the bar bof meeting) implicitly state one requirement: if REST is the
religion du jour, that's something to state.

> 3.2.  Incorporated Requirements

>    Many of the requirements distilled from the input provided by various
>    communities in [CRISP] will apply to this effort as well.  It is
>    certainly the case that the research presented there should be
>    considered prerequisite reading for this new work.

As discussed in Quebec, we'd probably need to have a walk-through of all
the requirements and explicitly accept, modify and not the least abandon
those listed in RFC 3707.

> 4.1.  Clients

>    The client-side requirements are as follows:

>    1.  To support internationalized values, a client SHOULD be able to
>        handle replies that contain data that are not exclusively 7-bit
>        clean.

Agree. But it might be better to make this a requirement of the overall
protocol rather than one side of the interaction, i.e., "the protocol
MUST support i18n", or something along the lines of RFC 3707's section 3.2.9.

>    2.  A client SHOULD support caching of replies.  It MAY apply its own
>        default and MAY use a time-to-live provided as part of the reply.

Same here. If the client is expected to cache, the protocol MUST or SHOULD
provide methods of cache-control.

> 4.2.  Servers

>    The server-side requirements are as follows:

>    1.  A server MUST be able to return internationalized data.

see above.

>    3.  A server SHOULD be able to provide class-of-service facilities
>        for different types of users.  At least the following cases need
>        to be considered:

>        anonymous:  Users with no prior arrangement for access to the
>           data; typically all available data will be provided in
>           response to a query, but the query rate may be severely
>           limited.  No authentication is typically required.

>        security:  Users that have an interest in a specific subset of a
>           registration's data for the purpose of analysis and
>           correlation while evaluating the trustworthiness of the
>           source.  Examples include email client evaluation, email
>           content evaluation, web site security, etc.  The subset will
>           typically include creation/registration dates, assigned
>           nameserver names and IP addresses, registrar ID and registrant
>           ID.  Users in this class would be required to authenticate in
>           some way, but such clients would not typically be subjected to
>           rate limiting given the prior arrangement.

>        law enforcement:  Users with a bona fide interest in as much
>           registration data, including change history, as is available.
>           Typically, queries would be rare but have extremely high
>           priority.  These clients would definitely require
>           authentication and probably also require encryption.

This would mean the protocol has to support client authentication, integrity
and transport confidentiality and in the end also data origin authentication.
The protocol should support combinations thereof, but i'd rather not
encode different classes of access a priori.

>    6.  A server MUST provide a minimum set of data about a given query.
>        It is expected that this minimum set will be different for a
>        network allocation registry than a domain name registry, however
>        the following MUST be provided:

>        *  The creation date of the record

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

>        *  For domain name registration records, the identifier of the
>           registrar that created the record

>        *  For domain name registration records, the identifier of the
>           registrant that created the record

>        *  For network registration records, the size of the assigned
>           subnet in terms of a number of bits

The way it is written makes it an operational or policy requirement
that the IETF will have a hard time getting a say in.  RFC 3707 chose
a different approach that would require protocol features rather than
service models.  This is a crucial issue.  I understand where you're
coming from but the IETF is the wrong body (not implying a single such
body exists) to mandate certain fields in a whois or "registration
information service" output.

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 14 Aug 2011 20:21:33 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Koch
> Sent: Saturday, August 13, 2011 3:04 PM
> To: [email-masked]
> Subject: Re: [weirds] FW: New Version Notification for draft-kucherawy-
> weirds-requirements-01.txt
> 

That certainly is the case, but that seemed to me to be inappropriate to say in a requirements document.

> those listed in RFC 3707.

Fair enough.  Who among us is sufficiently familiar with the output of CRISP to lead that effort?

> MUST support i18n", or something along the lines of RFC 3707's section

Makes sense to me.  (Same for your other "see above"s.)

> encode different classes of access a priori.

Also fair enough, though I think it might be beneficial to include these as use cases rather than specific class-of-service requirements.

> information service" output.

I'm frankly a little worried that if the RFCs don't say something like this, we can just say "Hi, WHOIS is now HTTP and XML," and we're finished.  I suppose it's the "If it's not said here, where will it be said?" concern, since I haven't heard for sure that ICANN plans to insist on a minimum field set for specific classes of service from registrars or anything like that.

It seems to me we're defining a service here, and defining some minima for compliance isn't outside of the IETF's realm.  But I'd be happy to hear of a better solution that ensures this gets covered somewhere if not here.

---

From: SM <[email-masked]>
Date: Mon, 15 Aug 2011 00:06:06 -0700

Hi Murray,
At 20:21 14-08-2011, Murray S. Kucherawy wrote:
>I'm frankly a little worried that if the RFCs don't say something 
>like this, we can just say "Hi, WHOIS is now HTTP and XML," and 
>we're finished.  I suppose it's the "If it's not said here, where 
>will it be said?" concern, since I haven't heard for sure that ICANN 
>plans to insist on a minimum field set for specific classes of 
>service from registrars or anything like that.

If the RFC includes operational requirements, it is "telling" 
operators what to do or it may be interpreted like that by some 
people.  Determining the policy for domains is not an IETF decision.

I suggest asking the policy makers about whether there are policies 
covering the data being provided through Whois.  If that question 
cannot be resolved, you might as well settle for HTTP and XML.

Regards,
-sm

---

From: Peter Koch <[email-masked]>
Date: Mon, 15 Aug 2011 12:15:30 +0200

> That certainly is the case, but that seemed to me to be inappropriate to say in a requirements document.

well, it should be possible to find some wording that doesn't predetermine
the solution more than acceptable - maybe by listing difficulties that
people experienced with (or didn't even bother to experience because they shied away
from) IRIS.

> Also fair enough, though I think it might be beneficial to include these as use cases rather than specific class-of-service requirements.

That would mean giving a rationale for the list of requirements? Sounds
reasonable to me.

> I'm frankly a little worried that if the RFCs don't say something like this, we can just say "Hi, WHOIS is now HTTP and XML," and we're finished.

Besides the "transport" and the representation paradigm, the data model
is very important as are the security properties of the protocol, both for
transport and the objects.  So, it's a bit more than http+xml, but i'd not
expect the content of the data objects to be subject to mandatory protocol
requirements.

>  I suppose it's the "If it's not said here, where will it be said?" concern, since I haven't heard for sure that ICANN plans to insist on a minimum field set for specific classes of service from registrars or anything like that.

ICANN, for one, will have to do its policy work no matter what.  The topic of
whois has been on ICANN's agenda since its inception and it won't be solved
by throwing it over the fence into the IETF's garden and then re-importing
policy declared as technical requirements.  Also, ICANN is only responsible
for part of the spectrum, still bound by different legislations.  The RIRs and
ccTLDs and potentially a fair number of "new" TLDs will have to adhere to their
own policy development processes and local legislation.

And here we are back to square one: did IRIS really "fail" and why?

-Peter

---

From: Steve Sheng <[email-masked]>
Date: Mon, 15 Aug 2011 13:27:55 -0700

On 8/15/11 3:15 AM, "Peter Koch" <[email-masked]> wrote:

>> I'm frankly a little worried that if the RFCs don't say something like this,
>> we can just say "Hi, WHOIS is now HTTP and XML," and we're finished.
> 

I agree with Peter that content of the data is an ICANN issue not an IETF
issue. There are a lot of issues with WHOIS, but it is important to separate
the policy issues / protocol issues.

In WHOIS, there are three elements: registration data, protocol and
services. 

Regarding the registration data. Today, there is no overarching policy on
what they include / their purposes are. Currently the RAA (registrar
Accreditation agreement between ICANN and registrars identify what they are)
and ccTLD operators define their own policies. Whether to require a minimum
set is a very good question, however it is a policy question, and I consider
it out of scope here.

What is perhaps within the scope is to make sure that the schema / data
model is structured and extensible.

Regarding the policies that operators set for the WHOIS service (rate limit,
availability), I sense the frustration is that there is much variability in
terms of the service offered. However, these are again primarily policy
questions, not technical ones.

>From a protocol perspective, instead of dictating policy, perhaps we should
think about enabling policy. For example the rate limit debate highlights
that there are different classes of users that have different query needs,
perhaps it is useful to have features in the protocol to distinguish them
and allow operators to apply different limits to different types of users
and (could even charge some of them, here again a policy and market
question). 

Thoughts? 

Steve

>>  I suppose it's the "If it's not said here, where will it be said?" concern,
>> since I haven't heard for sure that ICANN plans to insist on a minimum field
>> set for specific classes of service from registrars or anything like that.
>

---

From: Peter Koch <[email-masked]>
Date: Tue, 16 Aug 2011 06:49:52 +0200

> I agree with Peter that content of the data is an ICANN issue not an IETF

small clarification: the emphasis is on "not IETF"; whether or not it's
ICANN's game depends on a number of factors. The fact of the matter ist
there is not a single body "to rule them all".

> model is structured and extensible.

Absolutely. Attributes/fields or objcts need to be recognized as optional.
Otherwise people might follow the syntax but will have to provide N/A or
something similar.

> and (could even charge some of them, here again a policy and market

Sure, that would be covered by Murray's use cases.  Again, IRIS had provisions
in that direction and the reason it was not (or not widely?) implemented
is not obviously technical.

-Peter

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 16 Aug 2011 14:14:30 -0700

> the policy issues / protocol issues.

Actually, isn't the content a matter that is administrative domain specific? In the case of domain name registries, the ICANN community makes policy regarding domain registration data. In the case of Internet addressing registries, the ASO/RIRs do. But while these are the most popularly known WHOIS deployments, neither the framework nor the protocol ought to impose restrictions on the data elements that comprise a given instance of "directory service data".

(So IMO it would be perfectly appropriate to have several data models/definitions).

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 16 Aug 2011 14:17:44 -0700

On Aug 13, 2011, at 6:04 PM, Peter Koch wrote:

.  A server SHOULD be able to provide class-of-service facilities
      for different types of users.  At least the following cases need
      to be considered:

A question here. Is it the protocol or the framework that has to support these facilities/services? For example, I could envision "XML over HTTPS" could satisfy encryption and server authentication, and where different service providers could employ  subauthentication methods common to SSL as they choose (much as people use SSL today to support "extranets" and "intranets"). Am I thinking outside the parameters here?

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 16 Aug 2011 15:43:11 -0600

> A question here. Is it the protocol or the framework that has to support these facilities/services? For example, I could envision "XML over HTTPS" could satisfy encryption and server authentication…

I think you're well within the parameters of a reasonable discussion on the future of WHOIS.

IMO, what will be important is picking/establishing a data model, either extensible or a set of models for the "common" uses. From a user's perspective, it would be nice if there was significant overlap in these models. It'd be equally useful to have the presentation be as similar as possible, again from the perspective of the user. I'm not suggesting a *requirement* that all presentations be identical, but rather suggesting that we consider the uninformed user of WHOIS as we move forward and recognize that what me obvious to the well-informed, is positively opaque to others.

(User experience is too often overlooked

(rough) Uniformity in the model and presentation of WHOIS data would be a refreshing change from a number of perspectives.

As for transport, I'd suggest that any forward-looking "protocol" be transport independent. HTTPS is a fin protocol. So is SMTP.

When it comes to authentication, I'm less sanguine about our ability to come up with a mechanism that will prove operationally feasible at Internet scale. (So it's probably best to leave that to someone else.)

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 16 Aug 2011 15:10:38 -0700

> I think you're well within the parameters of a reasonable discussion on the future of WHOIS.

Thanks for this.

> (rough) Uniformity in the model and presentation of WHOIS data would be a refreshing change from a number of perspectives.

Share the user perspective frequently:-)

>From your comment I am speculating that a common set of data elements for "contact data" used uniformly across registries might be desirable. Sub-elements of these data might, for example, follow conventions prescribed by postal, telephony, and internet protocol (e.g., email) standards. Similarly, conventions for internationalized domain names (A-label and U-label) would also be desirable.

> As for transport, I'd suggest that any forward-looking "protocol" be transport independent. HTTPS is a fin protocol. So is SMTP.

Here, I think you mean that the framework should separate data from transport, and that the framework should accommodate any protocol that satisfies the transport service requirements (Sorry to sound so "OSI" about this).

> When it comes to authentication, I'm less sanguine about our ability to come up with a mechanism that will prove operationally feasible at Internet scale. (So it's probably best to leave that to so…

Defining authentication methods that prove operationally feasible at Internet scale represents one end of the design spectrum and yes, we don't know how to do that today. Defining a framework that accommodates the selected use of authentication, even if it is for specific access controlled circumstances of a much smaller scale, seems to be useful (and not merely an exercise).

---

From: Peter Koch <[email-masked]>
Date: Wed, 17 Aug 2011 10:31:44 +0200

{hand edited the slightly broken quotation levels}

> A question here. Is it the protocol or the framework that has to support these facilities/services? For example, I could envision "XML over HTTPS" could satisfy encryption and server authentication…

you may just have read "protocol" more strict than i had intended.  I hadn't implied that
that happen at the transport level, but no matter where, the WHOISng (if any) would have
to define the bindings and semantics.  This is probably already to far in the detail for
the first round of requirements.

-Peter

---

From: Arturo Servin <[email-masked]>
Date: Wed, 17 Aug 2011 10:25:52 -0300

On 16 Aug 2011, at 18:43, Smith, Bill wrote:

> IMO, what will be important is picking/establishing a data model, either extensible or a set of models for the "common" uses.

	Or both.

	I was thinking in:

	a set of common and extensible objects
	
	extensible objects to accomodate any data that don't fit in the defined common (and extensible) objects.

	May be I am naive, but as user (not data producer) is what I would like to have. 

> From a user's perspective, it would be nice if there was significant overlap in these models. It'd be equally useful to have the presentation be as similar as possible, again from the perspective of the user. I'm not suggesting a *requirement* that all presentations be identical, but rather suggesting that we consider the uninformed user of WHOIS as we move forward and recognize that what me obvious to the well-informed, is positively opaque to others.
> 

Regards,
.as

---

From: Andy Newton <[email-masked]>
Date: Wed, 17 Aug 2011 19:55:09 +0000

> is not obviously technical.

We could probably short circuit the need to make these types of requirements by stating that this will be a REST system using HTTP, and the base of such features are already found in HTTP. In my experience with ARIN's Whois-RWS, there is only one such feature not present in HTTP that needed to be placed at another layer, which was specifying that a result set had been limited in size. If you look at the IRIS stack, you'll find that many of the features in the "IRIS" layer already exist in HTTP. This is one of the reasons why re-use of HTTP is so compelling and implementing IRIS is a bit more of a hill to climb.

-andy