Subject: [Ietf-not43] Settlements

From: [email-masked] (Rick Wesson)
Date: Wed, 6 Nov 2002 10:16:56 -0800 (PST)

Please add the following section as 3.2.11

3.2.11 Query Settlements

Any search mechanism used to distribute a query to all applicable domain
registries and registrars for Nameserver Search (3.2.5) or Domain
Registrant Search (3.2.3) MUST contain provisions for cost recovery
through a settelments mechanism.

thanks,

-rick

---

From: [email-masked] (Ted Hardie)
Date: Wed, 6 Nov 2002 14:05:38 -0800 (PST)

Given your previous comments, I can only assume this irony.  Clearly
out of scope, but thanks for the light-hearted approach.

			regards,
				Ted Hardie

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

---

From: [email-masked] (Rick Wesson)
Date: Wed, 6 Nov 2002 14:54:43 -0800 (PST)

umm, its not irony, nor is it a joke. it was suggested as feedback in the
presentation scott gave to the registrars in shanghai.

how could it be out of scope?

-rick

---

From: [email-masked] (Jim Fleming)
Date: Wed, 6 Nov 2002 17:01:58 -0600

http://www.dnso.org/clubpublic/registrars/Arc01/msg03530.html

From: Neuman, Jeff [mailto:[email-masked]]
Here are the comments I have received thus far from the Registry Constituency.

8)e)vi) - How would fees be collected?  It would create a collection problem for ICANN. Registrars paying registrars directly
wouldn't work.

===================================

---

From: [email-masked] (Ted Hardie)
Date: Wed, 6 Nov 2002 16:35:05 -0800 (PST)

> how could it be out of scope?

Since this was a major extension attached to something you
were arguing we didn't need (and to a MAY-only requirement), 
I misread your comment as ironic.  Sorry for my confusion.

Your message seemed to indicate that you expected the settlement to be
between service providers, rather than between a service provider and
the service users.  As an interprovider policy issue, it is out of
scope for CRISP.

As a practical matter, there are some referral mechanisms for which
such a settlement mechanism would not make sense.  If a user asks a
question like "What are all the domains administered by Joe Example?"
and gets back "None here, but you might check with ServiceFoo,
ServiceBar, and ServiceBaz", the actual query distribution is done by
the client's choice to ask each of the Service* listed.

Or have I wholly missed your point, and you are arguing we need a
way for CRISP to support payment between the requestor of administrative
information and the supplier of that information?  

			regards,
				Ted Hardie

---

From: [email-masked] (Rick Wesson)
Date: Thu, 7 Nov 2002 17:21:24 -0800 (PST)

Ted... comments in line.

> I misread your comment as ironic.  Sorry for my confusion.

the refrence to 3.2.3 is not a MAY-only requirement

> the service users.  As an interprovider policy issue, it is out of

the requirements was general and not specific to interprovider thus I
believe as long as we have requirements for general searching where result
sets require agragation we must consider a settelments mechanism.

> the client's choice to ask each of the Service* listed.

you seem to be develing into implementations as you have reminded me all
to often not to do.

> information and the supplier of that information?

only for certian types of queries.

---

From: [email-masked] (Andrew Newton)
Date: Thu, 7 Nov 2002 21:51:08 -0500

Rick,

Are you suggesting that we have semantics like "debit my account $6.21" in an 
access protocol?

Or are you suggesting that we have some sort transaction tokens attached to 
queries for the purposes of auditing, one of which may be for cost 
settlement?

Or is this a requirement for an off-line, out-of-band feature?

btw
> sets require agragation we must consider a settelments mechanism.

From 3.1.7:
   The service MUST be decentralized in design and principle and MUST
   NOT require the aggregation of data to a central repository, server,
   or entity.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Thu, 7 Nov 2002 21:52:35 -0500

On Thursday 07 November 2002 08:21 pm, Rick Wesson wrote:
> believe as long as we have requirements for general searching where res=
ult
> sets require agragation we must consider a settelments mechanism.

=46rom 3.1.7:

-andy

---

From: [email-masked] (Andrew Newton)
Date: Thu, 7 Nov 2002 21:53:12 -0500

ult

=46rom 3.1.7:

---

From: [email-masked] (Ted Hardie)
Date: Fri, 8 Nov 2002 11:19:00 -0800 (PST)

> the refrence to 3.2.3 is not a MAY-only requirement

Sorry for the confusion.  Your message referred to 3.2.3 and 3.2.5;
3.2.3 is the one you've argued we don't need and 3.2.5 is MAY-only.
I did not mean to imply that you had argued that we don't need either
or that both were MAY-only.

> sets require agragation we must consider a settelments mechanism.

I don't think 3.2.3 or 3.2.5 require aggregation of the result set.

Interprovider settlements are clearly out of scope for CRISP.  If you
would like to propose a requirement that CRISP protocols provide a
settlement mechanism, please do so in a way that focuses the text on
the relationship between the CRISP service provider and end user.

> you seem to be develing into implementations as you have reminded me all

Sorry that it has been "all too often", and I'm glad we're agreed on the
point now.  To put my own point in purely requirements terms: an interprovider
settlement requirement is both out of scope and presumes an architecture
not mandated by the other requirements.  It is inappropriate to require
a mechanism for settlement that constrains the choice of architecture.

> only for certian types of queries.

If you believe a service provider should be compensated for the work done
in answering queries, I'm not sure why you would want to limit the scope
of that compensation.

To be clear, I personally think settlement mechanisms add more cost to
this picture than they will ever recover, especially in terms of
delays in specification and deployment.  
					regards,
						Ted Hardie

---

From: [email-masked] (Rick Wesson)
Date: Fri, 8 Nov 2002 11:43:44 -0800 (PST)

Ted,

comments in line.

> a mechanism for settlement that constrains the choice of architecture.

As one of the entities that this protocol is being designed for
(Registrars) I don't understand how you as chair can make these
determinations without specifying why it is out of scope.

cost recovery s a very real issue and one Registries and Registrars are
concerned with. If you as chair could stick with managing consensus instead
of architectural design I'm sure the registries and registrars would
appreciate it.

> in answering queries, I'm not sure why you would want to limit the scope

It is the cost of new functionality that you and the draft author believe
that registries and registrars should support. by continuing your
enthusiasm for 3.2.3 and the MAY for 3.2.5 I find settlements an
acceptable compromise for the retention of those requirements.

> delays in specification and deployment.

it matters not the time frame to do the work, we are not interested in
specifications that do not address all the issues this group is
identifying. As process is not something that should be manipulated for a
predetermined outcome (LDAP/IRIS) nor is it something to be used to force
unbaked protocols into the industry.

We will do the work until the work is done without regard for ones
impatients for deployment.

-rick

---

From: [email-masked] (Ted Hardie)
Date: Fri, 8 Nov 2002 13:32:30 -0800 (PST)

Rick,

Comments in line.

> determinations without specifying why it is out of scope.

As chair, it is part of my job to remind the working group of
the scope set out in the charter.  That charter says:

"In the standard operation of Internet systems, various labels and data
are managed globally -- domain names, IPv4 and IPv6 addresses,
etc. From time to time, for operational and administrative purposes,
users of the Internet need to be able to find and access registered
information associated with those labels.

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."

This charter was discussed extensively, reviewed and amended by the
IESG, and accepted; I am aware that you did not consider it well made,
but it is the charter of this working group.  Interprovider
settlements are out of scope of the charter.

> of architectural design I'm sure the registries and registrars would

Part of my job as chair is to balance the needs of all of those
concerned.  That include more than those who will operate as service
providers; it includes the set of actors currently set forth in the
requirements documents.  As an extreme position, it would, of course,
be cheapest for the service providers simply not to provide such a
service at all, and some may choose not to provide such a service.
This does not meet the needs, however, of those interested in the
service we have set out in the charter.  From a more moderate point of
view, the need to "find and access information associate with a
label", does include costs.  As chair, I believe we need to
take that into account, but in ways that fit within the charter.

Like you, or any other member of the working group, part of my job as
a participant in this work is to give my analysis as an engineer on
what the trade-offs are likely to be in different approaches.  I have
tried to be clear when I speaking as chair and when as a working group
member; please feel free to ask at any time when you feel I have been
unclear.

As a working group member I have expressed support for several kinds
of limitations to the requirements expressed in 3.2.3; as working
group chair, I have also expressed an eagerness to read text
associated with the generic requirement of "provider equity" so
that the working group can make appropriate engineering tradeoffs.

> acceptable compromise for the retention of those requirements.

This does not respond to the question I asked: if a settlement
mechanism (service provider to end user, as that is all that might be
in scope for this working group)is needed, why should the scope be
limited by type of query?

Frankly, it seems as a participant in these discussion that you have
raised the settlement issue on 3.2.5 and 3.2.3 because you were not
able to justifiy eliminating 3.2.3 outright; if the settlement issue
for you is only a method of clarifying your reasoning as to why 3.2.3
is a bad idea, please say so.  It could be an enormous rathole, and I
don't think we need to spend time on it if it is mainly a rhetorical
device.

> impatients for deployment.

No.  Charters have timelines for a reason.  If you wish to engage in
open-ended discussion without regards to the deliverables or timelines
of this working group, you are welcome to do so somewhere else.  In
this context, however, we have a set of deliverables and a need to
produce them within a charter.  That means we need constructive
efforts in a timely fashion, not allegations of manipulation.

			regards,
				Ted Hardie

---

From: [email-masked] (Rick Wesson)
Date: Fri, 8 Nov 2002 14:21:29 -0800 (PST)

Ted,

my last comment on this, otherwise we can debate this stuff off-line.
comments in-line.

> query profiles at some future date."

Queries in of the type discussed in 3.2.5 and 3.2.3 are neither
"commonly-required" nor "Backwards compatibility with existing
administrative directory services such as WHOIS" they are new types of
queries and impose a bourdon on the service providers. I have requested
that the requirements be removed for numerous reasons which you and the
draft author disagree with.

My additional requirement for settlements, which I believe are within
the scope of the charter, is one way to address "provider equity"

> settlements are out of scope of the charter.

yes, ammended in such a way as to remove all the players except name
registries and registrars. I and many others in the naming industry took
exception with the way the charter was amended.

I have never before seen the IETF take such an approach with an industry,
where silence is being noted as approval when no one is in the room to
discuss these issues.

now that we have some more of the providers participating we may need to
review the charter which is commonly done in the IETF.

> take that into account, but in ways that fit within the charter.

or we can revise the carter to address the needs of those providers that
will service crisp queries.

> that the working group can make appropriate engineering tradeoffs.

Its not up to you to dictate consensus no matter how you cloke it.
Settlements do address the issue of provider equity as does removing the
requirements. We can debate these items several ways none of which you
seem to agree with.

In my mind we have three options.

   o drop the 3.2.3 and the MAY for 3.2.5 requirements
   o use settlements to address provider equity
   o rewrite the charter

we may choose one any of the above.

> limited by type of query?

see above, the charter specificly states "commonly-required" and types of
queries. the types enumerated in 3.2.3 and 3.2.5 are new and place a
bourdon on the LCD of the participants of the mesh. New types of queries
new requirements.

> able to justify eliminating 3.2.3 outright; if the settlement issue

I proposed settlements as a way to address the issues raised above. what I
don't understand is why you are so intent on the quick finalization of
these items and address them as written in stone instead of electrons.

I hope this wg is more about a industry solution than pushing something
through the process to address one actors Appendix-W.

> efforts in a timely fashion, not allegations of manipulation.

I am addressing providers needs and desires for this protocol and will not
tolerate requirements or charters designed to steam roll over an industry,
that approach has never worked in the IETF and consensus can't be
dictated.

Looking through the archive I can't say I've seen allot of industry
participation, in fact some months there wasn't any discussion at all. so
listen up -- the industry is here and we are participating now so things
might appear to go slower now that folks are actually looking at what is
being proposed, commenting and proposing text for the requirements.

yes things move faster in a vacuum and what you are seeing here is that
the vacuum is now being filled with participants willing to work on the
issues at hand.

best,

-rick

---

From: [email-masked] (Leslie Daigle)
Date: Fri, 08 Nov 2002 17:39:18 -0500

I'm not sure I see how the settlements requirement follows
from the earlier concern of (seemlingly) requiring servers
to participate in global searches.

In the settlements scenario, your concern seems to be that, e.g.,
ClientX will contact ServerY and get back a reply that contains
results not only from ServerY but also from ServerW (and
ServerZ will have been contacted but no relevant results
found) and this will be aggregated into a single response.

However, that is not the model that is being described in
either of the 2 draft proposals.  ClientX would contact ServerY,
which would return its results and might also include pointers 
to ServerW and ServerZ.  ClientX would then opt to pursue
those pointers, and interact directly with ServerW and
ServerZ.  Those servers could accept, deny, or charge for
the contact as they saw fit, for ClientX.

It is true that a natural follow on is to have an intermediary
that does all the work on behalf of ClientX, so that ClientX
is lightweight and so on.  However, that, and any settlements
it might entail, are somebody else's choice (and problem).

So:  As Ted said, inter-provider settlements are out of
scope for the WG (because we're not doing inter-provider).
You haven't proposed specific requirements for searcher-service
settlements, and I think the above argues they aren't needed.

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] (Leslie Daigle)
Date: Fri, 08 Nov 2002 17:47:16 -0500

Rick,

[You wrote:]
>> the vacuum is now being filled with participants willing to work on the

I see a vacuum being filled with your spurious accusations
and frustration that things are not going the way that
you, personally, understand.

The other folks from the registrar community who have
been participating here lately have had the courtesy to
try to understand what's being proposed.  It would be
pleasant if you, too, would spend more time understanding
and helping the rest of us to understand, and less time 
accusing.

I don't care to see your personal meltdown interfere with
some very solid, technical work that is being proposed 
and debated thoughtfully here.

[Full disclosure for those who don't already know -- my
employer is VeriSign.  The opinions expressed in here are,
as always, mine personally.]

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: [email-masked] (Rick Wesson)
Date: Fri, 8 Nov 2002 16:11:21 -0800 (PST)

Leslie,

> you, personally, understand.

hmmm. I've made about 8 text proposals on the requirements drafts this
month. The archives average about 50 messages a month over the last 6
months and the bulk of those posts are from VeriSign employees, almost
none from the would be "service providers."

I am frustrated with what I perceive as Ted and Andy gate-keeping all the
documents without allowing provision for the service providers to suggest
text. Every one of my requirements proposals can stand on its own merit
and maneuvering to prevent their addition does beg the question of why. I
apologie if this has tured into questioning motives.

What I see is a number of exceptions raised and the draft author, and
chair unwilling to incorporate the requests because the don't fit within
the I-Ds that will implement the requirements. This is MY perception which
is probably wrong, I'm sure some of these issue will make it into the
requirements draft.

I will attempt to re-frame these issues with less finger pointing.

> and helping the rest of us to understand, and less time

I didn't start with accusation, I started with several additions to the
document, the debate has digressed because some vagueness in the charter
and the interpretation of scope, not for technical reasons.

ok, i'll work on less accusation, debate always digresses when VeriSign
(your employer) is involved, it has something to do with trust or lack
thereof. Not of you or Andy or any of the individual employees, its an
industry thing, burned once... you know the story. Its not just me either
it anyone who comes in contact with VeriSign seems feels this.

Steam-rolling this requirements draft and the other CRISP proposals without
the style of outreach VeriSign has done as enumerated in the Appendix B.1
will backfire in a big way. This isn't accusation its my best read of an
industry I've been around for a while.

I've been encouraging registrars to participate and I'm glad some are
starting to show up. Most of them don't read the drafts, they are
more pleasant and spend more time understanding than making comments.

As someone who reads the drafts and has tracked all the crisp drafts for a
while I am going to make more comments and more proposals and expect some
of those proposals to make it into the drafts if they are technicly sound
and address the issues at hand.

> and debated thoughtfully here.

"my personal meltdown" sniff, Thats the bets quip anyone has ever sent me
on an ietf list ;-)

My issue is that the service providers have some issues that need to be
addressed in the requirements and/or charter. I'm glad you'll be here to
help see that this is accomplished.

best,

-rick

---

From: [email-masked] (Ted Hardie)
Date: Fri, 8 Nov 2002 17:30:41 -0800 (PST)

As Rick notes, this conversation might be best continued off line.
A small number of points directed at the working group below.

> draft author disagree with.

To be clear here, "Backward compatibility" was definited as *not*
required.  "Commonly required" was defined as for the actors
and communities described in the draft.  This includes IPR,
law enforcement, and end-users.

> exception with the way the charter was amended.

A clarification here:  the charter was changed after the CRISP BoF
to restrict the applicability to domain name administrative information,
but this was not meant to restrict the use of the protocol to registries
and registrars; CRISP is meant to be used by the communities which
interact with those registries and registrars.

> review the charter which is commonly done in the IETF.

Another common possiblity is to charter a working group that takes on
related work.  An interprovider protocol relating to passing
administrative information or settlement information might fall into
such a working group.  A key consideration in making this choice is how
the scope of work changes with the addition of work items.  In very
few cases have I, as an IETF participant, seen the IESG allow
charters to be amended to include major new work items when none of
the existing items are done.

> we may choose one any of the above.

As the working group members following this thread realize, this
does not represent a comprehensive list of possiblities.

> through the process to address one actors Appendix-W.

This working group has a set of deliverables set out in a charter.  It
is meant to produce a protocol that meets the needs of all of the concerned
parties.  To put it another way, it is meant to be an "Internet solution",
not an "industry solution".  

> that approach has never worked in the IETF and consensus can't be

Consensus is best reached when the participants do not take
adversarial attitudes.  Couching statements as demands and indicating
disagreements in statements that certain things will or won't be
tolerated do not foster consensus.  I encourage all working
participants to participate, and I urge all of them to do so by
focusing on the protocol design in engineering terms.

> being proposed, commenting and proposing text for the requirements.

Active, constructive participation is always welcome.

			regards,
				Ted Hardie

---

From: [email-masked] (Jim Fleming)
Date: Sat, 9 Nov 2002 00:22:36 -0600

----- Original Message ----- 
From: "Leslie Daigle" <[email-masked]>
> try to understand what's being proposed.

When will the number of TLDs in the new Taxonomy Economy be disclosed by the IETF ?
http://www.icann.org/committees/ntepptf/new-gtld-action-plan-18oct02.htm
If the answer is already known to be 32, then people may want to engineer to that.
If the TLD namespace will be capped at 256, that may result in different sizing.
Registrars just likely want to know if the number of TLDs will fit on their splash pages.
It looks like 32 is about the limit, if you look at a modern multi-TLD provider's Taxonomy...
http://www.New.Net

If only 32 are allowed, then .COM may not be included...
http://www.icann.org/comments-mail/icann-current/msg00342.html
10514 INC
9264 ONLINE
7288 NET
6472 USA
4481 GROUP
4101 WEB
3891 TECH
3077 UK
---
2762 DESIGN
2570 SYSTEMS
2542 IT
2415 US
2378 SOLUTIONS
2322 LINE
2209 LAW
2171 CONSULTING
---
2161 INFO
2033 SERVICES
2027 WORLD
1966 SOFTWARE
1940 INTERNATIONAL
1932 INTL
1880 CORP
1874 CO
---
1803 SHOP
1795 FRANCE
1720 HOMES
1671 S
1638 ART
1603 TV
1587 TRAVEL
1555 MAIL
--------------- 32 above --------
1534 EUROPE
1529 DIRECT
1491 MEDIA
1487 MALL
1431 E
1419 LTD
1417 ASSOCIATES
1411 1
1361 SERVICE
1342 2000
1339 Z
1301 NETWORK
1289 NEWS
1269 INT
1232 SA
1218 ENTERPRISES
1217 CENTER
1216 CLUB
1202 MARKETING
1177 REALTY
1161 MUSIC
1149 STORE
1144 INSURANCE
1108 I
1101 COM
========

When will the number of TLDs in the new Taxonomy Economy be disclosed by the IETF ?