[Ietf-not43] -02 requirements draft

[Ted Hardie]

Rick,
	Thanks for your message.  Comments in line.

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

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

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

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

	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