[Ietf-not43] Settlements

[Leslie Daigle]

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.

Rick Wesson wrote:
> Ted,
> 
> comments in line.
> 
> On Fri, 8 Nov 2002, Ted Hardie wrote:
> 
> 
>>Rick writes:
>>
>>>>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.
>>>
>>>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.
>>
>>
>>>>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.
>>>
>>>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.
>>
>>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
>>>to often not to do.
>>
>>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.
> 
> 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.
> 
> 
>>>>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?
>>>
>>>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.
> 
> 
> 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.
> 
> 
>>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.
> 
> -rick
> 
> 
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43@lists.verisignlabs.com
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43


-- 

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

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------