Subject: [Ietf-not43] minutes of CRISP in Vienna

From: April.Marine at nominum.com (April Marine)
Date: Thu Aug 14 14:46:35 2003

Crisp WG - IETF 57 - July 16 2003 - Vienna

CHAIRS:	Ted Hardie <[email-masked]>
	April Marine <[email-masked]>

SCRIBE: David Knight <[email-masked](edited for length by April)

- Agenda Bashing

  Ned (sheparding AD) is on a leave, John Klensin will stand in

  George Michaelson: Cathy Murphy should make a contribution.
  Cathy Murphy: In the AOB

- IESG Feedback on Requirements ID (10 Minutes)

  Document was sent, there was some feedback regarding privacy issues.

  Concern raised by security ADs: no mechanism in the protocol for
  someone who had priviliged access to see what was priviliged and what
  was not. Protocol requirements should include something that allowed
  for this kind of distinguishment.

  Group discussed, especially experiences from PROVREG group.  Andy
  Newton, requirements doc editor, said he could send proposed text
  to address this to the list for review.

- FIRS Matrix Compliance (35 Minutes) Peter Gietz DAASI

  Peter presented the requirements, with comments indicating where the
  requirement might not have been clear.  FIRS met all requirements,
  but it emerged that LDAP would actually need extensions written to
  handle some of them.  These extensions are not yet specified, and
  so the FIRS work would have to include that specification.

  Along the way, in discussion of 3.2.2.1 re IDNs, Patrick noted the
  following regarding a change from the UNICODE Consortium:

   Patrik Folstrom:
     If the client is using UNICODE 4 and the request is normalised you
     will not get a match. The errors that the unicode consortium is
     creating can only increase in size. They have changed their
     definition of what stable means. Hope that the IAB can present a
     document on this issue. You don't know today what codepoints will
     be problematic in future. The IDN docs don't talk about this. We
     thought stable meant something else. Storing things directly in the
     normalised string is soemthing we should think about.

     The conclusion is that the IETF is using Unicode in the wrong
     context of what we thought.

- IRIS Matrix Compliance: Ed Lewis, Scott Hollenbeck:

   Ed:
   Started reading in March, couldn't grasp all the requirements.
   Points out some requirements that were confusing.

   Were there any NOs?

   Ed:
   yes, in regard to relay bags

   Scott:
   Presented slides covering the messages sent to the mailing list
   and discussed his issues with the matrix in general.

- Next Steps and Milestones

   Ted: In San Francisco we spoke about next steps. Agreed we would first
   evaluate protocol requirements, if we have a winner then we stop
   processing and move on. Sounds like there needs to be one change in
   the doc, to describe how that particular function is done, meaning
   what LDAP extensions that may be required to implement FIRS.

   Second step is to look at service requiremets. This is harder
   than the protcol requirements, we need more justification for
   each of the responses on the service side. We need volunteers who
   are willing to write fairly comprehensively, do we have someone
   willing to do this for FIRS?

   Is there anyone willing to do this for the IRIS side?

   No volunteers came forward at this point.  Some discussion of
   other ways to proceed, including putting up test implementations
   of the protocols.  However, Ted points out that that is a lot of
   work and expense to go to just to avoid writing.  John Klensin
   points out that if we don't decide something soon, some other
   group will move forward along their own path and we'll have lost
   the opportunity.

   A straw poll of those present showed a strong majority of those
   expressing an opinion in favor of IRIS.

   The group agreed, then, on the following next steps;
      - the FIRS LDAP extensions doc would be written, completing
        the specificaions for both protocol choices
      - a 3 week discussion period on the list would take place,
        starting at the time the last doc was available
      - at the end of that 3 weeks, a call for consensus on the protocol
        to be recommended would take place.

- AOB

  Cathy Murphy:
  A new requirements draft is being coordinated amongst the RIRS, this is
  for resource number space, ASNs IPs, this is in final review, the
  draft itself will be on the table before Minneapolis.

  ?:
  Will you be asking for charter revision?

  Cathy: Probably
  If you want to float it first for review that would be ok.

---

From: hardie at qualcomm.com ([email-masked])
Date: Fri Aug 15 14:35:44 2003

At 11:46 AM -0700 08/14/2003, April Marine wrote:
>From the Minutes

As you'll note from the text in the minutes, the group agreed
to a three week discussion period to begin at the publication
of the FIRS LDAP extensions doc.  With the publication
of that document, the chairs believe that it is appropriate to
start that discussion period.  It will end three weeks from
today, on September 5, 2003.

During this discussion period, the group is expected to discuss
the pros and cons of the two candidate protocol suites, with
two main aims:  identify any remaining requirements which have
not been met by the protocols; assess and comment on the
suitability of the protocols for the task set out in the requirements
document.

It is explicitly in scope for this discussion to consider the effort
in development and deployment of clients and servers; it is
also explicitly in scope to consider the advantages and disadvantages
of reusing specific technologies (LDAP, XML).

The group has so far managed to avoid making its consideration of
these topics in the context of ad hominem  attacks or religious
debate.  Once again, let me thank you all for your professionalism
in this regard.   I urge you, as well, to continue in that vein through
this period of consideration.

			regards,
				Ted Hardie
				April Marine
				Chairs, CRISP

---

From: richard at shockey.us (Richard Shockey)
Date: Mon Aug 18 21:10:21 2003

over a more substantive discussion of the meta issues involved in FIRS vs IRIS.

I'll say it again folks ... I oppose FIRS on the merits for the reasons I 
outlined previously and I would like my colleagues in the Domain Name 
Industry and RIR's to please come out of the closet and make your views known.

In the closed environment we are dealing with which means the Domain Name 
Industry and the RIR's will be directly affected by the protocols adopted 
here I think it is prudent to evaluate these proposals based on their 
economic impact on our operations as well as the merits of their 
conformance to the requirements.

and yes I will freely admit I prefer XML query response mechanisms to LDAP 
on a purely Layer 10 basis.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: wessorh at ar.com (Rick Wesson)
Date: Mon Aug 18 23:39:18 2003

hi rich,

> Industry and RIR's to please come out of the closet and make your views known.

i like xml, does this mean i'm out now? I even told my parents -- i like
XML!

-rick

---

From: shane at ripe.net (Shane Kerr)
Date: Tue Aug 19 08:22:38 2003

Richard Shockey wrote:
> I'll say it again folks ... I oppose FIRS on the merits for the reasons 
> I outlined previously and I would like my colleagues in the Domain Name 
> In the closed environment we are dealing with which means the Domain 
> Name Industry and the RIR's will be directly affected by the protocols 
> adopted here I think it is prudent to evaluate these proposals based on 
> their economic impact on our operations as well as the merits of their 
> and yes I will freely admit I prefer XML query response mechanisms to 
> LDAP on a purely Layer 10 basis.

Personally, I prefer XML based mechanisms.  We use XML here, and XML 
maps in a straightforward way to our schema.

We could probably use LDAP, but a lot of our problem space is either:

- not hierarchical
- searches not lookups

LDAP is not really a technology we're familiar with, so the cost would 
probably be higher here than for XML.  I expect we'll have to do some 
software development on our side no matter what, and not having to 
learn a new paradigm would be a huge cost savings.

I know LDAP has authentication baked-in, but I don't really know how 
it applies to the FIRS universe.  This could be a win for the LDAP 
implementation.

To be honest, I haven't read all of the drafts, and the information 
may be there.  But there are 151 pages of draft for FIRS and 173 pages 
of draft for IRIS.

I have read the 26 pages of requirements from the RIR's though.  :)

-- 
Shane Kerr
RIPE NCC

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Tue Aug 19 09:22:52 2003

Ok by now we had some general postings saying "I like XML better", one 
explicitly on layer 10 (religion).

This one is a bit more concrete:

Shane Kerr wrote:

>> I'll say it again folks ... I oppose FIRS on the merits for the 
>> reasons I outlined previously and I would like my colleagues in the 
>> Domain Name Industry and RIR's to please come out of the closet and 
>> make your views known.
>>
>> adopted here I think it is prudent to evaluate these proposals based 
>> on their economic impact on our operations as well as the merits of 
>> their conformance to the requirements.
>>

LDAP is designed for searches, in fact a lookup is just a sub case of 
search.

You don't neccessarily have to stgructure the Directory Information Tree 
   with a deep hierarchy. Anyway the possibility to do so, is IMHO one 
of the arguments for LDAP: The mapping of the domain names with 
DomainComponant naming is so intuitive.

Ok: I admit: being familiar with that technology for quite a while: I 
like LDAP. I hope my reasons are not (only) on layer 10. I BTW like XML 
as well, and for each use case there are cons anfd pros on both sides.

> software development on our side no matter what, and not having to learn 
> a new paradigm would be a huge cost savings.

Yes there are differences and in some respect (mainly on the actual 
protocol side with ASN.1 and DER-encoding) LDAP tends to be a bit more 
complex. But as user or application developper, you don't have to deal 
with that complicated stuff since it is handled by the many available 
LDAP libraries for almost any programming language you want to use (C, 
Java, Perl, Python, PHP come into my mind right now, there will be more 
languages with LDAP support). So what remains for you to get familiar 
with is the schema paradigm and that is quite intuitive and can 
basically be described in a couple of sentences:

- information is stored in entries that are nodes in a tree
- entries consists of attributetype/value pairs
- attributetypes are specified with an attribute syntax and matching
   rules
- Matching rules specify behavior, in comparisions and ordering (e.g.
   caseexact vs. caseIgnore)
- there is one (or more) special attributetype/value pair that forms the
   name of an entry
- there is one or more special attributetypes called objectclass that
   describe the structure, main characteristics and secondary
   characteristics of an entry
- Thus object classes specify which other attributes MAY or MUST be used
   in an entry
- an objectclass can inherite qualities from another objectclass, e.g.
   organizationalPerson inherits from person
- an attributetype can be inherited from another attributetype, e.g.
   common name is inherited from name

I think this paradigm is quite easy and intuitive and makes a lot of 
sence, when you want to store informations about real world entities. 
Especially the inheritance mechanisms are extremly useful.

> 
> I know LDAP has authentication baked-in, but I don't really know how it 
> applies to the FIRS universe.  This could be a win for the LDAP 
> implementation.

Yes you can even choose between a number of authentication mechanisms, 
e.g. userpassword via an encrypted TLS session, MD5 chalenge response 
(no password goes through the wire) via SASL, any other SASL mechanism.

Authentication is not the only inbuilt feature of LDAP that can be used 
for crisp (FIRS): all implementations have granular access control, and 
replication mechanisms. Distribution of the data on several servers is 
already defined in the standard. The implementations are stable and 
reliable, some are capable of storing tens of millions of entries in one 
server. But you would not need to store all data of, e.g. a .com 
registry in one server, you can have one (referral) server pointing to 
any number of (data) servers.

As the discussion about FIRS has shown and will show, all features 
needed can be specified by the extension mechanisms inherent in LDAP.

By now the XML database technology is not near as mature and well 
established as LDAP. You don't even have a single standardized acces 
protocol, but competing ones (Xquery, XMLquery, Xpath, XQL, ...). I 
don't know of any native XML database implementation that has inbuilt 
features like authentication, access control, replication. Most 
implementations use an SQL backend to an XML frontend. The mapping of 
the (hierarchical!) XML information model to the (non hierarchical) 
relational model is not very intuitive.

BTW there is a proposal called XML enabled Directory wihcb uses LDAP as 
datastore for XML applications. See 
http://www.ietf.org/internet-drafts/draft-legg-xed-roadmap-00.txt and 
the docs quoted therein. This could even be the base of an IRIS 
implementation with an LDAP database.

I hope this made sence on technical levels as well.

Cheers,

Peter
> 
> To be honest, I haven't read all of the drafts, and the information may 
> be there.  But there are 151 pages of draft for FIRS and 173 pages of 
> draft for IRIS.
> 

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 T?bingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Tue Aug 19 11:34:01 2003

> (no password goes through the wire) via SASL, any other SASL mechanism.

As a point of comparison, IRIS uses BEEP which has SASL as well.

I'd also like to point out that if you have a custom data store on your 
LDAP server, all that built-in authorization stuff goes out the window.

This is a point that keeps getting glossed over by the LDAP crowd here. 
  Most of us already have our own databases and loading and replication 
procedures.  RIPE has this nifty software that does incredibly fast 
radix indexing specifically to solve their unique problems.  We have a 
couple of million dollars invested in custom global replication 
technology.  I know our competitors have also spent tons of money fine 
tuning their systems for their operations.

The point is, that for the people standing up these servers, LDAP is 
only a protocol.  The implementations are nice, but they don't help us.

> relational model is not very intuitive.

As mentioned above, the question isn't about generic XML database 
technology vs. generic LDAP technology.  I suspect that I would end up 
making some of the same criticisms about generalized XML database 
implementation as I would about LDAP implementations.  And there are 
certainly a few of those wacky X* standards that are nothing but trouble.

To address Richard's point about economics:  one of the things that we 
must take into consideration is reuse of expertise of our technical 
staff.  Even if we don't reuse a single line of custom code, we still 
have to find people with expertise.  Most of us already have people very 
familiar with XML.  We know which XML parsers work for us and we know 
how to marshal it back and forth between our existing databases.

-andy

---

From: davidb at verisignlabs.com (David Blacka)
Date: Tue Aug 19 11:37:55 2003

In the hope that this will be useful, I thought I would describe the
intellectual journey that led me (and Mr. Newton) to IRIS.  I thought
it might be useful to give this story a slightly more personal spin,
although Andy has pretty much documented everything in his draft
describing our LDAP project
(http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt)
and some of the conclusions drawn from it (appendix C of the IRIS core
draft).

Feel free correct any inaccuracies you feel that I've made.

--

In the beginning (I am thinking 1999 or so), when my group started
looking into WHOIS alternatives, LDAP was a tough sell.  A number of
us (with one exception) were avowed LDAP haters.  As folks used to
dealing with prosaic protocols like SMTP and NNTP, LDAP's BER encoding
was hard to swallow (We can't see what is going on with tcpdump!  I
can't use telnet as my client!).  LDAP itself was a confusing array of
alien terminology.  It was really hard for us to get through an LDAP
RFC.

Ultimately, however, we got over it, due to our one persistent team
member who knew better.  In 2000 (I think, I could have the dates
wrong), we started looking very seriously at using LDAP to replace
WHOIS.  After all, it had a bunch of bits that we wanted: granular
ACLs, referrals, and a fair amount of existing software.  We realized
that LDAP had a lot to offer and our previous complaints were
superficial at best.

Our first approach was to see if we could find an existing LDAP server
that could handle our existing WHOIS data load and query rates.  We
had about 20 million objects all told (domains, hosts, and contacts.
It is more than that now). I don't really remember the query rates,
but we were hoping for hundreds of queries per second.  We spent about
a year looking.  That is when we learned our first lesson:

* LDAP servers are hard to scale.

A provocative statement, I'm sure.  All of the advertising literature
we got for every LDAP server said that it would handle "millions" of
objects.  We didn't do exhaustive testing, so it is quite possible
that some other set of millions of objects might actually work with
those servers.  But not ours (and by extension, any other domain
registry/registrar's).  We couldn't even load a significant fraction
of our data into many of them.  We were drawn to the few LDAP servers
that were ultimately based on RDBMSs.  On those, we could load the
data (if I remember correctly), but the query speeds were not good,
and the database sizes were huge.  Our 3 GB database turned into a 60
GB database, just by loading into the LDAP server.  Lesson 2:

* Forcing data into a generic LDAP DIT causes significant data bloat.

You could easily slow the whole system by asking 'hard' questions
(i.e., any subtree searches rooted at a TLD).  The servers didn't do
referrals well (at least one so-called LDAP v3 compliant server didn't
actually do LDAP v3 referrals!).  Then we ran into our show stopper: a
compliant LDAP server must return all referrals in scope.  As we were
trying to have registry domain objects refer to their registrar entry,
this was a serious problem.  Keep in mind that automatically followed
registry to registrar referrals was one of the motivating factors in
trying to replace WHOIS in the first place.  This rule essentially
made subtree searches against our DIT useless.  You see, any subtree
query rooted at a tld (or higher in the DIT) would immediately have to
return all of the referrals contained within that subtree.  Or (at the
registry level) one for every domain.  In other words, millions of
referrals.  Lesson 3:

* LDAP referrals are for gluing DITs together, and thus are not
  generally useful for registry-registrar referrals.

We needed them to work more like DNS referrals: only referrals that
matched the search criteria (or whose parents matched the search
criteria) would be returned.

During this process, we believed in LDAP.  But it was slowly dawning
on us that "stock" LDAP servers weren't going to work.  However, we
were determined to make LDAP work.  So, we moved on to the next
approach: a custom datastore plugin.  This would allow us to control
the database size (indeed, we would use our source database), and
control when referrals would be returned (even though this technically
violated the spec.)  Then we learned Lesson 4:

* LDAP datastore plugins take a lot of work.

Our plugin would map a more naturally normalized database of domain
information into a DIT.  It would translate queries into SQL.  It
would translate result rows into LDAP objects.  Initially our plan was
to create sort of a generic mapper that would take arbitrary LDAP
searches and translate them into SQL.  We learned that all sorts of
horribly inefficient queries would result.  (RDBMS-based LDAP servers
essentially index every attribute-value to handle this.)  We decided
to allow a number of specific queries that matched our known use
cases.  All other queries were explicitly disallowed.  The number of
allowed queries was pretty small when compared to the number of
disallowed queries.  Thus Lesson 5 was learned:

* The LDAP query language (generally) must be severely constrained
  when using a custom datastore.

Our work on the client side is less familiar to me, but I do know that
it became quickly apparent that 'ldapsearch' was not at all sufficient
as a client of this service.  Custom client code using LDAP libraries
was necessary.  We did find pretty good LDAP client libraries.  I
remember particularly liking Netscape's Java LDAP SDK.  Lesson 6:

* This problem domain requires custom clients.  Generic LDAP clients
  are not sufficient.

In the end, we got this to work.  The results are still available at
http://rldap.verisignlabs.com.  You may wish to keep in mind that the
RLDAP project was far more heavily focused on reuse than FIRS: it
strove to not introduce any new objectclasses, attributes, controls or
extended matching rules.

But when we finished, we realized that if we had to 1) essentially
create a custom LDAP server and 2) create custom clients, reusing LDAP
was losing its appeal.  Creating a WHOIS replacement using LDAP was
requiring a fair amount of "bending", and even when we were done, the
solution was far from ideal.  We started to realize that real, global
directory service applications were going to always be essentially
custom directory applications.  Real directory service clients were
going to be custom clients.  Why not define a directory service
protocol that lent itself to being *good* at custom directory
services.  This led us to a philosophy that, ultimately, led to IRIS.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Aug 19 11:47:54 2003

> only a protocol.  The implementations are nice, but they don't help us.

The other point that keeps getting glossed is that there are a huge number
of potential providers in a directory of Internet resources, not all of
whom are going to be affected by these restrictions. If we start getting
into things like having organizations run public directory partitions for
things like public keys or mail-routing data or whatever, then it doesn't
make sense to REQUIRE that these people also pay the costs required for
your line-of-business in particular, but that's what you're advocating.
Essentially your argument is "my business makes me build and manage
complex distributed database so everybody else should too, dammit!", which
is not only ridiculous and obscene but is ultimately going to be a major
hurdle towards the directory actually getting used for a whole lot more
than what we've got today.

Look, I'm all for Direct Democracy and having constituents vote their
interests, but that decision process depends heavily on the constituents
accurately representing the affected community and being informed about
the choices. IMO, we have satisfied neither of these considerations at
this point. Instead, we have a vocal mob from a demographically-tiny
group, most of whom apparently haven't even read the specs.

My feeling at this point is that we'd be best off by going with some
representative democracy. Let's recruit some people who we know can think
beyond their immediate benefits and who have the technical chops to
understand the longer term issues.

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

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Aug 19 12:10:28 2003

on 8/19/2003 10:34 AM David Blacka wrote:

I don't doubt that you ran into the difficulties you did as a result of
trying to pursue the course you chose.

> You may wish to keep in mind that the RLDAP project was far more 
> heavily focused on reuse than FIRS: it strove to not introduce any new 
> objectclasses, attributes, controls or extended matching rules.

Exactly right. A couple of the problems you encountered would still exist
with FIRS, but for the most part, starting with a different objective
(optimizing the application space accordingly) would have produced some
significantly different result. As you allude to in the text above (and
which would probably have been more helpful as intro text rather than
outro by-the-way), your path doesn't really say much about how well the
FIRS approach would work.

> was losing its appeal.

Yes, FIRS optimizes the client and server. Whether or not this diminishes
the primary benefit depends on how you define the benefit. If your target
was to reuse LDAP browsers, I can see how the evidence would support that
conclusion. On the other hand, if the target is general data-availability
and reuse, then I would argue that the objective was proven once the
assumptions were adjusted.

>  This led us to a philosophy that, ultimately, led to IRIS.

Could you possibly clarify how IRIS addresses either of the targets
described above? I mean, there are a whole lot less clients and servers
out there, so reusing technology isn't a benefit, nor is reusing data.

Perhaps you redefined your objectives along the way? And if so, what are
they now?

---

From: richard at shockey.us (Richard Shockey)
Date: Tue Aug 19 12:39:51 2003

A
>than what we've got today.

You are zeroing in on a key disconnect here ..is CRISP a database or a 
directory? I think its a database. The semantical difference is fine but it 
defines the perspective some have on the CRISP problem statement in general.

The excellent historical perspective from David Blacka completely 
re-confirms my judgement and reinforces my opposition to a FIRS solution.

Oh and last but not least ... irrespective of my employer, where we do 
manage two TLD's. I'm also the co-chair of the ENUM WG and if Verisign has 
trouble scaling LDAP to 20M entries what would we do with the 230M entries 
in the North American Numbering Plan, for instance??

It has been my high hope from the beginning of this WG that a CRISP 
solution could be reused by the various National ENUM administrations 
sprouting up all over the planet.  We are already getting requirements 
thrown at us for a database of technical contacts for the FQDN's RFC 2916 
defines.

---

From: davidb at verisignlabs.com (David Blacka)
Date: Tue Aug 19 12:59:53 2003

> FIRS approach would work.

As far as I can tell, FIRS would be harder to implement at our level, not 
easier.  Which of the problems that I described would be alleviated by 
FIRS?  I will admit that I don't entirely grok FIRS.  It certainly looks 
like the client side would be harder (than RLDAP clients).

One of the main things that I wanted to show through my story was that we 
ultimately rejected LDAP for actual, valid, non-religious reasons.

> assumptions were adjusted.

Our target was to use technology that would reduce implementation costs on 
both the client and server sides.  And the project proved to us that LDAP 
(in this case) did not do that.

And honestly, from what I can tell (and again, I might be wrong), FIRS is a 
move in the opposite direction from that target.

> out there, so reusing technology isn't a benefit, nor is reusing data.

I think I don't know what you are talking about when you say "reusing 
data".  What data?

The move towards IRIS was a move towards doing software reuse at a 
different level.  IRIS certainly reuses technology, just not an entire 
application substrate.

There aren't many FIRS clients and servers out there either.  One of the 
points I hoped folks might draw from my little story was that for those 
organizations that will *have* to stand up a CRISP service, they aren't 
any closer to implementing a FIRS solution than an IRIS one. 

> Perhaps you redefined your objectives along the way? And if so, what are

I don't think we redefined our objectives at all.  Fundamentally what we 
did was change our engineering approach.  And I, at least, changed my 
underlying directory service philosophy.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Aug 19 13:02:27 2003

> re-confirms my judgement and reinforces my opposition to a FIRS solution.

That's too bad, since he admits that their experience doesn't represent
the FIRS approach.

> thrown at us for a database of technical contacts for the FQDN's RFC 2916 

I'm glad you brought up ENUM, because I didn't want to. That service has
actually been in the back of my mind while doing this work, and I think
it's a fine illustration of the canonical issues.

First of all, there is a question of whether or not a centralized database
of phone/contact data is even the right approach. I'm not going to argue
either way right now, but there is plenty of evidence to suggest that
trying to support billions of phones looking up billions of phone numbers
isn't practical in a central model, even using lightweight DNS datagrams.
Secondarily, the technology deployment curves also suggest that the
long-term use will be distributed directories of locally-manged numbers
and data, with gateways publishing their own details rather than trying to
synchronize with a centralized repository. Along the same lines, being
able to manage things like ACLs is going to require pushing the service
closer to the user (EG, ~I want my boss to have my home phone, but not any
of the other employees, while my wife gets the cell and everything else).
So there is some argument that a service like ENUM (if not that service
itself) would eventually be best served by a distributed directory rather
than a central database.

We need to be planning for this eventuality.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Aug 19 14:01:18 2003

on 8/19/2003 11:56 AM David Blacka wrote:

>> Exactly right. A couple of the problems you encountered would still
>> exist with FIRS, but for the most part, starting with a different
>> objective (optimizing the application space accordingly) would have
>> produced some significantly different result. As you allude to in the
>> text above (and which would probably have been more helpful as intro
>> text rather than outro by-the-way), your path doesn't really say much
>> about how well the FIRS approach would work.
> 
> As far as I can tell, FIRS would be harder to implement at our level,
> not easier.  Which of the problems that I described would be alleviated
> by FIRS? 

It seems to me that most of the problems you encountered on the way to a
working solution would have been avoided by a recognition that generic
tools weren't going to do the job. The FIRS approach would have moved you
to what eventually did work for you.

The central theme with FIRS is to populate the data substrate, but to
optimize the application space. In particular, "FIRS" is just a stovepipe
vertical application into the data substrate. The idea is that once the
substrate is populated, other stovepipes will poke into it, sucking data
out and putting new data in.

The degree to which any of those may require application-specific logic
will depend on the application. Some of them will need some local logic
and no server logic -- "give me the host certificate for this mail
server/user" would only require client processing -- while others will
require additional back-end logic. FIRS the service focuses on high
volume, centralized delegation data, so it falls into the latter in the
general case, but it also off-loads significant processing onto the
front-end to minimize the back-end burden (normalization of i18n domain
names being an obvious example of this, where back-end normalization would
crush the servers). There are also a couple of areas in FIRS where the
client does all of the work; contact lookups are equality matches, for
example, with the client doing all of the prep work.

> I will admit that I don't entirely grok FIRS.  It certainly
> looks like the client side would be harder (than RLDAP clients).

It is necessarily more tuned, but I don't see this as an indictment. Any
client that is part of a distributed system require custom clients. This
even applies to legacy WHOIS, for example, where either the client has to
perform local processing, or it uses an application proxy which is
essentially a remote client.

> Our target was to use technology that would reduce implementation costs
> on both the client and server sides.  And the project proved to us that
> LDAP (in this case) did not do that.

How is IRIS cheaper on the client side for this specific application? You
have to do even more work, given the lower availability of tools (no BEEP
perl module, for example).

For the same reasons, I don't see how IRIS could possibly be cheaper for
lightweight (edge-distributed) servers that do not require additional
processing (eg, publishing certificate data), given that there are
numerous servers available to choose from which could do the job as soon
as the schema were installed.

Andy said in another message that the server deployments for ~this
applicaiton were relatively equal.

Meanwhile, the learning-curve costs you describe were essentially
amortized on the back of RLDAP. You didn't have to make the same mistakes
with IRIS, and had better expectations going into it, so it would be
expected to have been cheaper and faster. As noted multiple times,
however, these costs are not globally applicable.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Tue Aug 19 14:30:45 2003

> perl module, for example).

Quit attacking BEEP.  If you cruise on over to http://beepcore.org you 
will see there are plenty of BEEP implementations out there, most of 
them are open source.  There are probably more open source versions of 
BEEP than there are open source LDAP client libraries.

This also brings up another point of comparison.  If we decide that BEEP 
is not the correct answer, we can slide in another application transport 
because IRIS is a layered protocol.  See my drafts on IRIS LWZ.

> as the schema were installed.

Again, you are blurring the lines between protocol and implementation. 
Flowerbed is cheap and lightweight.

> applicaiton were relatively equal.

No, I said LDAP did not offer an advantage.  You are the one who equated 
them.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Aug 19 14:50:09 2003

on 8/19/2003 1:30 PM Mark Kosters wrote:

> On Tue, Aug 19, 2003 at 01:00:59PM -0500, Eric A. Hall wrote:
> 
>>  optimize the application space. In particular, "FIRS" is just a
>> stovepipe vertical application into the data substrate. The idea is
>> that once the substrate is populated, other stovepipes will poke into
>> it, sucking data out and putting new data in.
> 
> This is the holy grail that we all hope to achieve with a better
> protocol. Unfortunately, all past efforts failed (X.500, RWhois,
> whois++) given they tried to point too high trying to achieve the holy
> grail and did not solve the immediate problem first. I think if set our
> sites a bit lower and can do the best we can do in having a protocol
> that solves the registry problems, we may have something that can usurp
> whois.

I think that's what has me hot: Nobody has said this won't do it, and
instead are looking at religion and short-term interests.

But let's be positive. Could somebody from the other camp give some
discussion on how they see IRIS satisfying the longer-term issues. AFAICT
there's no focus on unified substrate in IRIS.

---

From: markk at verisignlabs.com (Mark Kosters)
Date: Tue Aug 19 14:58:48 2003

> out and putting new data in.

This is the holy grail that we all hope to achieve with a better protocol.
Unfortunately, all past efforts failed (X.500, RWhois, whois++) given they 
tried to point too high trying to achieve the holy grail and did not
solve the immediate problem first. I think if set our sites a bit lower
and can do the best we can do in having a protocol that solves the registry 
problems, we may have something that can usurp whois. 

Mark

---

From: richard at shockey.us (Richard Shockey)
Date: Tue Aug 19 15:35:08 2003

>instead are looking at religion and short-term interests.

Well we have stipulated that for all practical purposes the two proposed 
protocols _on paper_ will meet the requirements its just that we don't want 
to use FIRS for very very practical and economic reasons as well as the 
technical reasons David Blaka has demonstrated to my satisfaction.

That is not a short term view it is the reality of the Domain Name 
business. In case you had not heard its a highly competitive, mature 
business that is still trying to recover from the irrational exuberance of 
the past few years. Lots of TLD's are struggling to financially survive.

If it is technically "challenging" or expensive to implement a protocol the 
registry community will not do it or delay its implementation. ( DNSSEC 
..sorry :-) ) Especially among those of us that actually have to A. go 
capital expenditure budget meetings or B. actually have to do the work.

 From our perspective Mark Kosters is entirely correct ..I'm not interested 
in "holy grail" solutions either I want to see the existing problems in 
WHOIS corrected and made more flexible and extensible. IRIS meets those 
tests and integrates very nicely with the other XML query response 
platforms under construction. I'm sold.

I personally apologize to the WG chairs who I know would have preferred a 
more technically oriented discussion but ....

---

From: wessorh at ar.com (Rick Wesson)
Date: Tue Aug 19 15:47:16 2003

I definately agree with Rich here. I fer specify overly complex protocols
registrars and registries wil drag their feet or just down rite ignore it
until ICANN puts it as a requirement in a contract.

As long as we are dealing with domains we MUST recognize that adoption is
a real issue and if the spec is overly complex its not gonna get
implemented till ICANN enforces its mandate.

I'd prefer the specifications be compelling enough that registrars would
adopt them because they soleve problems with :43

-rick

Rick Wesson
CTO, DNSO Registrars Constituency
CEO, Alice's Registry

---

From: hardie at qualcomm.com ([email-masked])
Date: Tue Aug 19 17:01:30 2003

At 12:39 PM -0400 08/19/2003, Richard Shockey wrote:
>
>You are zeroing in on a key disconnect here ..is CRISP a database or 
>a directory? I think its a database. The semantical difference is 
>fine but it defines the perspective some have on the CRISP problem 
>statement in general.

Perhaps a quick quote of the salient charter text would be useful here:

The CRISP (Cross-Registry Information Service Protocol) WG will
define a standard mechanism that can be used for finding
authoritative information associated with a label, a protocol
to transport queries and responses for accessing that information,
and a first profile (schema & queries) to support commonly-required
queries for domain registration information. Backwards compatibility
with existing administrative directory services such as WHOIS is not a
goal of this effort. Provisioning of data into registry or registrar
systems is likewise out of scope -- CRISP provides a uniform
access to and view of data that may be held in disparate backend
servers. While the framework created will hopefully be sufficiently
flexible to allow re-use by other registries/services with related
design criteria, those uses will be deferred to the creation of
appropriate schema & query profiles at some future date.

The statement in what CRISP is not is probably the most
concise:  CRISP provides a uniform access to and view of
data that may be held in disparate backed servers.

Because the focus is on access, CRISP might be said to
be a directory service (though not strictly a directory);
and it may rely on (but is not) a database.
			regards,
				Ted Hardie

---

From: hardie at qualcomm.com ([email-masked])
Date: Tue Aug 19 22:33:02 2003

>there's no focus on unified substrate in IRIS.

I'm not from the other camp, but let me join my co-chair in trying to refocus
this discussion on the matter at hand.  Unified substrates, efforts
to have other stovepipes poking into that substrate, and holy grails
are not our business here.   Our goal is to meet our charter and develop
a protocol that satisfies the items set out in our requirements
document.  Openness to extensibility is one of the things mentioned
in the charter, but it is subordinate to meeting the needs of the chartered
work items.

On a more personal note, I'm sorry that you're feeling hot over this;
I had hoped we would be able to avoid heat in this discussion and could
focus on the technical issues at hand.   I encourage everyone involved to
take a moment and cool down.

There are serious differences in the technical approaches brought
forward in FIRS and IRIS, and I appreciate the effort that has been made to
explore the development, deployment, and related costs associated with
them.  But we need to do that while focusing on our task, not on what might be
built on top of the data store associated with our task or on tasks which
may come up in the future.  If it is not in the charter or requirements, please
set it aside.

As I said in the meeting in Vienna, it is also clear that each of 
these approaches
will require custom clients and at least some work on servers (schemas if
not extensions).  We do not have the option of rapid deployment by allowing
"standard" clients to access this application.  Given that, we are 
fundamentally
discussing two issues:  how well suited are the building blocks in one approach
to this task for reasons of scale, data model, accumulated experience 
(or cruft),
and is what has been built out of those building blocks meeting the 
requirements
that have been set forward?

To be very clear, this is not LDAP vs. XML.  This is "How do FIRS and IRIS meet
the needs set out in the requirements, and what are the deployment scenarios,
costs, advantages and disadvantages for this application?"

Everyone participating in this discussion needs to read the documents,
consider the question, and put forward your best engineering judgement
on behalf of the Internet as a whole.  That's the work of this working group,
and, indeed, the IETF.
			regards,
				Ted Hardie