Subject: [Ietf-not43] DRAFT minutes

From: [email-masked] (Ted Hardie)
Date: Wed, 3 Apr 2002 17:14:45 -0800

Below are the draft minutes for the BoF session in
Minneapolis.  My thanks to Lisa for her help and skills;
any errors were, no doubt, introduced by my own poor
editing.  Comments to me or the list as soon as possible,
as the final minutes are due fairly soon.
			thanks,			
				Ted Hardie

CRISP BOF
Ted Hardie, Chair
53rd IETF, March 18,  2002
Minutes taken by Lisa Dusseault ([email-masked])
Edited by Ted Hardie ([email-masked])

Summary: The BoF session discussed the audience and requirements for a
cross-registry information service protocol.  The consensus of the
room was that the overlap in requirements among the identified
audiences was not clear enough to warrant the scope proposed by the
BoF organizers.  As a first step towards clarifying the requirements,
it was agreed that a set of use cases would be supplied to the mailing
list; a requirements list or document prepared from the use cases
would then be the basis for further discussion.

Details of BoF presentations and discussion:

Why registries need a new solution
Presentation by Stig Venaas of Uninett

Why are Norwegian registries interested in alternatives to WHOIS?

* The main problem is no authentication.  The registry should be able
to provide almost no information to anonymous users, and by contrast
provide full information to registrars.

* Another problem is the need to limit query responses according to
the IP address requesting, or even better, by authenticated ID.

* Need a standardized query language to allow the same tools to query
multiple registries

* Need a standardized structured output to allow the same tools to
parse responses from multiple registries

Storage of registry information is in a SQL database, but LDAP access
to that database would involve slow responses because of the different
structures required.  Currently the Norwegian registries are using
LDAP, but that involves replicating data from the SQL server to LDAP
in order to get fast queries.  EU Privacy rules

Issue about European protection and privacy issues and how they
related to this.

Answer: registries have to use different rules, depending on whether
the records are describing individuals or organizations.  The rules in
Sweden, according to Patrick F, is that the registry may not publish
information about private persons (name, telephone number, postal
address).  This is interesting information, in so far as it produces
requirements for the system.  The requirement for the system is that
the registry records must be taggable with policy such as this.
Decisions may be related to the entry type.  Performance of LDAP
compared to WHOIS Using an oracle database and constrained query sets,
Network Solutions tests have shown that LDAP can sustain the same
query rates as WHOIS.  Whois-like information is getting more and more
fragmented.  This is another opportunity to try and fix it.

Unified Front-end problems

Demonstration of Geektools retrieval of whois information by Ted.  A
unified front end has been built but it is difficult to do anything
useful with the unstructured data from various back-ends.  The kind of
tagging on the data from the Australian registry is much more
extensive than that available from the American registry.  Processing
is difficult.  Anything that would be logical to prevent data mining
by spammers also prevents legitimate use.  Servers should be able to
reference each other, perhaps in chains, so that front ends don't have
to do so much work

RIR Input Regarding WHOIS deficiencies

Presentation by Cathy Murphy, on behalf of ARIN (not the RIRs)

* Need a one-stop lookup service This would only be needed to handle
IP address space and AS (Aut-num) queries.  Data mirroring is a
possibility.  Perhaps a set of limited- function servers could know
what RIR to query?  Then the appropriate RIR could actually respond to
the query.  ARIN membership specifically requested the RWhois model.

*	Data accuracy concerns

* Misuse of contact information: Currently all information is public,
and sources of that information must know that.  We're thinking of
doing a private service in the future.  Currently ARIN does make data
available in bulk, subject to an acceptable use policy.

* Increased server load: Better software and hardware and
architectures are needed to handle 2-6 x load increases in past year.

What are we not doing: Ted Hardie

Note that the word WHOIS is not in the name of the BOF.  It is
specifically not supposed to be backward compatible with WHOIS.

Requirements Draft

Requirements have already been discussed at several venues so could be
pretty mature.

Users and Scope

Some different communities of users have been identified, but the
scope of the problem has been narrowed to those that administer the
Internet:

*	Address registry operators: RIR, NIR, LIR.
*	Domain registry operators
*	Law enforcement and intellectual property enforcers

This is about accessing data, not provisioning.
The focus is on interaction between registry and end-user.

Requirements

Standard requirements apply: standard, extensible, decentralized, use
existing solutions.

More particular requirements:

* Access control: level of access, techniques to prevent anonymous
 data miners

* DNS referencing: use DNS to locate appropriate servers.  E.g. using
 SRV records.
*	Must be able to lookup specific information given a key.
*	Must be able to search 
*	Standard formats must be produced.

Address, domain and routing registries share most of these
requirements.  In addition, routing registries require mirroring.  In
addition, domain registries need escrow support.

Discussion on identification of users:

Are these the right users to select?  Do they really share the same
needs?  In some address applications, multiple registries might be
involved in producing a single answer.  That creates some
difficulties.

Cathy noted that any distributed system has that.  In RWhois, referral
provides the way to get additional information.

Rick pointed out that this same discussion has happened before in the
IETF.  Are the users really ready for it, this time?  Will they stand
up and help work with us to do this?

We can write this stuff and agree to it within the IETF.  Let's hear
that Verisign wants this.  They're not here?  That's a problem.

Ted notes that it's not just the United States registries that are
concerned.  We have here a broad population of people who are somewhat
content to keep doing the same thing they're doing.  To attract those
people, we need to have a concrete proposal, with a concrete set of
advantages, to present to them.  We don't have that yet.  But does it
mean we give up now?

Should we eliminate some of the user communities we've already
identified?  E.g. forget about the routing registries for now, and
perhaps expand later?

Crocker suggested we need several concrete usage scenarios to drive design.

Questioning the Need

Is there a really serious user requirement that isn't being satisfied?

Well, the registrars have a real need for a standard representation
because of how transfers occur.  Now they do compete against each
other, and it's difficult at times to get to provide resources.
There are certain user communities that need certain parts of what's
currently provided by WHOIS.  What they do does not work very well.
For example, the incident report CERT equivalent folks.  They need to
track down in near real-time, who claims responsibility for a net
block or domain.  Right now, its very difficult or time-consuming for
them to track this information through the layers where it is now: NIR
to RIR to LIR.  

Alexander French, speaking as an operator, says yes we
want solutions to the requirements outlined. However, we're not the
ones who need to implement solutions.  

Goals: Is this meant to supplement WHOIS, replace WHOIS, or be
redundant with WHOIS?  IF the aim is to replace, then uptake will be
slow.

CRISP is not to change the interior workings of registries business,
nor how they store their information.  Without changing either of
these, it should be possible to provide query capability and structure
for responses.

Scope and Complexity 

Is this too much work to try to solve?  Crocker seemed to think so.
Jaap repeated that specificity and narrow scope is good, that there
are even other kinds of registries, not covered here.  Response was
general agreement that of course we're not considering user groups not
considered here.

Rick suggested that when a service has been abused, and you're trying
to find all the entities that must be contacted about that abuse, this
work would really make that task easier.  Specifically on Routing
registries If RPSL solves this problem, we should use it.  One of the
problems we see today is that data is separated, and you can't get
good authentication unless you combine the data in the same store.
Since the routing registration data necessary falls out of the address
data, it's not as crazy as it sounds.

Proposal Overview
Leslie Daigle

Two proposals have been put forward: ldap-whois and iris.  Neither of
these was written by Leslie, but this is just intended to be an
overview.  Both proposals stay focused on the intended audience (IRRs,
RIRs, domain registries, network operators).  Clients can be written
to any server software; the bigger issue is the care and feeding of
servers.

LDAP-WHOIS

This proposal leverages LDAP for the query response model, and has a
data model that spans all the applications identified in the
requirements.  See the draft for details.

Performance of LDAP in this space?

Issues about whether LDAP is capable of scaling to the size of data
and number of queries required?  Reassurances from some people who
have actually tried, that it does.  

IRIS 

This proposal uses XML schema based query and responses.  The data
model is inferred.  HTTP has been proposed for a transport.  Currently
IRIS is for individual servers.  No way to get references to other
authorities.  See the draft for details.

IRIS vs. LDAP 

Global Service Either IRIS or LDAP-WHOIS could be a front-end to
existing registry databases, instead of completely replacing them.
Missing pieces Neither proposal addresses cross-registry searches.

Cannot aggregate If you are thinking of a service that will take
others' whois information and store it in a 3rd party location, that
is doomed to fail for numerous reasons.  Some entities are prevented
from allowing their information to be aggregated in this manner.

Problems solved by FreeBSD client To a certain extent, the FreeBSD
project has solved a lot of these problems with a smart WHOIS client.
It parses the user's request and attempts to look up, through a DNS
query with the TLD, who is the appropriate WHOIS server to ask.  It's
not perfect, and later versions are better than earlier versions.
Some of the work that you're suggesting has therefore already been
done.  However, no work has been done to parse the response or do
anything with it.  Note that the output they get is limited.  You're
left with a situation where a human can parse the information that is
returned and do something with it.  Also note that the client
implementation community is always chasing an increasing number of
servers with different formats etc.  This is at least a point to start from.

Privacy again Opposition to queries that go to all the registries that
are out there, collating information about an individual.  It may be
inevitable but must be opposed.  However, are there some kinds of
things we should be able to search across all registries?
E.g. the existence of a particular domain name across all TLDs?  So
what is the requirement for a protocol?  Is there a new technical
requirement in addition to the requirements we've already presented
for authentication and policy?  Apparently not.

Data accuracy George suggested that data accuracy must be out of
scope.  Of course data must be as accurate as possible, but that's a
matter of human process, not something that can be standardized.  Of
course we can't guarantee quality of data.  However, we can Different
schemas There are commonalities among the information presented, but
they are not the same.  Different people present different
information.  If we chose RPSL as a schema language, or some other,
and the schema elements for an RIR are different from those for a
different registry, but they use the same protocol, is that a problem?
There may also be a common way to do referrals

Some records will always be so advanced that they are unparsable.
User groups are or are not interested in standardization Somebody
stated that many of the supposed end users of this solution don't want
a standard solution.  RIPE NCC doesn't want this. We are convinced we
have a system that works.  It took a while to develop and make work.
It has been extensively tuned.  You mentioned incident response teams?
We rolled out a system to support European incident response teams.
If you are going to throw out everything we have for a utopic system
that is going to cause more trouble than it is going to remove

Another (12) RIPE NCC member(s) said that they would love to see this.
There's been a big effort to remove DNS information from the RIPE
database, and that's a fine thing.  However it doesn't mean that we
can't access that information with the same mechanisms.  A draft that
we could hit people with and ask them to implement it now, please.
You would then see registries, registrars and RIRs coming around.

Existing solutions

RIPE 81 is an existing solution. When we did RPSL we looked around to
see what was out there. We started from something without that.  If we
are going to change that standard, let's do it for a good reason, not
just XML.  The requirements that I'm hearing have more to do with
domain registries. Is there a requirement that the two registries have
to be the same?  What ties domain name registries with routing
registries?

Answers: Perhaps it's that they share the same end users, that the
same customers go to each of these registries looking for information.
There was some discussion about specific scenarios where the end user
would actually want to pull information from various different
registries and collate it.

Work Plan

Ted Hardie [NOTE: See charter for specific work plan proposal] RIPE
will not have an implementation of the proposal by Feb 2003 (the
suggested Proposed Standard date)

Rick noted that the iris draft looks easily as complex as implementing
a LDAP server.  A requirements document can either be agreed upon
quickly, or never.  The difference between the two is whether you can
get agreement on what it is you're intending to do.

The presentation earlier is helpful in that regard though still
hand-waving.  Resources are there for writing the necessary documents
as evidenced by the two proposals and requirements draft are already
written.  The question is rather whether there is agreement what this
is about.

Statement: Usage scenarios will be written, that will feed into the
requirements document.  Agreement that this is useful? Significant hum
for yes, none for no.

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 03 Apr 2002 21:41:23 -0600

Thanks Ted, sounds like a useful discussion. Comments and questions:

> requirements for the system.

My take would be that this produces requirements for the provider rather
than the system, although the provider requirement may introduce system
requirements. Can this be one of the usage scenarios so that this is more
better explored?

> The focus is on interaction between registry and end-user.

Personally 100% agree. My interest in this project results from an
inability to locate and reach operators of public resources, primarily.

> identified?  E.g. forget about the routing registries for now, and

This is certainly something to consider. The use of player-specific schema
makes extensibility an option. However, some core schema cannot be easily
modified after-the-fact so the more positive involvement there is up-front
will provably result in a better, more-stable design. My personal opinion
is that asking for their involvement is free, while not asking has known
hidden costs. We should at least make sure that the core schema are
sufficient for secondary audiences to build layered services onto.

> redundant with WHOIS?  IF the aim is to replace, then uptake will be

This is a distributed query service, which is something different than the
legacy WHOIS service. If somebody wants to put a perl front-end for this
service on their local tcp/43, that should work fine, but that's not the
goal, nor is it an objective.

> are out there, collating information about an individual.

> However, are there some kinds of things we should be able to search
> across all registries?

Three options that I can see here. First is to build a back-end query
mechanism into the distributed servers. That really loads up the server
requirements. Nor is in spirit with the traditional Internet model of
having clients do their own work. It is possible however. One other
potential concern is that this may make reusing existing technologies
somewhat difficult, or that it will require back-end locator technologies
that can't use the same public locator services as the clients, nevermind
the additional authentication and authorization requirements.

Another option here is to let the clients do their own work, and use
referrals for redirection and SeeAlso data. Personally, I tried to include
attributes that would let people tell you this stuff if they wanted you to
know it. Since the ACLs are per-jurisdiction anyway, this seems like the
only thing that will work in the end.

One more option is a catalog service. The Internet community could go out
and build their own catalog service to do this "right" but I don't think
anybody really wants another branch of Internet governance, which would
pretty much be required to manage this stuff. Alternatively, encourage the
Googles of the world to setup their own catalog servers, just as they did
with other services. This seems somewhat inevitable to me anyway.

In the end, the lawyer-actors would probably prefer a catalog service with
global access. However, they get paid by the hour, so I don't feel bad
about making them work for a living.

> requirements document.  Agreement that this is useful? Significant hum

Is this somebody's action item?

Thanks for the great notes

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Andrew Newton)
Date: 04 Apr 2002 09:21:30 -0500

> requirements. Can this be one of the usage scenarios so that this is more

I have the same reaction.  This appears to be an implementation issue
and not necessarily a protocol issue.  However, if it gets twisted just
a bit further into something where the contact info for individuals must
be kept private except to the owner of the data, then we get into a
protocol issue.

A use-case on this might flesh it out further.  Good point.

> only thing that will work in the end.

I agree.

> Is this somebody's action item?

Yes.  However, it doesn't stop others from contributing or presenting
their own.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 04 Apr 2002 10:06:39 -0600

Andrew Newton wrote:
> > My take would be that this produces requirements for the provider
> > rather than the system, although the provider requirement may
> > introduce system requirements. Can this be one of the usage scenarios
> > so that this is more better explored?
> 

Is paf on this list?

The case that would probably be most-illustrative of this issue would be a
Swedish user registering a domain in the com gTLD. Would the law require
that the com operator restrict the information in that case?

Another variation on this would be that a Swedish registrar sells domains
from the com registry. Would the Swedish registrar have to restrict
information about the American user (and all other users) or would they
only restrict information about Swedes?

Some of those issues may result in bleed-overs.

---

From: [email-masked] (Eva Stengard)
Date: Fri, 5 Apr 2002 12:27:17 +0200 (MEST)

Hi,
don't know about paf but we are more Swedes on this list...

The Swedish implementation of the European Data Protection Act is said to
be the most rigourous. I cannot tell as I haven't compared it with other
implementations. However, I'm uncertain to what extent what I'm saying
below regarding the Swedish case also is valid in a more European
context. That will take a lawyer majoring in European law to answer.

> that the com operator restrict the information in that case?

Assuming that all information is gathered and kept by a non-Swedish entity
outside of Sweden the law is not applicable. 

> only restrict information about Swedes?

The law does not make any distinction between the nationality of those
from whom the information originates. Therefore, in this case, the law
will apply.

For those of you interested I've tried to make a summary of the law
(what I think is relevant here) below. FYI, though I've had professional
reasons to familiarize myself with the law, I'm not a lawyer.

IMHO, there are things in the law that make it necessary for the protocol
to permit transport of certain data regardless of implementation. But as I
haven't done my homework properly yet (going through all the material
produced by this group) I will not make any suggestions. I hope the text
below will shed some light on the problem for those more familiar with the
protocol specifications.

Eva Stengård
Project Associate
MuseDoma

-------------------

The law applies in all cases where the gathering party is established in
Sweden (regardless of where the data is kept). It also applies when 
parties established outside of Sweden keeps/ process data on equipment
located in Sweden.

A number of basic requirements is put on any processing.
The gathering party is responsible for making sure that
- the data are only used for legal purposes;
- the data are always processed correctly and in correspondance with 'good
common praxis';
- data are only collected for especially specified and relevant tasks (any 
processing inconsistent with these tasks is forbidden);
- only data relevant (and no more) to the tasks at hand are collected;
- the data processed are correct and, if necessary, up to date;
- best effort is made to correct, block or remove data that are incorrect
or incomplete with regard to the purpose;
- data is not kept longer than necessary.
[Historical, statistical and scientific purposes are deemed always
consistent with the original tasks.]

The gathering party is also responsible for inform the person what data
are collected and how it's going to be used as wells as keeping the data
safe from irregular use. [Detailed regulation.]

Processing is OK when the person from whom the data originates has given
his/ her consent OR
- it is necessary to fulfill or make possible to fulfill an agreement with
the person;
- the gathering party is fulfilling a legal obligation;
- vital interests of the person is to be protected;
- a task of common interest needs to be performed;
- it is necessary in connection to 'governmental purposes' [it's more
rigid in the original text but I'm uncertain about the translation];
- it is necessary in connection with a relevant interest deemed being more
important than personal integrity.

Processing is NOT OK in connection to 'targeted marketing' [spam] IF the
person, in writing, has opposed this [opt-out].

There are also special rules regarding processing of 'sensitive data'.

Of interest may also be that it is in general forbidden to transfer
processed data or data for processing to a third country.
Exceptions is made if
- the person has given his/ her consent;
- it is necessary to fulfill or make possible to fulfill an agreement with
the person;
- legal claims are to be confirmed, made valid or protected;
- vital interests of the person is to be protected;
It's possible to get some other exceptions in certain circumstances.

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 05 Apr 2002 11:09:46 -0600

Thanks Eva.

Based on the material below, it would appear to me that the requirements
are only applicable to the providers, and do not impose any special
demands on the protocol. To the extent that a provider has to conform to
these demands, they can:

  1) get authorization from the user during the registration process

  2) provide limited information locally and use referrals to redirect
     queries to user-managed contact information

In either or both of those cases, the demands (as I understand them) would
be satisfied.

My opinion/interpretation

---

From: [email-masked] (Andrew Newton)
Date: 08 Apr 2002 11:21:08 -0400

I agree.

>      queries to user-managed contact information

The need for referrals is a demand for a requirement of the protocol.

[... parts snipped ...]
> > person, in writing, has opposed this [opt-out].

It would seem that preventing spam for a person who has opted out and
fulfilling legal obligations or providing data for governmental purposes
may also place requirements on the protocol.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Mon, 08 Apr 2002 12:48:22 -0500

> The need for referrals is a demand for a requirement of the protocol.

Yeah, it certainly should be in the requirements if it isn't already.
Specifically, this is a need for continuation referrals, where the
registrar provides *some* information but where *more* information is
available at this other location. I do not want all contact data to exist
in a remote database, as that model lets spammers and other abusers hide
themselves very easily.

It would be nice if we could demand some sort of public key certificate
for this stuff so that we could always see some form of identify. Probably
won't work, either for technical, political or nationalist (exposes some
personal data) reasons.

> may also place requirements on the protocol.

Wouldn't that kind of flag be part of the provisioning database rather
than the query database? EG, you could make this data available as data in
the lists which are sold, rather than through the not43 interface.

---

From: [email-masked] (Shane Kerr)
Date: Mon, 8 Apr 2002 21:27:06 +0200

On 2002-04-08 12:48:22 -0500, Eric A. Hall wrote:
> 
> Andrew Newton wrote:
> 
> > >   2) provide limited information locally and use referrals to
> > >   redirect queries to user-managed contact information
> > 
> Yeah, it certainly should be in the requirements if it isn't
> already.  Specifically, this is a need for continuation referrals,
> where the registrar provides *some* information but where *more*
> information is available at this other location. I do not want all
> contact data to exist in a remote database, as that model lets
> spammers and other abusers hide themselves very easily.

I like the idea of continuation referrals.  In fact, this seems like
it could fit in well with *ahem* extending existing protocols.

I'm not exactly sure what the issue with spammers and other abusers
is, however, or why they may more easily take advantage of referrals.

> It would be nice if we could demand some sort of public key
> certificate for this stuff so that we could always see some form of
> identify. Probably won't work, either for technical, political or
> nationalist (exposes some personal data) reasons.

I'm also not sure how the desire for a certificate fits in with the
desire for a continuation referral.  Or why it wont work.  :P

-- 
Shane Kerr
Only representing my own interests here.

---

From: [email-masked] (Andrew Newton)
Date: 08 Apr 2002 16:57:55 -0400

> it could fit in well with *ahem* extending existing protocols.

I think this is probably one of the reasons why an LDAP solution to this
space might be better... not because of the technology but because of
the adoption.  How many of us believe a registrant is going to setup a
whois server, an rwhois server, or even an IRIS server just to do this? 
The reality is that they probably already have an LDAP server... if it
isn't AD present in XP or Exchange, it is probably iPlanet or OpenLDAP
doing NIS or white pages for their Postfix or Courier setup, or one of
the other many reasons (applications) for which they have deployed it.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Mon, 08 Apr 2002 16:09:43 -0500

> is, however, or why they may more easily take advantage of referrals.

There are multiple kinds of referrals. Subordinate referralsa say that
*all* of the data is at some location. The problem there is that the user
can provide intentionally misleading information. EG, a spammer who
doesn't want to get their account yanked could provide false information,
either to mislead ("I am Donald Duck") or to defame ("I am Shane Kerr").

Continuation referrals provide *some* information locally, but provide
pointers to *more* information at some other location. EG, the registrar
says "he is Joe Spammer" while the referral says "I am somebody else".

> desire for a continuation referral.  Or why it wont work.  :P

Certs would provide third-party validation of who the operator really is.
EG, there could be:

    registry --> "he registered as Joe Operator"
    certauth --> "the cert is for Joe Operator, and is valid"
    operator --> "I am Donald Duck"

There are lots of reasons why people don't want this, or why it isn't
entirely feasible to demand it. On the other hand, this application in
particular is only for certain audiences, so it is possibly to mandate
that this limited audience provide the information. Dunno, but it seems
like this would be an extremely political can of worms to get into.