Subject: [Ietf-not43] -02 requirements draft

From: [email-masked] (Ted Hardie)
Date: Tue, 5 Nov 2002 10:02:21 -0800 (PST)

Hello Folks,
	Andy has sent in a -02 version of the requirements draft to
address the wordsmithing issues brought up during last call.  I
believe that none of those changes were substantive, so I plan to send
it up to the IESG as a candidate for Informational RFC.  If you
believe that the changes require further discussion on the list,
please let me (and the list) know as soon as possible.
			regards,
				Ted Hardie

---

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 15:28:30 -0800 (PST)

I still have a major problem with 3.2.3 Domain Registrant Search. I can't
see how searching is going to be distributed in a fair and equitable way
and ould like the requirement removed until we have some discussion that
shows that there is a technicaly feasable way of doing this.

If noone can stand up and show how everyone in the mesh isn't effected by
every registrant search then we either need to drop the requirement or
have a way to recover costs of preforming these queries.

-rick

On Tue, 5 Nov 2002, Ted Hardie wrote:

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

---

From: [email-masked] (Ted Hardie)
Date: Tue, 5 Nov 2002 16:38:56 -0800 (PST)

Rick,
	I understand your concern.  We need to be careful, though,
that we deal with concerns about the requirements in the requirements,
rather than by demonstrating that one or another candidate solution
doesn't have a particular problem.  To avoid this, I'd rather not go
with a "show how this works" resolution to your concern.
	Would you be willing to work with Andy on language for 3.2.3,
that includes something related to the question of equity that you
raise?  That allows the working group to decide if there is general
agreement on the amended requirement, whether it should stay as is,
or be wholly removed.  
			regards,
				Ted Hardie

---

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 16:49:34 -0800 (PST)

My concern that is that requirements such as "turn carbon into gold" are
not valid unless there is some real capability out there that can preform
such feats. I believe that unless somone can demonstrate how this can be
accomplished the requirement is absurd and should be removed.

-rick

---

From: [email-masked] (Andrew Newton)
Date: Tue, 5 Nov 2002 21:24:39 -0500

So...
 1) You raise an issue.
 2) Conversation takes place
 3) Language is agreed upon
 4) You never objected to it

Given that you seem to be unwilling to work with us, then perhaps you should 
explain why it will not work.  And allegations of absurdity and allusions to 
black magic are generalizations.

-andy

On Tuesday 05 November 2002 07:49 pm, Rick Wesson wrote:
> > > I still have a major problem with 3.2.3 Domain Registrant Search. I
> > > can't see how searching is going to be distributed in a fair and
> > > equitable way and ould like the requirement removed until we have some
> > > discussion that shows that there is a technicaly feasable way of doing
> > > this.
> > >
> > > If noone can stand up and show how everyone in the mesh isn't effected
> > > by every registrant search then we either need to drop the requirement
> > > or have a way to recover costs of preforming these queries.
> > >
> > > -rick
> > >
> > > > believe that none of those changes were substantive, so I plan to
> > > > send it up to the IESG as a candidate for Informational RFC.  If you

---

From: [email-masked] (Ted Hardie)
Date: Tue, 5 Nov 2002 17:44:19 -0800 (PST)

Rick,
	This is not a "turn carbon into gold" requirement.  As the
language notes, it is expressly limited by 3.2.8 to permit truncated
results, which can be construed to avoid the extreme requirement you
stated.  Even if it were not so limited, as you pointed out earlier,
the trivial implementation of 3.2.3 _as stated_ is to distribute every
query for registrants to every known server.  This would, obviously,
be bad protocol design, but it does meet the requirement.  There have
been a number of systems built (by which I mean both implemented and
deployed) that did a far better job of query routing.  I can, for
example, see using something like CIP (RFC2651) to provide forward
knowledge of indexed items like registrants to servers participating
in a mesh.
	This would not be free, and it might or might not be worth it,
but it is certainly easier than turning carbon into gold.  As I said
before, however, I do not think the right way to solve a problem in
the requirements is to architect a system to prove that it is
possible.  I'd rather attack problems in the requirements by fixing
the requirements.
	Your previously expressed problem was "I can't see how
searching is going to be distributed in a fair and equitable way".
Amending 3.2.3 so that it constrains query distribution to capture
some version of that problem statement may be useful.  If you are
willing to work with Andy on replacement language for 3.2.3 to capture
that, I believe we get the best outcome--as then the working group can
decide if the requirement should go forward in an amended form, be
left alone as an issue which may depend too much on deployment to be
standardized, or which should be wholly dropped.
			regards,
				Ted Hardie

---

From: [email-masked] (Ted Hardie)
Date: Tue, 5 Nov 2002 17:52:56 -0800 (PST)

Andy,
	Rick has raised an objection to the language, after having
raised an issue.  Please do not assume that the timing of this
discussion indicates an unwillingness to work on the problem.  I
believe we need to move forward by finding language that the working
groups agrees meets the service need implied by 3.2.3 and the service
provider concern which Rick has expressed.
			regards,
				Ted Hardie

> Given that you seem to be unwilling to work with us, then perhaps you sho> uld 
> explain why it will not work.  And allegations of absurdity and allusions>  to 
> > My concern that is that requirements such as "turn carbon into gold" ar> e
> > not valid unless there is some real capability out there that can prefo> rm
> > such feats. I believe that unless somone can demonstrate how this can b> e
> > > that we deal with concerns about the requirements in the requirements> ,
> > > > equitable way and ould like the requirement removed until we have s> ome
> > > > discussion that shows that there is a technicaly feasable way of do> ing
> > > > this.
> > > >
> > > > If noone can stand up and show how everyone in the mesh isn't effec> ted
> > > > by every registrant search then we either need to drop the requirem> ent
> > > > > send it up to the IESG as a candidate for Informational RFC.  If > you

---

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 18:08:58 -0800 (PST)

>  4) You never objected to it

I've objected several times, in person and on the list.

> black magic are generalizations.

ok, for all participitants in the mesh to answer a query of "show me all
the domains owned by john smith" all participiants must answer for a
complete result set at the client. My problem with this query isn't the
size of the result set is that ALL participitants must participate.

If there are 150 nodes in the mesh all 150 must answer. If 10 of the 150
node have 90% of all the domains 140 nodes answer negatively 90% of the
time. thus you have the burdon of the largest nodes imposed on the
smallest (in size of registrations)

This appears to be a big problem for small participitants in the mesh as
they will require significant bandwith and cpu just to answer negatively
for 90% of all queries they recieve.

90% of the participitants answering negatively 90% of the time is not an
acceptable solution for me. now if somone can show me how this isn't the
case for "3.2.3 Domain Registrant Search" I'll shut up.

-rick

---

From: [email-masked] (Jim Fleming)
Date: Tue, 5 Nov 2002 19:53:44 -0600

Where are all of the business people in these discussions about "cost recovery" and "turning carbon into gold" ?
Can people start with explaining what it really costs per year to run a Registry split over a few companies ?

----- Original Message ----- 
From: "Andrew Newton" <[email-masked]>
To: "Rick Wesson" <[email-masked]>; "Ted Hardie" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 05, 2002 8:24 PM
Subject: Re: [Ietf-not43] -02 requirements draft

So...
 1) You raise an issue.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Tue, 5 Nov 2002 22:28:10 -0500

> I've objected several times, in person and on the list.

In person?

> 90% of the participitants answering negatively 90% of the time is not a=
n
> acceptable solution for me. now if somone can show me how this isn't th=
e
> case for "3.2.3 Domain Registrant Search" I'll shut up.

http://lists.verisignlabs.com/pipermail/ietf-not43/2002-October/000287.ht=
ml
and
http://lists.verisignlabs.com/pipermail/ietf-not43/2002-October/000288.ht=
ml

-andy

---

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 18:33:28 -0800 (PST)

> > I've objected several times, in person and on the list.

scott hollenbeck's notes from the registrars constituency meeting in
shanghai china where he presented on crisp and requested comments.

> > case for "3.2.3 Domain Registrant Search" I'll shut up.

neither of the notes below address my concern. if we are going retain
3.2.3 we MUST address how the queries are distributed for such a search or
any requirements on the members of the mesh to provide index hints.

not addressing this stuff is a non-starter with the audience you are
designing these protocols for.

-rick

> http://lists.verisignlabs.com/pipermail/ietf-not43/2002-October/000287.html
> and
> http://lists.verisignlabs.com/pipermail/ietf-not43/2002-October/000288.html
>
> -andy
>

---

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 18:35:13 -0800 (PST)

Ted,

[snip]

> knowledge of indexed items like registrants to servers participating

I've considered CIP but then we would need a requirement that all members
of the mesh provide distilled indexes to a root node, I seriously doubt
we will be creating any new roots or that the members of the mesh are
willing to distill CIP like indexes and provide them to anyone. Maybe for
a fee but then we are way out of scope for our charter...

> standardized, or which should be wholly dropped.

My request stands at "please remove the requirement" as no one has even
attempted to discuss how searching can be distributed in a fair and
equitable way. changing the language in 3.2.3 is like requesting we
exchange silver for gold in my last analogy it still doesn't address the
fact that its not going to be fair for the vast majority of the members of
the mesh.

unfair protocols don't get deployed.

-rick

---

From: [email-masked] (Jim Fleming)
Date: Tue, 5 Nov 2002 20:31:15 -0600

"If there are 150 nodes in the mesh all 150 must answer." ??
===

It seems unlikely that there would be 150 companies cooperating the build "the Registry".
.COM has 4 companies that cover 100% of the market.

Average wholesale cost...$7.735
======= Example 4 RegisTRA Model =======
http://www.cashbackalliance.com/domain/domainsfor619.aspx
$6.19
http://www.wildwestdomains.com/pricelist.asp
$6.75
http://www.srsplus.com/en-def-5d142899df19/en/srsplus/partners_pricing.shtml
$8.00
http://resellers.tucows.com/opensrs/
$10.00
======================================================

The hierarchy is....

Reseller (Registrar)
RegisTRA
Registry

A RegisTRA does not compete with a Reseller...
...and Resellers can look like Registrars...

---

From: [email-masked] (Andrew Newton)
Date: Wed, 6 Nov 2002 00:30:04 -0500

> of the mesh provide distilled indexes to a root node, I seriously doubt

Why would we need a new requirement?  As stated in a previous thread, that is 
out-of-band.

> fact that its not going to be fair for the vast majority of the members of

I disagree.  Ted just pointed out one way.  And another was pointed out in the 
aforementioned thread.

Plus, I agree with Ted's concern about addressing the requirements.

-andy

---

From: [email-masked] (Ted Hardie)
Date: Tue, 5 Nov 2002 20:58:17 -0800 (PST)

Rick,
	Thanks for your message.  Comments in line.

> a fee but then we are way out of scope for our charter...

	This is why I do not want to have the design discussion at the
requirements phase.  Not only does the use of something like CIP not
require a root node, there is no way to predict the cost of distilling
or distributing CIP-like indexes until we are much further along the
protocol design.  I cited CIP, in any case, not because I think it is
that good a fit, but because it is an existence proof of systems which
provide forward knowledge to improve query routing.  One way of
handling your stated objection is to have query routing ensure that
queries go only to "likely" nodes, for some value of likely.

	All of this, however, is at the wrong stage of the discussion.
The document before is a requirements document.  The current
discussion is a requirements discussion.  The requirement provides
functionality: "Tell me all the domains administered by Example DNS
/Tell me all the domains owned by Joe Example".  There are
clear reasons to want this functionality.

	You are asking the working group to trade this functionality
for something else.  I can characterize this "something else"
as a service provider equity issue.  To make a reasonable engineering
decision about the trade-off, though, we need to have language
either modifying the existing language or as a separate requirement.
(3.2.3 currently cites 3.2.8 as a limitation and it is also limited
by the normal requirements for authentication etc.; a new requirement
embodying the "service provider equity" issue could be cited in
the same way).

> fact that its not going to be fair for the vast majority of the members of

	No, changing the language in 3.2.3 could include anything from
saying that the protocol MUST provide this facility to servers which
voluntarily choose to participate (which eliminates the equity issue)
to saying that service providers MAY provide this facility if
participating servers deem the resources available or well spent.  It
may also choose to cite a service provider equity requirement
described elsewhere in the document.  The metaphor of carbon into
precious metal simply does not apply here.

> unfair protocols don't get deployed.

	Unwritten language doesn't get included in specifications.
Since you have not argued against the functionality in 3.2.3, but
asked the working group to trade that functionality against another
requirement, I believe we need to have language for that requirement
or language indicating the appropriate effect of that requirement
on this one.   If you are adamant about not supplying that language,
I will call for other volunteers.
			regards,
				Ted Hardie

---

From: [email-masked] (Bret Fausett)
Date: Tue, 05 Nov 2002 21:09:06 -0800

Ted Hardie wrote:
> The requirement provides functionality: "Tell me all the domains administered
> by Example DNS /Tell me all the domains owned by Joe Example".  There are

Would you mind describing why one might want this functionality?

    -- Bret

---

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 22:20:02 -0800 (PST)

Ted,

> clear reasons to want this functionality.

no, I've asked for the requirement to be removed. only you and the draft
author have said no. There has been almost no discussion on this list on
or about the points in the requirements draft. I am stating that these
requirements are not fully baked and are not nearly cooked enough for
passing them off to the IESG.

none of the other requirements have conditions that require all members of
the mesh to participate in a query. this type of query does deserve
special attention because of the negative impact it could bring to those
who provide crip resolution service.

for these reasons I request that 3.2.3 be removed as a requirement,
otherwise please enumerate the clear reasons you have eluded to for
retaining this functionality.

-rick

---

From: [email-masked] (Peter Gietz)
Date: Wed, 06 Nov 2002 13:28:12 +0100

Hi,

I would like to second Ted in this thread. The Domain Registrant Search=20
is doable by means of an indexing system.
We in an European working Group on Directory deployment (TERENA Task=20
Forc LDAP Service Deployment, http://www.terena.nl/task-forces/tf-lsd)=20
have gained some experience with LDAP and CIP. The single service manager=

wouldn't even have to provide an index object, but could also allow its=20
service to be crawled by a known, registered and
authenticated crawler that can produce such an index object. So its=20
either delivering the index objects yourself or let a trusted
crawler do that job. And: yes there has to be someone who is willing to=20
maintain the index service.

I also second Ted in another respect: requirements documents should not=20
too much be concerned with the architecture that fullfills the specified =

requirements. It is more something like "what to we want, what do we=20
need" and it is the problem of the authors of the architecture documents =

to specify the architecture accordingly.

A distributed architecture with one or more central index services (in=20
analogy to www and google)  is in any case a good choice, which provides =

flexibility, scalability, and reliability (by redundancy).  I am happy=20
to contribute to the LDAP documents to include such an architecture.

Cheers,

Peter

Rick Wesson wrote:

> =20
>>   =20
>no, I've asked for the requirement to be removed. only you and the draft=

>author have said no. There has been almost no discussion on this list on=

>none of the other requirements have conditions that require all members =
of
>special attention because of the negative impact it could bring to those=

> =20

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

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 06 Nov 2002 13:40:05 -0600

> size of the result set is that ALL participitants must participate.

I'm not sure what the complaint is but let me deal with this issue in
particular, specifically as it applies to LDAP-WHOIS model. Essentially
there are two ways of dealing with this specific query type there:

  1) use a catalog server and ask for all of the inetDnsDomain
     entries with an email address of [email-masked] in one
     of the contact attributes.

  2) ask the server responsible for example.org for all of the
     inetRelatedDnsDomain attributes that are linked to the
     queried email address.

Both of these mechanisms are voluntary. Distributed deployment essentially
requires voluntary participation, ESPECIALLY since the management of each
server will vary. Even if there was a way to provide hard links between
these attributes (and there are), there is no way to ensure that the data
is accurate (intentionally or otherwise).

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

---

From: [email-masked] (Ted Hardie)
Date: Wed, 6 Nov 2002 13:48:22 -0800 (PST)

> passing them off to the IESG.

Well, there is clearly now discussion the list about the requirements
and it is clear that others have opinions to add to the mix; if
you were worried you were talking to only Andy or me, you can stop
:).

As you may have seen in my comment on Next Steps, I believe the
current set of discussions will require a new draft of the
requirements document, which should go through working group last
call.  This document, in other words, will not go to the IESG.

> who provide crip resolution service.

Your belief about the negative impact is now well documented, but
given the requirements in 3.1.11 for generalized query distribution
and the restrictions currently in place or in discussion 3.2.3, there
still seems to me some fundamental assumption behind this that has not
been captured.  I continue to urge you to send text on this
requirement so it can be evaluated in the full context of the
requiremetns.

> retaining this functionality.

There are clear reasons for wanting it in both IPR and law enforcement
contexts (these would, of course, be subject to the authorization
requirements already in place).  I have also seen a case where a
contractor working on behalf of small businesses had used his own data
for domain ownership to shortcut the existing system; when his
business went under, exactly this kind of search was necessary.  While
this is a far more unusual case (and largely related to a "wrong"
registration in the first place) than would be law enforcement, it can
and does happen.
			regards,
				Ted Hardie