Subject: [Ietf-not43] extensibility

From: edlewis at arin.net (Edward Lewis)
Date: Thu Jul 17 09:07:16 2003

I had a dramatically worded intro to this, but, I decided to spare 
y'all the theater and cut to the chase...

The current specification of FIRS and IRIS are cut to meet the 
"problems" seen by Domain registries.  It's conceivable that other 
kinds of registries might want to be accommodated in the CRISP 
protocol.  By other kinds I mean Address registries and Routing 
registries.

One observation I've been refining is that when you look at Domain 
registries, DNS is the most important protocol.  In the Address 
registry realm, routing is the most important protocol.  For Domains, 
routing, and for Address, DNS, are "optional" protocols.

DNS has a natural hierarchy, routing doesn't.  This difference make 
me question the FIRS definition of its name space as a basic tenet of 
that approach.

The message subject is "extensibility."  I chose that because I was 
thinking that the more extensible of IRIS and FIRS would be more 
promising.  Sure both LDAP and XML are expressive representations, 
but there is more to extensibility - like, what if the range of use 
of the protocol is extended?  That's behind my comment in the 
previous paragraph.

PS - I haven't had time to really think though how this plays for 
Routing registries.  If anyone can contribute thoughts on this, I'd 
appreciate it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...

---

From: richard at shockey.us (Richard Shockey)
Date: Thu Jul 17 09:57:26 2003

At 03:07 PM 7/17/2003 +0200, Edward Lewis wrote:

>I had a dramatically worded intro to this, but, I decided to spare y'all 
>the theater and cut to the chase...
>
>The current specification of FIRS and IRIS are cut to meet the "problems" 
>seen by Domain registries.  It's conceivable that other kinds of 
>registries might want to be accommodated in the CRISP protocol.  By other 
>kinds I mean Address registries and Routing registries.

We're looking at this in ENUM as well ...

>promising.  Sure both LDAP and XML are expressive representations, but 
>there is more to extensibility - like, what if the range of use of the 
>protocol is extended?  That's behind my comment in the previous paragraph.
>
>PS - I haven't had time to really think though how this plays for Routing 
>registries.  If anyone can contribute thoughts on this, I'd appreciate it.

I'm reasonably convinced of the extensibility arguments since it seems 
quite clear that the transport of XML objects for the purposes of look up, 
provisioning or commerce are well established in all sorts of protocols .

Beyond that I'm pro IRIS since we now have in the domain/RIR space EPP. 
Developed in PROVREG it follows the same basic protocol logic we have in 
IRIS ( move the XML blobs please).

IRIS specifies BEEP/TCP but it could easily be adapted to other transport 
layers etc ( yea SOAP) and I , for one, would like to maintain a consistent 
business infrastructure. In fact _some of you_ might remember NeuStar 
supported EPP over BEEP/TCP. Well that argument was lost ..but its still 
possible if the demand was there and that IMHO is the very definition of 
extensibility.

What I think people were thinking but could not express yesterday is that 
the real issue is not the applicability of one protocol or another to 
satisfy the requirements, lets face it both IRIS and FIRS will work ..its 
that there are serious business issues here.

And irrespective of the technical religious views of IRIS vs FIRS , the 
logical business choice, from my perspective , is IRIS.

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: ehall at ehsco.com (Eric A. Hall)
Date: Thu Jul 17 11:14:00 2003

> me question the FIRS definition of its name space as a basic tenet of 

I think you're looking at too high of a layer. That all of the proposed
resource-types use DNS is a coincidence of convenience at lower layers,
and is not a universal technical requirement.

The WG expended a fair amount of effort on this subject a while back. The
basic truth is that the WG has shunned building its own delegation system,
and that existing delegation systems have to be reused where they are
available, and that new delegations have to be created in the external
systems where they do not exist.

Specifically, the value of using an external existing delegation system is
that the registered operator of the resource will be able to control where
queries for their resource are directed, while the value of avoiding
duplicate delegation systems is that this information doesn't have to be
maintained twice, that ownership integrity checks don't have to be managed
twice, and so forth.

Any existing external delegation system can be used for this, but as a
practical matter, there is only one delegation system which satisfies
these concerns, which is DNS. In particular, things like common-syntax
URIs are only going to work with DNS, common-syntax service lookup (via
SRV) is only going to work with DNS, and so forth. Without checking, I
think the requirements still allow other delegation systems, but in the
end I am pretty sure that you'll come to the same conclusion.

FWIW, both IRIS and FIRS should be able to use whatever delegation system
you choose. The existing proposals use DNS as a practical result of the
practical considerations described above, but if there is some other
locator technology that you would prefer and which is available to
clients, then both systems are malleable and can probably use it. The FIRS
namespace is more visible and thus more transparent in its linkage, but
both technologies have the same basic dependancies, BTW.

> Routing registries.  If anyone can contribute thoughts on this, I'd 

You need to separate the concept of resources and service-providers. If
you want information about a global resource, ask the global (default)
namespace for information about that particular resource. If you want to
query a specific provider for information (including information about a
resource they manage), then you need to query for that provider.

There are multiple routing registries; there would in theory also be
multiple registry client applications, or a single client that is capable
of querying the multiple unique registries. Essentially, the FIRS model
would allow the client to construct the locator queries according to the
needs of each registry, but (in its existing form) would use DNS to locate
the servers for each of those registries. EG, an IRR could establish a
service under my-irr.net, and the client application would have to know
this, and would have to know to use queries for the dc=my-irr,dc=net
partition, rather than using the generic namespace.

All of that is separate from trying to find generic global delegation
information about a particular resource, such as a netblock or an ASN. The
global information for those global resources would still need to be
served through the global delegation system, which is currently DNS (see
the discussion at the top), meaning queries for in-addr.arpa or asn.arpa
in this case.

IRIS and FIRS are both heavily virtualized and are capable of handling a
significant range of usage scenarios, including different global resource
types, private service providers (using private partitions instead of the
default namespace), and alternative delegation mechanisms. These heavily
virtualized approaches can be difficult to get your head around.

-- 
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: Thu Jul 17 11:22:53 2003

on 7/17/2003 8:58 AM Richard Shockey wrote:

> What I think people were thinking but could not express yesterday is
> that the real issue is not the applicability of one protocol or another
> to satisfy the requirements, lets face it both IRIS and FIRS will work
> ..its that there are serious business issues here.
> 

I agree that operational convenience and potential (albeit probably
somewhat minor) cost savings through reuse are important factors, but they
aren't going to be the most important aspects for the Internet community
as a whole. We really don't want to make decisions based on the desires of
the operator community in particular. Otherwise, we'd just stick with
WHOIS since doing nothing is the cheapest and easiest by far.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Jul 18 08:48:15 2003

> Routing registries.  If anyone can contribute thoughts on this, I'd 

I thought up a good analogy this morning -- the use of multiple IRR
servers with [crisp] is very similar to the use of blacklists in DNS,
where each blacklist essentially acts as an application-specific private
partition, with the clients of those private applications using those
private partitions (where 'using' means knowing about their existence and
sending queries to those servers, versus using the public delegation
hierarchy). IRR servers (and other application-specific uses) would
probably operate in the same basic way in [crisp], with clients being
aware of the partition they need to use (the dc= hierarchy, in LDAP) and
also having to know which data-types to request, how the query should be
formed, and so forth.

We should also expect (and hope) that there would be lots more variations
on this theme, since we would not be limited to [name|type|class] queries
like DNS. Some applications will want to create their own partitions, but
others could reuse the public namespace and simply layer on their own
objectclass definitions at the public leaf nodes, too.

Hopefully that's clearer.

---

From: edlewis at arin.net (Edward Lewis)
Date: Fri Jul 25 17:04:09 2003

>WHOIS since doing nothing is the cheapest and easiest by far.

I think that's an oversimplification.  "Sticking" is cheap and easy, 
but WhoIs lacks some crucial features.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: edlewis at arin.net (Edward Lewis)
Date: Fri Jul 25 17:04:15 2003

>servers with [crisp] is very similar to the use of blacklists in DNS,

I'm not sure what you mean by a blacklist.  Do you mean a list of 
servers that a client relies upon for answers or a list of clients 
that a server will ignore?

>objectclass definitions at the public leaf nodes, too.

I'm not sure what you mean my partitions wrt DNS.  Like "class" or 
"type" or splitting the names in some way?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: edlewis at arin.net (Edward Lewis)
Date: Fri Jul 25 17:04:21 2003

At 10:13 -0500 7/17/03, Eric A. Hall wrote:
>these concerns, which is DNS.

Speaking mostly from the perspective of a chair of the provreg group, 
one thing I notice is that often times IETF WG's take on the bias of 
the participants.  Although this sounds like I am leading to an 
indictment of the process, I don't mean for it to be so.  I'm leading 
with this because I can see how domain name registration folks can 
see DNS as being the natural fit.  Ergo, I'm not going to argue with 
that the WG has found to date and how it got to that point.

I also should point out that I'm far from having a real, precise 
reason to disagree, I'm asking in a discovery mode.  I have yet to be 
convinced that DNS is the end-all for the purpose here (thinking of 
the domainComponents).  E.g., in some private communications (and at 
the end of my reply to Michael Dillon) I mentioned that, for example, 
as DNS zones are not necessary for address space to be useful, DNS 
isn't a reliable convention for finding the appropriate directory 
server when you are starting a query.  I might be running my own 
"CRISP" server and exchanging routes with others but not running DNS. 
(It could happen.)

It's over this uncertainty that I am raising the question of 
extensibility and whether it's a factor in FIRS' name space 
definition.

>These heavily

That's exactly what should be apparent from the WG's output - 
starting with a discussion in an archive and then followed up in a 
perpetuating document. ;)

That being said - my entire reply here is an aside to give my 
rationale for asking the question in the first place.  What I will 
need to do is to see just how a hierarchical name space helps, 
hinders, or neither the application space I'm considering.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Jul 25 17:15:19 2003

> but WhoIs lacks some crucial features.

The ratio of users to service providers is probably close to about
10,000,000:1 give or take a million. Making a decision based on the
convenience of ~300 whois providers is wrong, imo.

---

From: edlewis at arin.net (Edward Lewis)
Date: Fri Jul 25 20:15:44 2003

>convenience of ~300 whois providers is wrong, imo.

Your point is valid, but I don't think it is what Richard's (and my) 
comment centered on.  Just to try and clarify at least where I'm 
coming from...

There's a difference between the service offered and how it is 
implemented.  Given two implementations that that offer the required 
service and the desire to pick one, there has to be other 
differentiations made.  (This is the state the WG is in.  Both FIRS 
and IRIS are built to what we decided are the rules of the game. 
It's a tie according to this, but we can't have a tie.)

It's not a matter of what's best for the user vs. what's best for the 
provider.  Between FIRS and IRIS, well, let's assume they both 
provide the same service.  In that case I'd say it is valid for the 
providers to lean to the one that offers it more cheaply.  Because 
the cheaper one is chosen, in the long run every one wins.

Alternatively, if both provide the required service, and one does the 
job better than the other, then picking the more functional one is a 
logical choice - clearly so if they both cost the same to implement.

But what if both meet the requirements, but one alternative does a 
10% better job for 10% more cost?  15% more cost?

What Richard and I said was that for the provider, it seems that IRIS 
has an edge in adoption given other work being done in registries. 
Perhaps there are advantages down the FIRS road he and I are missing. 
And perhaps FIRS is more suited to what the consumers demand.  The 
latter two points need to be made.

This is why I raised the question about the name space and 
extensibility.  Is it just that I don't see the advantage of 
domainComponents?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Jul 25 21:42:37 2003

> the cheaper one is chosen, in the long run every one wins.

I disagree with both the premise and the conclusion.

Given that user-to-user applications can be expected to be deployed that
reuse the chosen transport, namespace, messaging, etc., the unavoidable
conclusion is that what's best for the user *IS* going to be the most
important. What is easy for them to deploy and manage, what offers the
most integration into other services, these are the criteria we should be
focusing on, since those will ultimately determine whether this is
actually a successful broadly-deployed service or if its just a more
expensive version of whois that is once again limited to being offered by
a handful of delegation bodies.

Furthermore, as far as the expense argument goes, I think that a critical
analysis on that point would actually favor FIRS. It may be cheaper for
delegation operators to reuse the provreg stuff (although I'm not even
convinced of that; just that it's more convenient), but for the average
user the initial cost won't have already been underwritten. I mean, LDAP
gives them a pre-networked database that is tightly integrated with a
transport service already, provides integrated authentication and
authorization services, has broad support from the vendor and support
communities, etc. I can't even find a BEEP module on CPAN, and remember
we're expecting the community to stitch together unspecified databases and
XML together and security and all of that everytime they want a new
application in the service space. Cheaper? LDAP definitely.

Then we get into the real meaty stuff, like the number of RFCs that have
gone into LDAP, and how long do you expect it would take to replicate all
of that in databaseX-beep-xml. Or, which do you suppose the PKIX community
would prefer, starting over with databaseX-beep-xml or LDAP. And numerous
other similar arguments.

Really what the favoritism towards IRIS boils down to is a preference for
convenience. Now we've got a hammer, let's go find some nails. That might
even be okay -- I'm certainly favoring LDAP because of convenience reasons
too -- except that provreg is a closed-community service. By that I mean,
the providers are the consumers and vice-versa, and supporting millions of
application agents probably wasn't much of a design consideration, while
that really has to be this WG's focus entirely (even if no user-to-user
applications are ever developed, we'll be looking at that scale from
programmatic lookups alone anyway).

> extensibility.  Is it just that I don't see the advantage of 

I don't see what domainComponent has to do with any of this. So the
linkage to a universal, managed namespace is transparent, so what?

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Jul 28 01:04:09 2003

Eric A. Hall wrote:
 > ...[snip]...
> convenience. Now we've got a hammer, let's go find some nails.
 >
 > ...[snip]...

I take great exception to this mis-charactarization of providers.  Many 
of us have spent and are spending a considerable amount of resources to 
get this right.  We have a pretty good idea about being on the business 
end of a tech support phone call when things go wrong.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Jul 28 08:43:55 2003

>> Really what the favoritism towards IRIS boils down to is a preference
>> for convenience. Now we've got a hammer, let's go find some nails.

> I take great exception to this mis-charactarization of providers.

> has an edge in adoption given other work being done in registries.
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

---

From: richard at shockey.us (Richard Shockey)
Date: Mon Jul 28 10:44:42 2003

>comment centered on.  Just to try and clarify at least where I'm coming from...
>
>service and the desire to pick one, there has to be other differentiations 
>made.  (This is the state the WG is in.  Both FIRS and IRIS are built to 
>what we decided are the rules of the game. It's a tie according to this, 
>but we can't have a tie.)

Thanks Ed .. the issue again see is is that all things being equal in terms 
of protocol and service requirements it boils down to Layer 8 (economic 
issues) and on that basis the advantages of IRIS at the margin tilt the 
balance.

There is nothing wrong with the expedience in a choice where all other 
factors are roughly equal.

>provider.  Between FIRS and IRIS, well, let's assume they both provide the 
>same service.  In that case I'd say it is valid for the providers to lean 
>to the one that offers it more cheaply.  Because the cheaper one is 
>chosen, in the long run every one wins.
>

Exactly IRIS provides a simplified overall business process architecture 
for,IMHO, the domain name industry based on what we have to do. I cant 
speak to the business process issues among the RIR's.

And lets face it the TLD operators, including my distinguished 
colleagues/competitors from Verisign really don't want to do anything if 
they don't have to since the economics of the business are not very 
pleasant these days even for a major Generic or CC tld.

One way or another implementing these protocols will cost money and my 
analysis concludes that IRIS will be simpler and less expensive.

>What Richard and I said was that for the provider, it seems that IRIS has 
>an edge in adoption given other work being done in registries. Perhaps 
>there are advantages down the FIRS road he and I are missing. And perhaps 
>FIRS is more suited to what the consumers demand.  The latter two points 
>need to be made.

If there are advantages of FIRS for consumers I'd certainly like to see 
that list.

But realistically I take John Klensin's comments to heart that the sooner 
we make a decision the better. There are Layer 9 issues here (political aka 
ICANN) we have to deal with.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Jul 28 10:54:37 2003

>>has an edge in adoption given other work being done in registries.

Richard's comment (in the meeting) was not exclusive to EPP.  It was 
more of a general comment about the world moving towards XML and related 
technologies (e.g. witness what is going on in netconf and idmef).

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Jul 28 11:04:45 2003

> factors are roughly equal.

I agree with this but let's be accurate about what we're advocating. The
requirements list numerous "actors" (and omits just as many), not all of
whom will benefit from this particular factor.

The question I'm trying to raise is whether or not this one factor
warrants ignoring or overriding all of the other actors' criteria, and as
should be clear I don't think it does.

> analysis concludes that IRIS will be simpler and less expensive.

I would like to review the criteria behind this analysis. For FIRS, the
requirement is (1) generate an LDIF file on a daily basis, (2) upload it
to the server, and (3) use a server that supports the FIRS extensions.
That is pretty cheap.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Mon Jul 28 12:50:40 2003

Richard Shockey wrote:

[...]
> Thanks Ed .. the issue again see is is that all things being equal in 
> terms of protocol and service requirements it boils down to Layer 8 
> (economic issues) and on that basis the advantages of IRIS at the margin 
> tilt the balance.
> 

As to layer 8, I agree with Richard here.

>> provider.  Between FIRS and IRIS, well, let's assume they both provide 
>> the same service.  In that case I'd say it is valid for the providers 
>> to lean to the one that offers it more cheaply.  Because the cheaper 
>> one is chosen, in the long run every one wins.
>>
> 

Is this really so? What makes you think so that a complete new 
implementation will be cheaper than using existing technology and do 
some tweaks to make it CRISP compliant?

Alone the fact that Eric could perl a FIRS client in one week prooves ho 
cheap it can be to deploy FIRS. I know it is a long way from proof of 
concept to production service, but what makes you think this path is 
shorter with XML?

Are there existing XML data base technologiers that are as performant, 
scalable and secure as are LDAP implementations?

Only because things like Web services are being deployed in the 
commercial  realm, does this make IRIS deployment really cheaper?

> If there are advantages of FIRS for consumers I'd certainly like to see 

One might be that FIRS client will be easy to write and client authors 
will find lots of goodies and features to the liking of the user. But I 
think the main advantages are more for the FIRS providers, since data 
management, replication scenarios, backup mechanisms, and above all 
distribution of data in a server mesh just are there and easily handable.

> 
> But realistically I take John Klensin's comments to heart that the 
> sooner we make a decision the better. There are Layer 9 issues here 
> (political aka ICANN) we have to deal with.

Yup. Layer 9 is quite unpredictable for a technician like me. But don't 
the political decisions more influence Layer 8 instead of the technical 
layers?

Just my 2 cent.

Cheers,

Peter

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 
_______________________________________________________________________

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: Mon Jul 28 13:29:31 2003

> to the server, and (3) use a server that supports the FIRS extensions.

This makes implementation and operational assumptions that are 
simplifications of how registries operate.  It also makes assumptions 
about the data models which I know are not true for domain registries 
and I suspect are even less true for address registries.

At some point I will try to put it all together in one place, but for 
now I can only point to the snippets:

> http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt

and appendix C of

> http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-03.txt

-andy

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Jul 28 13:39:50 2003

> concept to production service, but what makes you think this path is 

Speaking as somebody who has put together both types of systems (Pimmit 
- IRIS -00 and draft-newton-ldap-whois-03.txt*), I can tell you that 
LDAP offered no speed of implementation or ease of deployment advantages.

* draft-newton-ldap-whois-03 is not as far reaching as FIRS.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Jul 28 14:02:56 2003

> and I suspect are even less true for address registries.

I should have said 'minimal requirements', which is true. It is entirely
possible to go beyond that (voluntarily), but it is not necessary.

For example, the requirements document does not mandate a read-write
system, but only allows for it, and the minimal requirements support a
read-only service as mandated.

One step beyond the minimal requirements might be to generate LDIF
changelogs every 15 minutes or so, with the adds, updates and deletes
being applied more frequently. A far-edge usage could be made which put
LDAP at the center of the registration system (generating ~XML as output,
instead of using another database and generating LDIF as output). These
are all beyond the minimal requirements however.

>>http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt

This is an example of a voluntary system which goes further than the
minimal requirements, imo.

>>http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-03.txt

This seems to discuss some specific needs of large-scale operators, which
I think were included in the "uses FIRS extensions" sub-claim (which is
not just limited to search filters, but also includes things like query
limiters). Granted, there are going to be some deployment issues for some
registry operators, but nothing beyond the kind of issues that LDAP
servers already deal with frequently (eg, clustering and replication can
take care of most stuff, and isn't technically a full step beyond the
minimum requirements listed earlier).

As far as that goes, doing this work for LDAP is going to be cheaper than
doing this same necessary work in addition to all of the other glue
necessary for IRIS.

---

From: richard at shockey.us (Richard Shockey)
Date: Mon Jul 28 14:03:10 2003

>>>the same service.  In that case I'd say it is valid for the providers to 
>>>lean to the one that offers it more cheaply.  Because the cheaper one is 
>implementation will be cheaper than using existing technology and do some 
>tweaks to make it CRISP compliant?

Well as Andrew pointed out correctly, it seems obvious that a truly 
stunning number of , dare I say it, "e-business" practices are moving to a 
XML based architecture transported on FOO. The classic being SOAP may of us 
have lots of experience with SOAP.... that PROVREG is going to such a 
design that many TLD's will be contractually obligated ( Layer 9 again) to 
implement means that I have to build a service platform to support it ..If 
I can reuse that platform to implement CRISP, that is economically a "good 
thing"

>concept to production service, but what makes you think this path is 

I have no doubt it would be simple to implement FIRS ..is just that I dont 
want to .. that means 2 platforms I have to support and the registration 
data from PROVREG has to be converted...that is more work. When I have to 
propose capital budgets for platforms that do this and that the question is 
always raised ..." Well cant we reuse this box and development time for that?"

>scalable and secure as are LDAP implementations?

Yep... look at the APACHE SOAP stuff.. the bindings and transport are 
easily adaptable. We in the IETF are generally opposed to the use of HTTP/S
transport for everything under the sun which is why BEEP was developed. In 
fact the IESG has a directive specifically prohibiting the further use of 
HTTP as a transport layer in IETF application protocols. If the IETF 
weren't so opposed to SOAP on religious grounds we'd probably be using 
that. And if I had to choose I'd prefer SOAP but I'm realistic enough to 
know that is not going to happen.

>commercial  realm, does this make IRIS deployment really cheaper?

IMHO yes. Nails are cheep, Hammers are expensive :-)

>distribution of data in a server mesh just are there and easily handable.

maybe ... I remain unconvinced.

>>we make a decision the better. There are Layer 9 issues here (political 
>>aka ICANN) we have to deal with.
>
>the political decisions more influence Layer 8 instead of the technical layers?

alas yes .... but in this situation they cannot be ignored especially when 
the choice between IRIS and FIRS on purely protocol and service 
requirements are virtually indistinguishable.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Jul 28 14:12:05 2003

You mean that implementing a fully-scoped read-write system had the same
basic results in both cases.

I'm sticking to the story that the minimum requirements are lower for FIRS.

---

From: hardie at qualcomm.com ([email-masked])
Date: Mon Jul 28 14:31:55 2003

During the meeting in Vienna, we discussed a set of next steps for the protocol
evaluation, and the first of these was the development of a document that
described the "relay bag" work that would need to be done for LDAP to enable
FIRS.  Peter Gietz and Eric Hall have the pen(s) on that document.  I believe
having that document is a necessary step along the way to assessing which
of the two proposals will go forward as it speaks to complexity on the FIRS
side.  Having that work as early as possible will help all of us, and I'd like
to encourage the authors along those lines.

If people would like to discuss the extensibility of FIRS and IRIS in advance
of that document, the list is certainly open for that.  In general, though,
I'd appreciate folks being careful in tone--the group has had a collegial
approach to this problem space which has been very much appreciated.
Keeping that approach will help us achieve consensus; please resist
using terms and arguments which are derogatory to others.

I also believe that we have already achieved consensus that neither approach
allows us to use unmodified existing clients or servers.  In the IRIS case,
it is clear that the protocol is a new creation and will require appropriate
development of clients and servers (albeit using tools which are 
readily available).
In the FIRS case, it is clear that we are getting the heritage of 
LDAP as a protocol
(both for good and ill), but that development of modified clients and servers
(or schemas) appropriate to FIRS will also be required.  Arguing this point
does not seem to advance us along the road to resolution, since it has already
been agreed.

Thanks to all of you for your work and professionalism,
				regards,
					Ted Hardie

---

From: edlewis at arin.net (Edward Lewis)
Date: Wed Jul 30 22:28:27 2003

Regarding Ted's note - I do feel a bit guilty about making this 
thread seem antagonistic.  My intent is to fill in a huge blind spot 
(LDAP) in my knowledge.  Frankly I (and this is just my history) 
haven't seen anything come of LDAP in the many years I have know of 
it's existence.  (That would date back to at least 1995.)

This message is in the context of my being ignorant about LDAP's 
deployment.  I'm not saying the LDAP is garbage, I'm saying that I am 
unaware of it's advances.  Given that background I have a question 
and a comment to this.

At 20:42 -0500 7/25/03, Eric A. Hall wrote:
>It may be cheaper for
>delegation operators to reuse the provreg stuff ..., but for the average
>user the initial cost won't have already been underwritten.

I'm asking out of my pure ignorance.  Why would a client-side user 
want to integrate the responses from the CRISP protocol in a 
something that's built on LDAP?  I apologize that this may seem like 
an indictment, but I'm asking in the spirit of "I really can't 
imagine how/why."  (I'm not discounting that LDAP can do this, I just 
don't see why.)

>gone into LDAP,

I coming from a long term relationship with DNSSEC. (;()  There are 
quite a few RFCs on that subject, but to date it is not useable.  I 
don't think that the number of RFCs is a measure of anything quite 
frankly.  My point is that a lot of work has gone into LDAP and I 
know of the work, but I am ignorant of where LDAP is applied in spite 
of all the work.

(Much to the same extent of PKIX work - a lot of energy and still a 
lot of frustration in seeing it adopted.)

>convenience.

Granted - but the "favoritism" is the bias expressed by *A FEW* folks 
that are on the registry side of the game.  Perhaps I was a bit too 
definitive in making *my* statement in favor of IRIS (at this time, I 
should add), but I wanted to make it clear.  I anticipated one of two 
outcomes - either the FIRS proponents would lay down their pens and 
grant the title to IRIS (YES, I AM JOKING!) or FIRS proponents would 
let me know what I am missing about the FIRS advantages.

I have been known to be someone who switches sides in arguments of 
this (IRIS v FIRS) nature based on what I learn.  Right now I see 
advantages favoring IRIS but this may only be because I am stupid 
about FIRS or LDAP.  So, to this end I would appreciate hearing how 
FIRS is more extensible for the client (and/or server) side - not 
just that it is because of the LDAP legacy.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Jul 31 00:58:54 2003

on 7/30/2003 9:15 PM Edward Lewis wrote:

> thread seem antagonistic.

It isn't antagonistic; it's adversarial, as it should be. Let's not be
afraid to question each other's assumptions.

For the record, FIRS would not be on the table without the support and
effort of Andy Newton and Mark Kosters in particular.

> something that's built on LDAP?

I'm actually thinking about more than that, where users would not limit
themselves to reusing the data but would want to provide their own CRISP
servers, services and data. I'll get back to this in a moment, but let me
diverge first.

CRISP is about providing a directory service, by definition and by
operational character. It's a read-mostly distributed database service,
providing lookup-by-name and search-by-value functions, structured answer
sets, and so forth. WHOIS was intended as a directory, the IRIS specs use
the term freely, and LDAP is what it is, so by every interpretation we're
building a directory service of Internet resources, regardless of how
comfortable anybody actually is with that. We've avoided focusing on this
point and that was a good thing, imo, since we've also avoided a lot of
undesirable participants, but we're at the point where we need to realize
what it means and deal with it.

The central issue is scope. Do we just want it to be a WHOIS replacement
for the same providers, or do we want to want to encourage broad and deep
usage within the Internet community. In my opinion, the latter is
unavoidable in the absence of purposeful design limitations being
architected into the system, which is something we probably aren't going
to do. This leads to the conclusion that failing to encourage the
inevitable is a fundamental error, since we're only going to be
guaranteeing eventual frustration.

As proof of this point -- and to answer your question -- look at how WHOIS
data is already being used today, for starters. Anti-spam tools, network
management tools, logfile analyzers, and a slew of other products are
already tapping into WHOIS data even in it's brutal current form. We can
guarantee that this same level of usage willl be picked up for the new
system, at the very least. What's even more likely is that the technology
will get pulled into a bunch more products, either along similar lines or
by extending other tools. I mean, it's not that hard to imagine that
traceroute programs are going to start using the baseline data, or that
(God help us) automated complaint generators are going to use it, etc.

What will follow is also fairly predictable, since it also happened with
WHOIS, which is that people will want to start building layered services
on top of the baseline data. We saw this not only with the long-ago
expansion into data for non-human resources, but also with the more-recent
expansion into RPSL. It seems obvious to me that once people discover a
federated namespace with ACLs, structured queries and answers, and all,
that this expansion will accelerate, with people wanting to provide all
kinds of resources.

For an idea of the kinds of data that I'm talking about, think about the
types of data that have been proposed for DNS but which are rejected due
to incompatibilies or concerns with DNS. Certificate stores, public keys
for applications and services, whitelists, email filters, personal contact
data, etc. There is already a demonstrated desire for this stuff but
nowhere to put it, and what we are providing is indistinguishable from a
perfect place to put it (unless it is designed not to, as mentioned). For
years we've been telling people "use something else" and by golly, this
*is* that something else. The fact that the initial database will be
populated with the most useful resources -- domains, IP addressing blocks,
and contacts -- is going to be bacon on the bait.

This is why I'm saying that the registry data is just a part of the big
picture. It's arguably the most important part of the picture, but in the
end I don't think it will represent the majority of the data in the total
system. And since I think this balance is unavoidable, I think we should
be focusing on making sure it goes well.

> know of the work, but I am ignorant of where LDAP is applied in spite 

I agree with this indictment, but I don't think there is much in the LDAP
RFC series that equates with that. Most of the specifications are schema
definitions and protocol extensions, and is used to illustrate the point
that this same level of crack-filling will also be necessary.

> lot of frustration in seeing it adopted.)

Nowhere to put it. Yet.

What's been missing is the mesh of servers. Once the domain and IP
addressing delegation data goes into CRISP, these problems will at least
be partially resolved (depending on the degree that the providers
recognize that they are already in the directory business and begin
offering the layered data as a value-add to their customers, or if it gets
left to third-party providers to plug in as layered services).

> just that it is because of the LDAP legacy.

The candidates are relatively equal as far as the technology parts go,
Andy and I already privately agreed to that.

The advantage to FIRS is in time-to-deployment, especially as you get
towards the edge of the service. LDAP servers are bundled into Win2k,
Solaris, Linux, NetWare, and several other common operating systems. LDAP
clients are already provided with authentication systems, email clients,
web engines (eg, PHP and ColdFusion), and bundled as libraries for most
development languages. The LDAP technology already provides integated
database, protocol, authentication, and ACL technologies. The service is
understood and supported by a large number of vendors, and is provent to
be extremely scalable. Simply put, if I want to write a client agent that
does CRISP lookups (or does some layered service lookup) then FIRS is
easier. Likewise, if I want to provide a new layered service as a
leaf-node in the Internet directory, then FIRS is easier there too, and
has the known properties of scalability, reliability and support.

---

From: April.Marine at nominum.com (April Marine)
Date: Thu Jul 31 18:07:30 2003

Hello,

On Wed, 30 Jul 2003, Eric A. Hall wrote:
> ...
> ...

The possible potential use of the protocol chosen by CRISP is an
interesting topic, but not one that determines which protocol the group
chooses.  The requirements for the protocol and the usage scenarios which
it is required to address are documented and these form the bounds of how
we proceed.  So I agree with you that scope is an issue, but think we have
to limit ourselves to the scope of the WG's charter, which was
deliberately focused.

As Ted said in his last msg:

 > During the meeting in Vienna, we discussed a set of next steps for the
 > protocol evaluation, and the first of these was the development of a
 > document that described the "relay bag" work that would need to be done
 > for LDAP to enable FIRS.  Peter Gietz and Eric Hall have the pen(s) on
 > that document.  I believe having that document is a necessary step
 > along the way to assessing which of the two proposals will go forward
 > as it speaks to complexity on the FIRS side.  Having that work as early
 > as possible will help all of us, and I'd like to encourage the authors
 > along those lines.

So let me be the stern co-chair and encourage us to get the possibly
mundane but necessary work done so that we can come to closure in good
time.

thanks,
April

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Thu Jul 31 18:17:37 2003

Richard,

some comments to your comments:

Richard Shockey wrote:

[...]
>>> One way or another implementing these protocols will cost money and 
>>> my analysis concludes that IRIS will be simpler and less expensive.
>>
>>
> stunning number of , dare I say it, "e-business" practices are moving to 
> a XML based architecture transported on FOO. The classic being SOAP may 
> of us have lots of experience with SOAP.... that PROVREG is going to 
> such a design that many TLD's will be contractually obligated ( Layer 9 
> again) to implement means that I have to build a service platform to 
> support it ..If I can reuse that platform to implement CRISP, that is 
> economically a "good thing"

Well I can see a point here. It made me think of an LDAP based 
implementation of it with an XML-interface. This would be possible, but 
would only make a proof that LDAP could have been used for provreg as 
well. It is far too late for such work now.

> 
> 
>> Alone the fact that Eric could perl a FIRS client in one week prooves 
>> ho cheap it can be to deploy FIRS. I know it is a long way from proof 
>> of concept to production service, but what makes you think this path 
>> is shorter with XML?
> 
> 
> I have no doubt it would be simple to implement FIRS ..is just that I 
> dont want to .. that means 2 platforms I have to support and the 
> registration data from PROVREG has to be converted...that is more work. 
> When I have to propose capital budgets for platforms that do this and 
> that the question is always raised ..." Well cant we reuse this box and 
> development time for that?"
> 
BTW: CRISP and Provreg do differ in many respects. I am not too sure 
that much reuse is possible.

> transport for everything under the sun which is why BEEP was developed. 
> In fact the IESG has a directive specifically prohibiting the further 
> use of HTTP as a transport layer in IETF application protocols. If the 
> IETF weren't so opposed to SOAP on religious grounds we'd probably be 
> using that. And if I had to choose I'd prefer SOAP but I'm realistic 
> enough to know that is not going to happen.

I think there are more than religious grounds to dislike SOAP, the major 
being that tunneling everything through port 80 just makes firewalls 
useless. Anyway IMO SOAP is a good thing (an old concept called RPC 
transformed into the new XML world), the usecases of it (Web Services) 
is just no IETF realm.

BEEP is nice as well, but I haven't seen that really hit the market yet.

Anyway, SOAP will not be it in IETF and the XML DB implementation in 
Apache Xindice is not comparable in its features with LDAP 
implementation. If you, e.g., look at XML:DB XUpdate, the protocol for 
making changes into the database you will find nothing about 
authentication, authorization, access control, etc. and neither do you 
find that in the Apache implementation. As to performance, I myself 
haven't made any XMLDB tests. I am aware of some XMLDB/LDAPDB 
performance testings done in the frame Grid computing by the globus 
toolkit team. That showed how slow XML databases are these days, which 
nevertheless didn't prevent them going the Web Services path (OGSA). The 
motivation might be: If the whole market is going this way, there will 
be fast implementations some day.

Anyway, there are good arguments for XML just as there are for LDAP. For 
the present, I would say that the latter can fulfill its promisses now, 
while most of needed features in XML are rather vapor ware than existing 
in implementations.

Cheers,

Peter

Peter Gietz (CEO)