Subject: [Ietf-not43] oss implementation release

From: [email-masked] (Andrew Newton)
Date: Tue, 29 Oct 2002 16:14:58 -0800

A few weeks back, I sent out a list of issues we had noted with the IRIS 
-00 drafts, most of which were discovered through the time-honored 
process of trying to implement the spec.

Here's the email from the archives:
http://lists.verisignlabs.com/pipermail/ietf-not43/2002-October/000267.html

After a bit of code clean-up and documentation, we are making this 
software available under an open source license.  It may be found here:
http://iris.verisignlabs.com/

Comments and observations with respect to the drafts are welcome.

-andy

---

From: [email-masked] (Rick Wesson)
Date: Tue, 29 Oct 2002 16:45:40 -0800 (PST)

andy,

can you comment on distributed quering and how the resolution of searched
for contacts works.

I realized that searching will require alot of processing on nodes with
few domains and i just didn't understand from your requirements how this
can be avoided.

thanks,

-rick

On Tue, 29 Oct 2002, Andrew Newton wrote:

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

---

From: [email-masked] (Andrew Newton)
Date: Tue, 29 Oct 2002 19:49:02 -0800

Yoah!  Is this a context switch to the requirements?

Query distribution is just giving the client a list of places to go 
search.  As for processing requirements, they shouldn't be any greather 
than they are today.  In fact, by structuring the queries, processing 
may be reduced by limiting the number of indexes that must be consulted.

-andy

---

From: [email-masked] (Rick Wesson)
Date: Tue, 29 Oct 2002 18:08:08 -0800 (PST)

> may be reduced by limiting the number of indexes that must be consulted.

my question is if the query for a contact must be distributed to all
servers then some servers with few registrations/contacts will be doing
alot of processing to respond with a negative result.

I feel that queries for contacts will be a burdon on the servers with few
contacts. When we have requirements that require all participiants to
provision equal bandwith and cpu for processing even when they know they
will rarely have a positive result to return.

We need to discuss the requirement on support of searches for objects that
require the client to query every participating server where no
authortaive index exists.

-rick

---

From: [email-masked] (Andrew Newton)
Date: Tue, 29 Oct 2002 20:21:46 -0800

> authortaive index exists.

Ok.  I understand the concern now.

The requirement is that the protocol be capable of distributing queries. 
  Which service operators participate in the query distribution is a 
matter of policy.

In addition, there is nothing preventing additional measures where 
queries are distributed in a more intelligent manner vs. a shotgun 
approach (i.e. index hints).

-andy

---

From: [email-masked] (Leslie Daigle)
Date: Tue, 29 Oct 2002 22:52:29 -0500

I think there is some confusion because you replied to
the message re. iris implementation with a question that
is about (service) requirements.

So the IRIS protocol doesn't do query distribution; it
should (does) have mechanisms that will allow IRIS servers
to play in a network of servers that provides the overall
*service* (entity references, search continuations).

The ldap-whois proposal includes detail about how to find
the authoritative server for a given lookup (e.g., domain
name).  That is also not in the IRIS protocol definition.
But, it would be possible (and, to my way of thinking,
necessary?) to define how IRIS leaf servers can be
coordinated into such a federation.  But that is out of
band of the IRIS protocol. As is the "how to do query
routing" answer.

Leslie.

-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
   -- ThinkingCat  (c.1983 - 2002)

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked] (Ted Hardie)
Date: Wed, 30 Oct 2002 09:49:57 -0800 (PST)

> approach (i.e. index hints).

I'm a little uneasy with this answer.  If we say the service
operator's participation in the query distribution is a matter of
policy, but the protocol must be capable of distributing queries, I
think we run the risk of saying servers must know the policies of
other servers to whom they distribute queries.

It seems to me that we could say something more like the follow:

 The protocol must be capable of distributing queries among the
 participants in an established mesh of CRISP service operators.  It is
 not a requirement that the CRISP protocol enable the discovery of
 service operators, but the CRISP protocol should be able to
 intelligently handle distribution within its established mesh.
 Individual service operators will respond to all queries received
 according to their policies for authentication, privacy, and
 performance.

To put this another way, I think a service operator participating in
a mesh should be able to provide a referral, but I don't think it
should be responsible for knowing whether the server to which
it refers you will answer _you_ or will answer _at_this_time.
I understand, of course, that the policies for authentication,
privacy, etc. may require a server to refuse to respond without
making clear exactly why it refused, but I consider the refusal
to respond participation (and I expect the protocol will need
response codes appropriate for such refusals).

Lame example:

Rick, Leslie, and I are part of a CRISP service mesh of operators.
Andy asks me for info on domain "example.tld"; I have no info on this
domain, as I am not a registrar or registry for .tld.  I do have
internal configuration parameters that indicate Leslie is a registrar
for .tld and I give a referral to Leslie.  Leslie is not the registrar
for example.tld, but, as a registrar for .tld, she knows that Rick is
the registrar for example.tld and gives a referral to Rick.  Andy asks
Rick for info on example.tld; the answer he gets will depend on the
policy of Rick's service for queries received with the credentials
supplied by Andy.  If Andy supplies no credentials, Rick's service may
reply something like: I do know, but I won't tell you (. | until you
provide me with credentials | until my load is lower )

					Ted

---

From: [email-masked] (Andrew Newton)
Date: Wed, 30 Oct 2002 12:10:36 -0800

> other servers to whom they distribute queries.

I don't agree with this sequence of logic, but...

>  according to their policies for authentication, privacy, and

...I do agree with this language.

-andy

---

From: [email-masked] (Leslie Daigle)
Date: Wed, 30 Oct 2002 14:18:24 -0500

I agree with Andy... on both points.

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: [email-masked] (Leslie Daigle)
Date: Wed, 30 Oct 2002 14:26:51 -0500

FWIW, I don't personally think that a global whois-like
service would be successful with such an apparently ad hoc
regime of referrals (cf your example below).  

To have a useful *service*, I think there would have to
be thought-out, standard conventions for how to generate
referrals, and/or do query distribution.

What I was attempting to say earlier was that I don't
think this is a protocol thing.

It's not entirely clear to me if it would be part of this WG.

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: [email-masked] (Ted Hardie)
Date: Wed, 30 Oct 2002 11:00:40 -0800 (PST)

> regime of referrals (cf your example below).  

Hey, there's a reason I said "lame example".  I don't intend
in the example to describe a thought-out,standard convention
for how to generate referrals; just clarify any mudiness
in my language on the "policy" problem statement. 

> It's not entirely clear to me if it would be part of this WG.

It is currently in the requirements, section 4.2. and 4.3:

4.2 Referrals

   To distribute queries for search continuations and to issue entity
   references, the service MUST provide a referral mechanism.

4.3 Common Referral Mechanism

   To distribute queries for search continuation and to issue entity
   refences, the service MUST define a common referral scheme and
   syntax.

I assume that defining a common referral scheme and syntax is part of
the protocol work on our plate.  Are you proposing we strike these
requirements?

---

From: [email-masked] (Andrew Newton)
Date: Wed, 30 Oct 2002 13:12:50 -0800

> the protocol work on our plate.  Are you proposing we strike these

The intent of this requirement is that the set of ways to talk about 
referrals should not be unbounded.

It could be argued that 4.2 and 4.3 say the same thing.

-andy

---

From: [email-masked] (Leslie Daigle)
Date: Wed, 30 Oct 2002 15:15:35 -0500

I'm not proposing anything -- I am making an observation
on the state of my own thinking, and attempting to elaborate
it in sufficiently detail so that others might decide whether
they agree or disagree.

Specific comment below:

> the protocol work on our plate.  Are you proposing we strike these

Any protocol that meets the requirements must have the
ability to support some form of a common referral scheme and
syntax.

At issue is the *semantics*.  When does a server generate
a referral?

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: [email-masked] (Ted Hardie)
Date: Wed, 30 Oct 2002 11:46:18 -0800 (PST)

Leslie writes
> >Ted writes:

The question of when a server generates a referral is not what I would
normally call semantics, but I think I see your point.  Let me stretch
it a bit:

1) When *may* a server generate a referral?

2) When *must* a server generate a referral?

3) When *must* a server *not* generate a referral?

My quick view of the answers:

1) Any time it is not an authoritative source 
   for the information requested and it knows
   of other CRISP servers.  (Better if it knows
   something about what they know, of course,
   and the more it knows the better it is).

2) Never.  It should always be possible to configure a server
   to act as a standalone server.

3) When it is an authoritative source for the the
   information.

Of course, the interesting question is "When *should* a server generate
a referral?", but the answer is a boring "it depends" (on the service
mesh(es) the server participates in).

None of this seems to me to change the requirement to specify
a mechanism for referrals when they occur.

					Ted