Subject: [weirds] Submission for BOF request [[email-masked]: BOF request IETF 82: WEIRDS]

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Oct 2011 12:40:35 -0400

Dear colleagues,

Today I submitted the attached as a request for a BOF.  I'm also
updating the BOF section of the IETF wiki.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

Subject: BOF request IETF 82: WEIRDS
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Cc: "Murray S. Kucherawy" <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 3 Oct 2011 12:18:14 -0400

Hello,

This is a request for a BOF session at IETF 82, for WEIRDS:
(WHOIS-based Extensible Internet Registration Data Service).  This is
a request for a BOF in the Applications Area.  The ADs for the area
are copied on this mail.

Murray S. Kucherawy <[email-masked]> has volunteered to co-chair
the BOF with me (Andrew Sullivan, <[email-masked]>).

We have a mailing list: <[email-masked]>

The purpose of the BOF is to determine whether there is a reason to
start a working group to undertake this work.  The work aims at a
replacement for WHOIS to be delivered as a RESTful service, with an
eye to avoiding a number of the issues that have prevented IRIS
deployment as a WHOIS replacement.  The impetus for this work is the
existence of three already-deployed experimental services along these
lines, and the burgeoning number of IDN TLDs in the domain name system
root zone.  A full proposed charter is attached to this message.

Here are the drafts we know about on the topic:

http://tools.ietf.org/id/draft-fiorelli-weirds-rws-00.txt
http://tools.ietf.org/id/draft-kucherawy-weirds-requirements-01.txt
http://tools.ietf.org/id/draft-newton-et-al-weirds-rir-query-00.txt
http://tools.ietf.org/id/draft-newton-weirds-arin-whoisrws-00.txt
http://tools.ietf.org/id/draft-sheng-weirds-icann-rws-dnrd-00.txt

Here is the proposed agenda for the BOF:

    0.  Agenda bashing.                                                         
                                                                                
    1.  A very quick review of the background.                                  
                                                                                
    2.  A pointer to the drafts about actual deployments, but not               
        discussion of these.                                                           
    3.  A very quick overview of the then-extant requirements draft.            
                                                                                
    4.  Questions for discussion (at least 30 mins):                            
        a.  Is this a problem to be solved?                                     
        b.  Is the problem statement in the proposed charter clear              
            enough?                                                                     c.  Do we think we can solve the problem?                               
        d.  Are there people willing to work on the problem? 

I will upload all these materials to the tools BOF wiki, also.

CONFLICTS

I'd like to avoid conflicting with the APPSAWG, DANE, DNSOP (and
DNSEXT, but we're not having a meeting), EAI, PRECIS, OPSAWG, and
V6OPS.  Secondarily, I'd like to avoid conflicts with GROW, URNBIS and
IRI.  There are other conflicts that would be bad, but all of those
groups I expect to have significant populations that overlap our
target population.  (Basically, the conflict list includes anyone who
uses WHOIS for anything, and anyone who might want to use WHOIS for
something if it were usable for that -- so the entire anti-abuse
community, for instance.  I know there are probably additional bad
conflicts, but I've tried to keep the list under control.)

POSSIBLE ATTENDANCE

We didn't have previous a previous meeting and therefore have no
previous attendance numbers.  We had a side meeting in Québec, and
counted about 40 people in the room.  There was also significant
interest in the topic when we had a few minutes for discussion in the
APPSAWG meeting, so this leads me to believe that a target of 60 or 75
people is not unreasonable (especially considering how BOFs lately
seem to be badly oversubscribed).  I cannot imagine attracting more
than 150 people, and think it would be a bad sign of tourism if we
did.

We have no special requests.  We would like one session.  Given our
agenda, I would prefer two hours, because I expect discussion to range
widely (this is based partly on the amount of discussion that happened
in the APPSAWG in Quebec, which surprised me).  I'm aware of the
difficulty of scheduling, however, and we can do it in one hour if
need be.  2.5 hours would be too much time.

Best regards, 

Andrew

-- 
Andrew Sullivan
[email-masked]

WHOIS-based Extensible Internet Registration Data Service (weirds)
------------------------------------------------------------------

DRAFT Charter v 2011-09-30a

Chairs:
    TBD

Internet Area Directors:
    Pete Resnick & Peter Saint-Andre

Description of Working Group:

    Internet registries for both numbers and names have historically
    maintained a lookup service to permit public access to some of the
    registry database.  Most registries offer the service via WHOIS
    (RFC 3912), with additional services being offered via world wide
    web pages, bulk downloads, and other services like RPSL (RFC
    2622).

    A conspicuous problem with WHOIS is that it has never been
    internationalized.  In the absence of formal specification, ad hoc
    solutions to signal internationalized registration data have been
    adopted and deployed. The current collection of WHOIS service
    specific signalling, widely varying response formats, and error
    reporting already inhibits automatic processing of WHOIS output.
    Providing a standards-base solution that scales well could
    minimize further proliferation of ad hoc solutions.

    WHOIS also has no data model at all: replies are basically just
    free-form text.  This means that processing of WHOIS output
    amounts to "screen-scraping", with specialized handlers for every
    service.  Finally, WHOIS does not offer any differential service;
    it cannot differentiate among clients and offer different
    information to different classes of user.

    Various attempts to solve limitations of WHOIS have met with mixed
    success.  The most recent of these was IRIS (RFC 3891).

    IRIS has not been a successful replacement for WHOIS.  The primary
    reasons for this appear to be the complexity of IRIS, the fact
    that it has its own control part, and that it requires
    implementers to understand the details of the transport it is
    using.

    In response to these facts, some registries have deployed
    experimental services that provide the registration information
    services traditionally offered via WHOIS, using a RESTful approach
    to data delivery over the web.  Three such efforts have been
    undertaken, and more may be anticipated in response to the
    increased deployment of IDNA.

    The Working Group shall undertake to document the existing
    efforts, to determine the general needs of such a service; and to
    standardize a single data framework, to be delivered via a RESTful
    data service using HTTP (optionally using TLS).  The overall
    effort will be broadly aligned with the Cross Registry Internet
    Service Protocol (CRISP) Requirements (RFC 3707), but with the
    explicit additional goal of producing a simple, easy-to-implement
    protocol that is to be deployed via REST.  In addition, the
    following three priorities take precedence over others:

    1.  Complete support for internationalization of queries and
    responses, including a standard representation for IDNs and
    non-ASCII text in queries and responses, and ways to indicate
    language or character set preferences for responses.  The Working
    Group will need to determine whether language or character set (or
    both) is an appropriate selector.

    2.  A rigorous machine-friendly data model that allows for the
    (current) developments of innovations in TLDs and in number
    registries.

    3.  Support for differential service levels, including bulk
    access, according to different classes of user.

    It is expected that more than one data profile will need to be
    developed to be used in different service environments
    (e.g. number registry versus name registry).  The base
    specification shall include an extension mechanism to permit
    future developments in the served registries.

    One possible outcome of the requirements development stage will be
    that the WG concludes that using one protocol for name and number
    registries is an error, in which case two different but probably
    basically similar protocols will be developed.

Milestones

    [TBD]   Drafts outlining existing deployments to IESG for
    publication as Informational RFCs.

    [TBD]   Draft WEIRDS requirements to IESG for publication as
    Informational RFC.

    [TBD]   Draft WEIRDS base specification to IESG for publication on
    the standards track.

    [TBD]   Draft WEIRDS object specifications to IESG for publication
    on the standards track.

---

From: Peter Koch <[email-masked]>
Date: Wed, 5 Oct 2011 08:15:41 +0200

>         d.  Are there people willing to work on the problem? 

there will hopefully be moe time than 30 minutes.

>     implementers to understand the details of the transport it is

I think this analysis needs more space on the prospective charter.
That is, I'm not convinced that the "complexity" of the protocol
is really the issue unless we're willing to cut down on the
requirements side.  Any flexible approach will ultimately have to
show some complexity to address and, where necessary, combine
solutions for the various requirements across the various constituency.
It may be that the transport or session layer approaches chosen by IRIS
were too ambitious or overtaken by events, but just because the
approach du jour is to substitute API design for protocol design
doesn't mean we'll see a betrter result in terms of deployment.

>     increased deployment of IDNA.

It is interesting to observe that most of the perceived complexity of the
protocol arises from ist use in the domain name business whereas the
demonstrated solution originate from within the RIR community mostly.

>     both) is an appropriate selector.

Whois is one of those protocols where protocol elements may be exposed to the
end user, therefore: when talking about "language" here, would that apply
to user friendly translated record or field names like "address" or what else?
Also, localization might be an important additional issue.

>     basically similar protocols will be developed.

I'd suggest that that decision be postponed until after the requirements
work, i.e., there might be only energy/consensus/support to proceed with
one of the two.

>     publication as Informational RFCs.

If these just document the current REST implementations in separate
documents, what's the purpose of making the drafts WG documents?

>     [TBD]   Draft WEIRDS base specification to IESG for publication on

I'd like to see the charter allow for changes to IRIS instead of only the
development of a new protocol (well, API for that matter).

-Peter

---

From: SM <[email-masked]>
Date: Wed, 05 Oct 2011 01:16:02 -0700

>doesn't mean we'll see a betrter result in terms of deployment.

Yes.  The current fad is the HTTP of Things.  One of the requirements 
discussed in another group was to design a protocol that could be 
implemented by "amateurs". :-)

>demonstrated solution originate from within the RIR community mostly.

And that can end up as an IRIS-bis.

>work, i.e., there might be only energy/consensus/support to proceed with

Agreed.

The previous requirements look good on paper.  I suggest looking into 
what solutions are out there and compare them with the previous requirements.

Regards,
-sm

---

From: Nikolay Shopik <[email-masked]>
Date: Wed, 05 Oct 2011 14:00:31 +0400

> And that can end up as an IRIS-bis.

I'm understood that correctly, that most work currently only apply to 
RIRs? And stuff for ccTLDs, will separately appear later under this WG?

---

From: SM <[email-masked]>
Date: Wed, 05 Oct 2011 03:37:18 -0700

Hi Nikolay,
At 03:00 05-10-2011, Nikolay Shopik wrote:
>I'm understood that correctly, that most work currently only apply 
>to RIRs? And stuff for ccTLDs, will separately appear later under this WG?

Wierds is not a working group.  The BoF which has been requested is 
an attempt to form a working group.

There have been some individual drafts that have been discussed on 
this mailing list.  That work is from individuals who work for RIRs 
or ICANN.  People from ccTLDs have not submitted any draft.

The proposed charter for a proposed working group covers both RIRs 
and ccTLDs.  If a design is picked once there is a working group, it 
would also be recommended for ccTLDs.  That does not mean that ccTLDs 
must follow that design.

If you have some interest in the work, it is up to you to read the 
proposed charter and see whether you agree about what work will be 
done and how it will be done.

Regards,
-sm

---

From: Dave Piscitello <[email-masked]>
Date: Wed, 5 Oct 2011 04:26:00 -0700

On Oct 5, 2011, at 2:15 AM, Peter Koch wrote:

> requirements side.  

I agree, but I don't think we need a detailed negative analysis of IRIS. Rather, I think that the explanation that Andy Newton has used on several occasions is extremely helpful. You can glean the reasons from our ;login article. Using a REST framework leverages existing client, server infrastructure, and (importantly) developer knowledge base much more so than IRIS. Business segments that claim to have very small revenue margins and contractual obligations to provide a non-revenue generating service may be just as reticent to implement something that is "entirely new" as they would something complex. We're trying to demonstrate that RESTful directory services are neither of these and thus, several benefits emerge from what is seemingly a modest investment: structured data, internationalization, security framework (even if this proves to be only confidentiality and server authentication, it costs little over current web-based Whois).

---

From: Avri Doria <[email-masked]>
Date: Wed, 5 Oct 2011 07:50:59 -0400

On 5 Oct 2011, at 04:16, SM wrote:

> 
> The previous requirements look good on paper.  I suggest looking into what solutions are out there and compare them with the previous requirements.

Wouldn't the point be to collect all of the requirements, including the ones that IRIS was based on, and then look toward solution, including perhaps IRIS-bis based on the collected and WG consensus view of the requirements?

BTW, I do not see that the draft charter as currently written necessary excludes IRIS, it just doesn't presuppose it.

avri

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Oct 2011 08:26:06 -0400

> BTW, I do not see that the draft charter as currently written necessary excludes IRIS, it just doesn't presuppose it.

What is the point of having IRIS-bis? To provide backwards compatibility with all the current IRIS deployments?

The only part of IRIS that has seen any real deployment is DCHK over UDP, adopted by two ccTLDs. And that is work I don't think we should attempt to replicate.

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Oct 2011 08:30:22 -0400

On Oct 5, 2011, at 4:16 AM, SM wrote:

> Yes.  The current fad is the HTTP of Things.  One of the requirements discussed in another group was to design a protocol that could be implemented by "amateurs". :-)

Had the security czars not blocked the other TCP ports at the corporate firewalls, we might live on a different Internet. :)

-andy

---

From: Avri Doria <[email-masked]>
Date: Wed, 5 Oct 2011 09:08:51 -0400

Hi Andy,

I just wasn't making any presupposition until we aggregated the requirements from all the relevant sources.  There are people that seem to think well of what IRIS does, and I guess some who actually use it.  So, to me, it made sense to include it among the things we looked at once we knew what the requirements were.  I was not suggesting that we make explicit mention of checking it, only that the charter as currently written did not seem to preclude looking at it as one among possibly several alternates.

avri

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Oct 2011 13:19:44 +0000

> I just wasn't making any presupposition until we aggregated the requirements from all the relevant sources.  There are people that seem to think well of what IRIS does, and I guess some who actuall…

Avri,

Understood. Sorry for the snark. I'll go properly caffeinate now to prevent further outbursts. :)

-andy

---

From: SM <[email-masked]>
Date: Wed, 05 Oct 2011 09:32:59 -0700

At 04:50 05-10-2011, Avri Doria wrote:
>Wouldn't the point be to collect all of the requirements, including 
>the ones that IRIS was based on, and then look toward solution, 
>including perhaps IRIS-bis based on the collected and WG consensus 
>view of the requirements?

The discussion up to now has been about a RESTful solution as that is 
the only alternative that has been submitted as drafts.  Some people 
who have been looking for a solution do not favor a particular 
alternative as their problem is data availability.  I don't think 
that collecting requirements will help in addressing such a problem.

At 05:30 05-10-2011, Andy Newton wrote:
>Had the security czars not blocked the other TCP ports at the 
>corporate firewalls, we might live on a different Internet. :)

See draft-tschofenig-post-standardization-00 :-)

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Oct 2011 12:59:22 -0400

> there will hopefully be moe time than 30 minutes.

I asked for a 2 hour slot, but we could be reduced to 1, in which case
we'd have to move very fast through all the background and so on
before getting to the open mic, in order to get a lot more than 30
mins.  
 
> is really the issue unless we're willing to cut down on the

That could be.  It is the reason people state most often, however, for
why IRIS didn't get rolled out.  Do you have text to suggest?

> demonstrated solution originate from within the RIR community mostly.

Right.  That's why I'm susceptible to the argument (I think John
Klensin made it in the APPSAWG) that part of the problem here is
trying to "replace WHOIS" where WHOIS is the lookup protocol used for
two completely different registry types.  Maybe that's the deep source
of the problem.

> Whois is one of those protocols where protocol elements may be
> exposed to the end user, therefore: when talking about "language"
> here, would that apply to user friendly translated record or field
> names like "address" or what else?  Also, localization might be an
> important additional issue.

Excellent point.  Text?

> work, i.e., there might be only energy/consensus/support to proceed with

Sure.

> documents, what's the purpose of making the drafts WG documents?

I guess we don't need to.  The review might be a good idea, however.

> development of a new protocol (well, API for that matter).

Why?  We have seen absolutely no interest expressed in futher IRIS
work, and if we have to have the fight about whether to start with
IRIS or build some sort of web service, I think we will expend all our
energy before we get to specifying interoperable things.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Mon, 10 Oct 2011 17:10:23 +0200

On Wed, Oct 05, 2011 at 04:26:00AM -0700, Dave Piscitello wrote:

> I agree, but I don't think we need a detailed negative analysis of IRIS.

agree, for given values of 'detailed'.

> Using a REST framework leverages existing client, server infrastructure,
> and (importantly) developer knowledge base much more so than IRIS.

I'm not defending IRIS in any way, just i fear were going to be caught in the
same trap as IRIS sooner or later.  And for the "developer knowledge base"
I am not sure where to find myself on the scale between laughter and mourning.

Also i am not opposed to REST in general, just i'm not subscribing to that
religion. In particular, it is in no way helping with the (lack of) a data
model, where IRIS or other efforts have set the grounds.  The RIPE database,
for example, has been working very well without REST over the last 20-ish
years - due to a sensible data model.

> it costs little over current web-based Whois). 

Web based whois (and the service, opposed to the protocol, is what this
is all about) is unlikely to disappear no matter what protocol or API
this group will come up with, if only for whatever access control
has to be implemented.   Who is the immediate target audience for
the specification/output this group is considering to deliver?

-Peter

---

From: Peter Koch <[email-masked]>
Date: Mon, 10 Oct 2011 17:55:20 +0200

> What is the point of having IRIS-bis? To provide backwards compatibility with all the current IRIS deployments?

in a way, yes. There are reasons for non-deployment and maybe
those should be addressed. If the group consensus is that IRIS' major
fault is the lack of port 80, then changing the 'transport' to REST
I'm sure will do the job (withthe data model still to be inherited
from IRIS, maybe).  If the counter incentives are on the economics
or political side then I'm afraid a renewed IETF effort is at the
risk of having similar success.

-Peter

---

From: David Conrad <[email-masked]>
Date: Mon, 10 Oct 2011 09:22:14 -0700

> risk of having similar success.

+<very large number>

While undoubtedly fun for some, I fear arguing about transport flavor of the day will leave us precisely the same place we've been with Whois++, RWhois, IRIS, and the myriad of different flavors of Whois (either port 43 or 80).

The problem in this space isn't REST vs IRIS vs DNS vs Whois vs. anything else.  It's the fact that there is and never has been an agreed upon "registration data" data model nor has there been the political will or economic incentive to compromise on (much less implement) a standardized "registration data" schema.

Once you have a consistent way of representing the data that people can agree upon, packaging it into packets or streams with different headers is a trivial detail.  Without that consistent data model and schema, you'll end up exactly where we are now, just with access provided to random blobs of possibly UTF-8 (or maybe NETASCII or maybe locally encoded) and at best arbitrarily tagged data via REST instead of a stream over port 43.

Regards,
-drc