[Ietf-not43] Settlements

[Rick Wesson]

Ted,

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

On Fri, 8 Nov 2002, Ted Hardie wrote:

> Rick,
>
> Comments in line.
>
> > > 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.
> >
> > 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.
>
> 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."

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"


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

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.


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

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

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

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.

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

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.

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

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.

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

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