Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRISP Internet Resour ce Number Requirements draft-00

From: rlehning at smimetlaw.com (Ryan Lehning)
Date: Tue Nov 11 17:10:00 2003

I would like to submit the following comments on two CRISP documents:
draft-ietf-crisp-requirements-06 (hereafter Requirements documet) and
draft-ietf-crisp-internet-resource-number-req-00 (hereafter Numbers
document).  

Requirements Document

The draft protocol outlined in the Requirements document fails to fully
describe the community of users who need access to Internet resource
information, including registrant data for domain name registrations.  As
such, I propose an amendment to section 2.4 "End Users," to include a new
subsection 2.4.7 as follows:

2.4.7 General Public

		General and casual users of the Internet use the directory
services of Internet registries to determine who is behind the Internet
resources with which they interact.  The general public use of directory
services facilitates consumer protection, prevention of fraud, protection of
minors, and transparency of the Internet.

Similarly, the protocol fails to include a framework for ensuring the
accuracy and currentness of data elements.  This could be remedied by
amending the Requirements to include specifications for tagging returned
values to show if the accuracy of data has been verified, if so, when, and
by what method it was verified.  I propose the following amendment:

	3.1.15 Data Verification Labels

	3.1.15.1 Protocol Requirement

		When a value in an answer to a query is given, the protocol
MUST be capable of tagging the value with the following labels:

		1.	Accuracy of data has been verified

		2.	Accuracy of data has not been verified

		If the data has been verified, the protocol MUST be capable
of tagging the value with the following labels:

		1.	Accuracy of data was last verified on [data on which
the accuracy of data was last verified]

		2.	Accuracy of data was last verified by [method by
which the accuracy of data was last verified]

		The protocol MUST include a typology for describing the
method by which the accuracy of data is verified.  For example, if
verification takes place by cross-checking U.S. street addresses with a
database of U.S. Zip Codes, a "1" could be inserted into the label to
indicate verification by such method.  

		The protocol MAY define other values for this purpose, but
MUST define values defined above at a minimum.  The protocol MUST be capable
of attaching these labels concurrently.

		3.1.15.2 Service Description

		Though registries may have different policies regarding
access to their data, the accuracy of that data is vital to the stability
and security of the Internet.  For this reason, registries may need to tag
data, or queried values, with labels specifying if and when the accuracy of
the data had been verified, and the method by which it was verified.

Numbers Document

	The Numbers document likewise fails to include a framework for
ensuring the accuracy and currentness of data elements.  Therefore, I
propose an amendment to the Numbers document to add a new subsection 3.2.9
as follows (note, this language is identical to the proposed amendment to
the Requirements document above):

3.2.9 Data Verification Labels

	3.2.9.1 Protocol Requirement

		When a value in an answer to a query is given, the protocol
MUST be capable of tagging the value with the following labels:

		1.	Accuracy of data has been verified

		2.	Accuracy of data has not been verified

		If the data has been verified, the protocol MUST be capable
of tagging the value with the following labels:

		1.	Accuracy of data was last verified on [data on which
the accuracy of data was last verified]

		2.	Accuracy of data was last verified by [method by
which the accuracy of data was last verified]

		The protocol MUST include a typology for describing the
method by which the accuracy of data is verified.  For example, if
verification takes place by cross-checking U.S. street addresses with a
database of U.S. Zip Codes, a "1" could be inserted into the label to
indicate verification by such method.  

		The protocol MAY define other values for this purpose, but
MUST define values defined above at a minimum.  The protocol MUST be capable
of attaching these labels concurrently.

		3.2.9.2 Service Description

	Though registries may have different policies regarding access to
their data, the accuracy 	of that data is vital to the stability and
security of the Internet.  For this reason, 	registries may need  to tag
data, or queried values, with labels specifying if and 	when the
accuracy of the data had been verified, and the method by which it was
verified.

I look forward to your responses on these proposals.

Thank you very much,

Ryan Lehning

---

From: wessorh at ar.com (Rick Wesson)
Date: Tue Nov 11 17:53:36 2003

Mr Attorney:

nice work! Though it looks like you are simply focused on US data elements.

If you would be so kind to respond to my comments in line.

thanks,

-rick

On Tuesday 11 November 2003 2:09 pm, Ryan Lehning wrote:
> services facilitates consumer protection, prevention of fraud, protection
> of minors, and transparency of the Internet.
>

please define accuracy, as an example describe how to accurately assess an 
address element in 207 countries.

> which the accuracy of data was last verified]

where are method to be kept, are you proposing another IANA database otherwize 
please describe the method by withch accuracy checking methods are refrenced.

> indicate verification by such method.

great, explain how this is done for china, japan, and aruba. If you can't make 
your method work for those countries then we can safely ignore the rest of 
your note.

> MUST define values defined above at a minimum.  The protocol MUST be
> capable of attaching these labels concurrently.
>

yea, right...[snip]

---

From: vb at bertola.eu.org (Vittorio Bertola)
Date: Wed Nov 12 09:15:02 2003

> subsection 2.4.7 as follows:

Are you sure that this is appropriate for a protocol requirements 
document? IMHO, a good part of your text is just a collection of 
personal opinions that are neither uncontroversial nor objective. For 
example:

 > The general public use of directory

This is just an opinion - in fact, I have heard many people complaining 
that public use of directory services, by exposing people's identities 
and contact details, hugely increases the chances for identity theft, 
frauds and personal harassment.

 > access to their data, the accuracy of that data is vital to the
 > stability and security of the Internet.

Again, this is just your personal opinion on a policy issue. I don't 
think that it is appropriate for a technical document to make this kind 
of statements.

More generally, I don't get the need to add features to the protocol to 
send this kind of data to the client. You might then add a feature to 
specify from which host the domain name registration form was filled, or 
which browser was used during the registration process, or whether it 
was raining on the day the domain was registered, or other tons of 
irrelevant personal and impersonal information...

I think that the protocol should stay focused on meeting the need for 
exchanging contact details, rather than being overloaded with other 
purposes; if you need to know more, you might simply obtain the 
registrant and registrar contacts and then ask them directly. After all, 
that's exactly what the protocol is meant for.
-- 
.oOo.oOo.oOo.oOo vb.
Vittorio Bertola - vb [a] bertola.eu.org
http://bertola.eu.org/    <-- Vecchio sito, nuovo toblog!