[Ietf-not43] -02 requirements draft

[Ted Hardie]

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


> 
> 
> 
> 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
> 
> 
> 
> On Tue, 5 Nov 2002, Ted Hardie wrote:
> 
> > 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
> >
> >
> >
> >
> >
> > >
> > >
> > >
> > > 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:
> > >
> > > > 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
> > > >
> > > >
> > > > _______________________________________________
> > > > Ietf-not43 mailing list
> > > > Ietf-not43@lists.verisignlabs.com
> > > > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> > > >
> > >
> >
>