From iesg-secretary at ietf.org Mon Nov 3 17:24:33 2003 From: iesg-secretary at ietf.org (The IESG) Date: Mon Nov 3 17:37:38 2003 Subject: [Ietf-not43] Document Action: 'Cross Registry Internet Service Protocol (CRISP) Requirements' to Informational RFC Message-ID: The IESG has approved following document: - 'Cross Registry Internet Service Protocol (CRISP) Requirements ' as an Informational RFC This document is the product of the Cross Registry Information Service Protocol Working Group. The IESG contact persons are Ted Hardie and Ned Freed. From rlehning at smimetlaw.com Tue Nov 11 17:09:56 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Tue Nov 11 17:10:00 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRISP Internet Resour ce Number Requirements draft-00 Message-ID: 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 Tue Nov 11 17:51:31 2003 From: wessorh at ar.com (Rick Wesson) Date: Tue Nov 11 17:53:36 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRISP Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <200311111451.31214.wessorh@ar.com> 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: > 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 please define accuracy, as an example describe how to accurately assess an address element in 207 countries. > 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] where are method to be kept, are you proposing another IANA database otherwize please describe the method by withch accuracy checking methods are refrenced. > 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. 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. > 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 yea, right...[snip] From rlehning at smimetlaw.com Wed Nov 12 08:35:49 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 08:35:53 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Rick, Thanks for the prompt response. It strikes me that your comments are equally relevant to the Data Omission Protocol Requirement (3.2.8.1). That requirement doesn't specify what the authorization rules might be or what the privacy constraints are, those would be filled for particular applications based on policy choices. The same goes for the proposed accuracy/verification amendment. the rules are policy, but the protocol has to be able to support whatever policy is chosen. There could be lots of different typologies of verification. One could be whether data was verified individually through contact with a registrant, or automatically. Again, the specific, implemented, typology could be left up to the registries themselves, but the protocol must accomodate some typology of methods. Doesn't the SECSAC Whois recommendation call for exactly this sort of data element? "Whois data must contain a 'Last Verified Date' that reflects the last point in time at which the information was known to contain valid data. It must also contain a reference to the data verification process." http://www.icann.org/committees/security/sac003.htm Thanks again for your helpful comments, Ryan From vb at bertola.eu.org Wed Nov 12 09:12:54 2003 From: vb at bertola.eu.org (Vittorio Bertola) Date: Wed Nov 12 09:15:02 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRISP Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <3FB23FE6.6050902@bertola.eu.org> Ryan Lehning ha scritto: > 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: 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 > services facilitates consumer protection, prevention of fraud, protection of > minors, and transparency of the Internet. 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. > 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. 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! From wessorh at ar.com Wed Nov 12 09:20:23 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Nov 12 09:22:32 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <200311120620.23749.wessorh@ar.com> Mr. Legal Professional: no matter what the SECSAC said, your proposal does not fit with the functional framework of the CRISP work. You can't say "well this works in the US because we have verifiable zip codes" and ignore the 200+ countries that your proposal does not work in. I continue to believe that a 'Last Verified Date' would be valuable to the community. Furthermore, I don't believe you have justified any of your proposal, or provided the requested examples from my last note, indicating that we may now safely ignore your proposal. -rick > Doesn't the SECSAC Whois recommendation call for exactly this sort of data > element? > > "Whois data must contain a 'Last Verified Date' that reflects the > last point in time at > which the information was known to contain valid data. It must also > contain a reference to > the data verification process." > http://www.icann.org/committees/security/sac003.htm > From rlehning at smimetlaw.com Wed Nov 12 09:34:19 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 09:34:27 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Rick, If a "Last Verified Date" would be valuable, why isn't it included in the Requirements document? Do others have comments on whether there are better ways of implementing the SECSAC recommendations than my proposal? Thanks, Ryan -----Original Message----- From: Rick Wesson [mailto:wessorh@ar.com] Sent: Wednesday, November 12, 2003 9:20 AM To: Ryan Lehning; 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Mr. Legal Professional: no matter what the SECSAC said, your proposal does not fit with the functional framework of the CRISP work. You can't say "well this works in the US because we have verifiable zip codes" and ignore the 200+ countries that your proposal does not work in. I continue to believe that a 'Last Verified Date' would be valuable to the community. Furthermore, I don't believe you have justified any of your proposal, or provided the requested examples from my last note, indicating that we may now safely ignore your proposal. -rick > Doesn't the SECSAC Whois recommendation call for exactly this sort of data > element? > > "Whois data must contain a 'Last Verified Date' that reflects the > last point in time at > which the information was known to contain valid data. It must also > contain a reference to > the data verification process." > http://www.icann.org/committees/security/sac003.htm > From rlehning at smimetlaw.com Wed Nov 12 09:49:04 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 09:49:11 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Vittorio, Thanks for commenting. The Requirements document as it stands currently overlooks the fact that the general public uses Whois. My proposed remedy would simply clarify that. Also, the Requirements document already contains statements that approach, if not encompass, policy statement, particularly Section 3.1.14 on Privacy Labels. My proposed amendment would do no more than what the Privacy Labels section does. Finally, your solution, "if you need to know more, you might simply obtain the registrant and registrar contacts and then ask them directly," will not work if the data is phony. Thanks again. I look forward to your response, Ryan -----Original Message----- From: Vittorio Bertola [mailto:vb@bertola.eu.org] Sent: Wednesday, November 12, 2003 9:13 AM To: 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRISP Internet Resour ce Number Requirements draft-00 Ryan Lehning ha scritto: > 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: 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 > services facilitates consumer protection, prevention of fraud, protection of > minors, and transparency of the Internet. 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. > 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. 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! _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From anewton at ecotroph.net Wed Nov 12 10:08:27 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Nov 12 10:08:41 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <3FB24CEB.3040802@ecotroph.net> Ryan Lehning wrote: > Rick, > > If a "Last Verified Date" would be valuable, why isn't it included in the > Requirements document? Do others have comments on whether there are better > ways of implementing the SECSAC recommendations than my proposal? > > Thanks, > > Ryan Yes. Look at dreg. I believe this covers the SECSAC recommendation (as described by Rick). -andy From vb at bertola.eu.org Wed Nov 12 10:08:25 2003 From: vb at bertola.eu.org (Vittorio Bertola) Date: Wed Nov 12 10:10:33 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <3FB24CE9.10504@bertola.eu.org> Ryan Lehning ha scritto: > Rick, > > Thanks for the prompt response. It strikes me that your comments are > equally relevant to the Data Omission Protocol Requirement (3.2.8.1). Sorry - don't want to flood you with comments - but which of his comments, and how? I disagree with your statement. That paragraph does not define any country-dependant mechanism, does not refer to undefined concepts such as "accuracy", nor it requires the creation of a new set of reference values. Furthermore, that paragraph deals with the situation where the protocol is not able to return the values it is built to return, because of policy constraints; the protocol needs to be able to cope with this situation, or, simply, it won't work. But that paragraph does not require the protocol to start supporting new data elements or extend it over its original purpose. As for ICANN's SECSAC recommendation, as you possibly know, ICANN has just started a policy making process to deal with that and other recommendations, and to verify the consensus on whether Whois contact data elements should be changed and how. So before talking about extra items to be communicated by the protocol, I think it would be wiser to wait for that process to finish. It will not take long. Then (replying to your other message): > Finally, your solution, "if you need to know more, you might simply obtain > the registrant and registrar contacts and then ask them directly," will not > work if the data is phony. Do you mean that registries return fake *registrar* information? Thanks, -- .oOo.oOo.oOo.oOo vb. Vittorio Bertola - vb [a] bertola.eu.org http://bertola.eu.org/ <-- Vecchio sito, nuovo toblog! From rlehning at smimetlaw.com Wed Nov 12 10:48:33 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 10:48:36 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Vittorio, I really do appreciate the comments. Rick's comments, "please define accuracy. . .where are methods to be kept," etc. are equally relevant to 3.2.8.1 because that subsection says that the protocol has to be able to return a result indicating a denial of access based on lack of authorization or privacy contraints. It doesn't specify what the authorization rules would be or what the privacy constraints are. As to the second question, why is any work being done on CRISP now, before the policy making process is complete? Based on your suggestion, shouldn't we therefore wait until all of the policy choices are made before specifying any technical requirements? As to your last question, I'm not quite sure what you mean. Do you mean that registrars are submitting false data to registries? (which in turn are accessed via Whois queries of the registry) They may be if the registrant is not giving reigstrars correct information. What I think you're asking is this: Is the registrar data element false when users query the registry for Whois information? It may be. For example, if a registration is being transferred, depending on where in the transfer process it is, a Whois query may return false registrar information. If a user follows your suggestion and asks a registrar to provide registrant contact information, the registrar may refuse or the registrar may refer the user to Whois which may be inaccurate for the reason stated above. Thanks, Ryan -----Original Message----- From: Vittorio Bertola [mailto:vb@bertola.eu.org] Sent: Wednesday, November 12, 2003 10:08 AM To: Ryan Lehning Cc: 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Ryan Lehning ha scritto: > Rick, > > Thanks for the prompt response. It strikes me that your comments are > equally relevant to the Data Omission Protocol Requirement (3.2.8.1). Sorry - don't want to flood you with comments - but which of his comments, and how? I disagree with your statement. That paragraph does not define any country-dependant mechanism, does not refer to undefined concepts such as "accuracy", nor it requires the creation of a new set of reference values. Furthermore, that paragraph deals with the situation where the protocol is not able to return the values it is built to return, because of policy constraints; the protocol needs to be able to cope with this situation, or, simply, it won't work. But that paragraph does not require the protocol to start supporting new data elements or extend it over its original purpose. As for ICANN's SECSAC recommendation, as you possibly know, ICANN has just started a policy making process to deal with that and other recommendations, and to verify the consensus on whether Whois contact data elements should be changed and how. So before talking about extra items to be communicated by the protocol, I think it would be wiser to wait for that process to finish. It will not take long. Then (replying to your other message): > Finally, your solution, "if you need to know more, you might simply obtain > the registrant and registrar contacts and then ask them directly," will not > work if the data is phony. Do you mean that registries return fake *registrar* information? Thanks, -- .oOo.oOo.oOo.oOo vb. Vittorio Bertola - vb [a] bertola.eu.org http://bertola.eu.org/ <-- Vecchio sito, nuovo toblog! From rlehning at smimetlaw.com Wed Nov 12 12:02:38 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 12:02:43 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Andy, Thanks for pointing me to this. Yes, it looks like dreg contains an element for last verified date. However, there doesn't appear to be any indication of how the data was verified. I'm not sure that users can reasonably rely on the accuracy of data without some indication of how that data was verified. thanks, Ryan -----Original Message----- From: Andrew Newton [mailto:anewton@ecotroph.net] Sent: Wednesday, November 12, 2003 10:08 AM To: Ryan Lehning Cc: 'Rick Wesson'; 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Ryan Lehning wrote: > Rick, > > If a "Last Verified Date" would be valuable, why isn't it included in the > Requirements document? Do others have comments on whether there are better > ways of implementing the SECSAC recommendations than my proposal? > > Thanks, > > Ryan Yes. Look at dreg. I believe this covers the SECSAC recommendation (as described by Rick). -andy From wessorh at ar.com Wed Nov 12 12:14:50 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Nov 12 12:16:57 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <200311120914.50570.wessorh@ar.com> IMHO, It is not the IETF that should deal with how data is verified. In fact since ICANN has initiated processes to define such we definately MUST NOT attempt to define such in the IETF. see http://www.icann.org/announcements/announcement-18sep03.htm -rick On Wednesday 12 November 2003 9:02 am, Ryan Lehning wrote: > Andy, > > Thanks for pointing me to this. Yes, it looks like dreg contains an > element for last verified date. However, there doesn't appear to be any > indication of how the data was verified. I'm not sure that users can > reasonably rely on the accuracy of data without some indication of how that > data was verified. > > thanks, > Ryan > > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Wednesday, November 12, 2003 10:08 AM > To: Ryan Lehning > Cc: 'Rick Wesson'; 'ietf-not43@lists.verisignlabs.com' > Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and > CRIS P Internet Resour ce Number Requirements draft-00 > > Ryan Lehning wrote: > > Rick, > > > > If a "Last Verified Date" would be valuable, why isn't it included in the > > Requirements document? Do others have comments on whether there are > > better > > > ways of implementing the SECSAC recommendations than my proposal? > > > > Thanks, > > > > Ryan > > Yes. Look at dreg. I believe this covers the SECSAC recommendation (as > described by Rick). > > -andy > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From anewton at ecotroph.net Wed Nov 12 12:19:44 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Nov 12 12:19:49 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <3FB26BB0.4060204@ecotroph.net> Ryan Lehning wrote: > > Thanks for pointing me to this. Yes, it looks like dreg contains an element > for last verified date. However, there doesn't appear to be any indication > of how the data was verified. I'm not sure that users can reasonably rely > on the accuracy of data without some indication of how that data was > verified. I agree with Rick on this point. -andy From rlehning at smimetlaw.com Wed Nov 12 12:21:19 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 12:21:24 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Rick, I'm not asking that the IETF determine how data is verified, that would be a policy decision. All I am asking is that there be some typology to describe how data is verified, in order to implement whatever policy decision is made. -Ryan -----Original Message----- From: Rick Wesson [mailto:wessorh@ar.com] Sent: Wednesday, November 12, 2003 12:15 PM To: Ryan Lehning; 'Andrew Newton' Cc: 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 IMHO, It is not the IETF that should deal with how data is verified. In fact since ICANN has initiated processes to define such we definately MUST NOT attempt to define such in the IETF. see http://www.icann.org/announcements/announcement-18sep03.htm -rick On Wednesday 12 November 2003 9:02 am, Ryan Lehning wrote: > Andy, > > Thanks for pointing me to this. Yes, it looks like dreg contains an > element for last verified date. However, there doesn't appear to be any > indication of how the data was verified. I'm not sure that users can > reasonably rely on the accuracy of data without some indication of how that > data was verified. > > thanks, > Ryan > > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Wednesday, November 12, 2003 10:08 AM > To: Ryan Lehning > Cc: 'Rick Wesson'; 'ietf-not43@lists.verisignlabs.com' > Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and > CRIS P Internet Resour ce Number Requirements draft-00 > > Ryan Lehning wrote: > > Rick, > > > > If a "Last Verified Date" would be valuable, why isn't it included in the > > Requirements document? Do others have comments on whether there are > > better > > > ways of implementing the SECSAC recommendations than my proposal? > > > > Thanks, > > > > Ryan > > Yes. Look at dreg. I believe this covers the SECSAC recommendation (as > described by Rick). > > -andy > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From vb at bertola.eu.org Wed Nov 12 12:33:00 2003 From: vb at bertola.eu.org (Vittorio Bertola) Date: Wed Nov 12 12:35:07 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 In-Reply-To: References: Message-ID: <3FB26ECC.6030801@bertola.eu.org> Ryan Lehning ha scritto: > Vittorio, > > I really do appreciate the comments. So do I. However, I'm quite a newbie on this list, so please anyone tell me if I'm going off topic. It's easy to move from technical issues to policy issues in a discussion like this, and only the former are appropriate on this list. > Rick's comments, "please define > accuracy. . .where are methods to be kept," etc. are equally relevant to > 3.2.8.1 because that subsection says that the protocol has to be able to > return a result indicating a denial of access based on lack of authorization > or privacy contraints. It doesn't specify what the authorization rules > would be or what the privacy constraints are. Pardon me, I still don't get it. Your proposal says that the protocol should mark certain data as "verified as accurate", but does not define what "accurate" means. If the two people on the two ends of the wire define "accurate" in different ways, you will fail to ensure interoperability, and you will cause confusion. On the other hand, if you say "these data are being denied due to privacy constraints", it is just the server that speaks to the author of the query. There's no possible misunderstanding, as "privacy constraints do not allow me to reply" is a judgement to be made on one side of the connection only. Unless what you mean is that "verified as accurate" in your proposal means "verified as accurate according to the registrar", which is a tautology, since the registrar will never purposedly give you data that are not the most updated ones it has (will it?). > As to the second question, why is any work being done on CRISP now, before > the policy making process is complete? Based on your suggestion, shouldn't > we therefore wait until all of the policy choices are made before specifying > any technical requirements? IMHO, that could be a good idea; work on CRISP has already taken a long time. Before making more modifications, I would wait to be sure that these would be the last and final ones. At least, this is what I advice as an engineer, when a customer comes to me to ask for a last minute feature addition, but I figure out that other people from his company are still discussing the matter, and more last minute change requests may come later. It's better for everyone if the policy people agree on what needs to be done once for all, and then the specs are changed only once more, rather than twice or three or four times more. > this: Is the registrar data element false when users query the registry for > Whois information? Right. > It may be. For example, if a registration is being > transferred, depending on where in the transfer process it is, a Whois query > may return false registrar information. Ok, but I am sure that this regards a very small number of domain names, and you can get who the correct registrar is from the other registrar. Or perhaps you should have a "verified as accurate" marker on the registrar information too? :-) > If a user follows your suggestion > and asks a registrar to provide registrant contact information, the > registrar may refuse or the registrar may refer the user to Whois which may > be inaccurate for the reason stated above. Sorry, but if the registrar refuses to tell you privately who the registrant actually is, then why do you expect it to tell everyone publicly through its CRISP server? Thanks, -- .oOo.oOo.oOo.oOo vb. Vittorio Bertola - vb [a] bertola.eu.org http://bertola.eu.org/ <-- Vecchio sito, nuovo toblog! From rlehning at smimetlaw.com Wed Nov 12 13:49:41 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 13:49:44 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Vittorio, Dreg (http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-dreg-04.txt) contains a last verification date and time element, defined as "an element containing the date and time of the last time the data for this domain was verifed by the responsible registration authority." Dreg does not state how the responsible registration authority would be. My proposal could be amended to reflect, as you suggest, that accuracy is verified by the responsible registration authority, without stating who that might be. Data may not be up to date for a variety of reasons. Whether or not the registrars reveal registrant data, and to whom they reveal it, would be policy decisions. The Requirements document contains a framework for implementing privacy policy before such policy has been decided upon. Why shouldn't it similarly contain a framework for allowing a data verification policy to implemented once such policy is decided upon? Thanks, Ryan -----Original Message----- From: Vittorio Bertola [mailto:vb@bertola.eu.org] Sent: Wednesday, November 12, 2003 12:33 PM To: Ryan Lehning Cc: 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Ryan Lehning ha scritto: > Vittorio, > > I really do appreciate the comments. So do I. However, I'm quite a newbie on this list, so please anyone tell me if I'm going off topic. It's easy to move from technical issues to policy issues in a discussion like this, and only the former are appropriate on this list. > Rick's comments, "please define > accuracy. . .where are methods to be kept," etc. are equally relevant to > 3.2.8.1 because that subsection says that the protocol has to be able to > return a result indicating a denial of access based on lack of authorization > or privacy contraints. It doesn't specify what the authorization rules > would be or what the privacy constraints are. Pardon me, I still don't get it. Your proposal says that the protocol should mark certain data as "verified as accurate", but does not define what "accurate" means. If the two people on the two ends of the wire define "accurate" in different ways, you will fail to ensure interoperability, and you will cause confusion. On the other hand, if you say "these data are being denied due to privacy constraints", it is just the server that speaks to the author of the query. There's no possible misunderstanding, as "privacy constraints do not allow me to reply" is a judgement to be made on one side of the connection only. Unless what you mean is that "verified as accurate" in your proposal means "verified as accurate according to the registrar", which is a tautology, since the registrar will never purposedly give you data that are not the most updated ones it has (will it?). > As to the second question, why is any work being done on CRISP now, before > the policy making process is complete? Based on your suggestion, shouldn't > we therefore wait until all of the policy choices are made before specifying > any technical requirements? IMHO, that could be a good idea; work on CRISP has already taken a long time. Before making more modifications, I would wait to be sure that these would be the last and final ones. At least, this is what I advice as an engineer, when a customer comes to me to ask for a last minute feature addition, but I figure out that other people from his company are still discussing the matter, and more last minute change requests may come later. It's better for everyone if the policy people agree on what needs to be done once for all, and then the specs are changed only once more, rather than twice or three or four times more. > this: Is the registrar data element false when users query the registry for > Whois information? Right. > It may be. For example, if a registration is being > transferred, depending on where in the transfer process it is, a Whois query > may return false registrar information. Ok, but I am sure that this regards a very small number of domain names, and you can get who the correct registrar is from the other registrar. Or perhaps you should have a "verified as accurate" marker on the registrar information too? :-) > If a user follows your suggestion > and asks a registrar to provide registrant contact information, the > registrar may refuse or the registrar may refer the user to Whois which may > be inaccurate for the reason stated above. Sorry, but if the registrar refuses to tell you privately who the registrant actually is, then why do you expect it to tell everyone publicly through its CRISP server? Thanks, -- .oOo.oOo.oOo.oOo vb. Vittorio Bertola - vb [a] bertola.eu.org http://bertola.eu.org/ <-- Vecchio sito, nuovo toblog! From rlehning at smimetlaw.com Wed Nov 12 13:50:07 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Wed Nov 12 13:50:13 2003 Subject: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 Message-ID: Rick, In furtherance of my last point, similarly, based on your point, it isn't IETF that should deal with what data is or is not available as a function of privacy policy. ICANN is currently looking at this issue. http://gnso.icann.org/issues/whois-privacy/tor.shtml Yet, the Requirements document contains a section on Privacy Labels (3.1.14). I don't think what I am proposing goes any further than section 3.1.14. Thanks, Ryan -----Original Message----- From: Rick Wesson [mailto:wessorh@ar.com] Sent: Wednesday, November 12, 2003 12:15 PM To: Ryan Lehning; 'Andrew Newton' Cc: 'ietf-not43@lists.verisignlabs.com' Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and CRIS P Internet Resour ce Number Requirements draft-00 IMHO, It is not the IETF that should deal with how data is verified. In fact since ICANN has initiated processes to define such we definately MUST NOT attempt to define such in the IETF. see http://www.icann.org/announcements/announcement-18sep03.htm -rick On Wednesday 12 November 2003 9:02 am, Ryan Lehning wrote: > Andy, > > Thanks for pointing me to this. Yes, it looks like dreg contains an > element for last verified date. However, there doesn't appear to be any > indication of how the data was verified. I'm not sure that users can > reasonably rely on the accuracy of data without some indication of how that > data was verified. > > thanks, > Ryan > > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Wednesday, November 12, 2003 10:08 AM > To: Ryan Lehning > Cc: 'Rick Wesson'; 'ietf-not43@lists.verisignlabs.com' > Subject: Re: [Ietf-not43] Comments on CRISP Requirements draft-06 and > CRIS P Internet Resour ce Number Requirements draft-00 > > Ryan Lehning wrote: > > Rick, > > > > If a "Last Verified Date" would be valuable, why isn't it included in the > > Requirements document? Do others have comments on whether there are > > better > > > ways of implementing the SECSAC recommendations than my proposal? > > > > Thanks, > > > > Ryan > > Yes. Look at dreg. I believe this covers the SECSAC recommendation (as > described by Rick). > > -andy > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From andy at hxr.us Thu Nov 13 11:37:30 2003 From: andy at hxr.us (Andrew Newton) Date: Thu Nov 13 11:37:37 2003 Subject: [Ietf-not43] IRIS Open Issues Message-ID: <3FB3B34A.1000903@hxr.us> The following are the items from the IRIS open issues presentation given Wednesday during the working group meeting. Please provide comments if you have them. AREG o AREG has only been updated according to a couple of directed comments on the list. o Does not yet attempt to conform to draft-ietf-crisp-internet-resource-number-req - Just a time/bandwidth issue Resolutio Methods o DREG - Defines top-down and bottom-up DNS tree walking - Good enough? o AREG - Top-down and bottom-up reverse DNS tree walking - Given that reverse DNS tree does not always accurately represent network boundaries, should we think about others? Misc. Changes o Side-effects of comments on -03 - goes away due to redefinition of - Replaced by with null 'authority' attribute content o According to RFC 2396, IETF assigned URI's cannot have dashes - Therefore ?iris-beep? URI scheme is now ?iris.beep? according to common practice Host in DREG o One implementer has noticed that the ipv4/v6 address elements are the only ones inside a container. o This is not consistent with the rest of children. Status in Domain o New change to forces server to sort them before sending them. o Maybe it should be - With the addition of a boolean valued 'current' attribute on , this allows servers to convey the history of the domain if they want. - Or simply specify that only one type of status element be used (must be expressed in words... not possible in XML Schema). (NOTE: I'll try to cover this in more detail in a separate email since it is really asking for a choice.) Draft Mechanics o All four drafts need to have references split into normative/informative. o Proper registration for the URN's in the 'ietf' NID. o Otherwise ID-nits compliant. -andy From andy at hxr.us Thu Nov 13 11:59:15 2003 From: andy at hxr.us (Andrew Newton) Date: Thu Nov 13 11:59:21 2003 Subject: [Ietf-not43] status in Domain Message-ID: <3FB3B863.5020408@hxr.us> Expounding upon the element in , there are really two parts to this issue. The first part is the noted side effect of the previous decision to make the children of the status element an unbounded sequence. The unintended consequnce was that the servers must sort the status elements if multiple are applicable. My suggestion to simply solve this problem is to change to an unbounded choice (instead of sequence) and add wording that states that no child element may appear twice. In other words, the only change in the instance XML would be that the status indication elements (the children of ) would not be ordered as they are today, but a single child may not appear more than once. The second part is really asking the working group if there is a desire to extend this change (to 'choice' from 'sequence') to include an historical record of the status (naturally, it would be optional for deployment). This would be accomplished by modifying the requirement on the child elements so that they may only appear more than once if they have an 'appliedDate' attribute containing a date not appearing in any other 'appliedDate' attribute on the same type of element. To illustrate: The simple change as described in part one: The change as described in part two: I am not convinced of the usefulness of this, but I thought I'd throw it out to see what other people think. -andy From davidb at verisignlabs.com Thu Nov 13 12:02:21 2003 From: davidb at verisignlabs.com (David Blacka) Date: Thu Nov 13 12:02:26 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: <3FB3B34A.1000903@hxr.us> References: <3FB3B34A.1000903@hxr.us> Message-ID: <200311131102.21735.davidb@verisignlabs.com> On Thursday 13 November 2003 10:37 am, Andrew Newton wrote: > The following are the items from the IRIS open issues presentation given > Wednesday during the working group meeting. Please provide comments if > you have them. > Status in Domain > o New change to forces server to sort them before sending them. This isn't a show-stopper. It is just annoying. > o Maybe it should be > - With the addition of a boolean valued 'current' attribute on > , this allows servers to convey the history of the domain > if they want. Nothing else in CRISP has pointed toward using it to see historical data about a registration object. I would be somewhat reluctant to start with this. > - Or simply specify that only one type of status element be used > (must be expressed in words... not possible in XML Schema). To be clear, the way you represent an "unordered set" in XMLSchema is to create a sequence of choices. When you do that, you make it impossible to enforce the property of uniqueness. So you could have: some date some date some other date -- David Blacka Sr. Engineer Verisign Applied Research From andy at hxr.us Thu Nov 13 12:08:21 2003 From: andy at hxr.us (Andrew Newton) Date: Thu Nov 13 12:08:27 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: <200311131102.21735.davidb@verisignlabs.com> References: <3FB3B34A.1000903@hxr.us> <200311131102.21735.davidb@verisignlabs.com> Message-ID: <3FB3BA85.90306@hxr.us> David Blacka wrote: > > Nothing else in CRISP has pointed toward using it to see historical data > about a registration object. I would be somewhat reluctant to start with > this. Agreed. I'm just throwing it out as a possible thing that could be done due to this change. I'm not convinced of its usefulness. > To be clear, the way you represent an "unordered set" in XMLSchema is to > create a sequence of choices. When you do that, you make it impossible to > enforce the property of uniqueness. So you could have: Hence the use of RFC 2119 language to formalize it. -andy From shollenbeck at verisign.com Thu Nov 13 12:47:40 2003 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu Nov 13 12:47:44 2003 Subject: [Ietf-not43] IRIS Open Issues Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A70C5B@vsvapostal8.vasrv.verisign.com> Dave, > > - Or simply specify that only one type of status > element be used > > (must be expressed in words... not possible in XML Schema). > > To be clear, the way you represent an "unordered set" in > XMLSchema is to > create a sequence of choices. When you do that, you make it > impossible to > enforce the property of uniqueness. So you could have: > > > some date > some date > some other date > I think an unordered set is better represented using the "all" model group than a sequence of choices. According to the schema primer description of an "all" group: "All the elements in the group may appear once or not at all, and they may appear in any order". Note the "once or not at all" part. -Scott- From ggm at apnic.net Thu Nov 13 12:54:33 2003 From: ggm at apnic.net (George Michaelson) Date: Thu Nov 13 12:54:47 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: <3FB3BA85.90306@hxr.us> References: <3FB3B34A.1000903@hxr.us> <200311131102.21735.davidb@verisignlabs.com> <3FB3BA85.90306@hxr.us> Message-ID: <20031113175433.4307c206.ggm@apnic.net> On Thu, 13 Nov 2003 12:08:21 -0500 Andrew Newton wrote: > David Blacka wrote: > > > > Nothing else in CRISP has pointed toward using it to see historical data > > about a registration object. I would be somewhat reluctant to start with > > this. > > Agreed. I'm just throwing it out as a possible thing that could be done > due to this change. I'm not convinced of its usefulness. In number registry space, it might help with people tracking potential hijacked nets. We're considering some issues around mandatory change logging on top level objects. Equally, this can be done offline, its more about information management than lookup. I think I have some problems conceptualizing what 'sort' means in some of these contexts. If you mean 'by time' then the sort isn't on the status, its on the date of the status. If there are other more complex sort orders, why isn't that being done in the client? -George From rlehning at smimetlaw.com Thu Nov 13 13:55:20 2003 From: rlehning at smimetlaw.com (Ryan Lehning) Date: Thu Nov 13 13:55:34 2003 Subject: [Ietf-not43] IRIS Open Issues Message-ID: George, forgive the newbie question, can you defined "mandatory change logging?" Thanks, Ryan -----Original Message----- From: George Michaelson [mailto:ggm@apnic.net] Sent: Thursday, November 13, 2003 12:55 PM To: Andrew Newton Cc: David Blacka; ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] IRIS Open Issues On Thu, 13 Nov 2003 12:08:21 -0500 Andrew Newton wrote: > David Blacka wrote: > > > > Nothing else in CRISP has pointed toward using it to see historical data > > about a registration object. I would be somewhat reluctant to start with > > this. > > Agreed. I'm just throwing it out as a possible thing that could be done > due to this change. I'm not convinced of its usefulness. In number registry space, it might help with people tracking potential hijacked nets. We're considering some issues around mandatory change logging on top level objects. Equally, this can be done offline, its more about information management than lookup. I think I have some problems conceptualizing what 'sort' means in some of these contexts. If you mean 'by time' then the sort isn't on the status, its on the date of the status. If there are other more complex sort orders, why isn't that being done in the client? -George _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From ggm at apnic.net Thu Nov 13 14:27:56 2003 From: ggm at apnic.net (George Michaelson) Date: Thu Nov 13 14:28:03 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: References: Message-ID: <20031113192756.6aebf4e1.ggm@apnic.net> On Thu, 13 Nov 2003 13:55:20 -0500 Ryan Lehning wrote: > George, forgive the newbie question, can you defined "mandatory change > logging?" > > Thanks, > Ryan if somebody changes a IP address block registry object, and its not detailing customer-specific records (which probably change a LOT, and are therefore less likely to be ameanable to tracking in depth, and in any case get to privacy issues) then it should be required that you can find out the historical data against that block. so the change logging which currently in RPSL/RIPE WHOIS V.3 can be deleted at the maintainers request (its just a field in the block, and can be added or removed at will) would become readonly/append mode. A growing list of dates at which changes were made. This is not a policy requirement, its a loose proposal which might become a policy requirement. -George > > -----Original Message----- > From: George Michaelson [mailto:ggm@apnic.net] > Sent: Thursday, November 13, 2003 12:55 PM > To: Andrew Newton > Cc: David Blacka; ietf-not43@lists.verisignlabs.com > Subject: Re: [Ietf-not43] IRIS Open Issues > > > On Thu, 13 Nov 2003 12:08:21 -0500 Andrew Newton wrote: > > > David Blacka wrote: > > > > > > Nothing else in CRISP has pointed toward using it to see historical data > > > > about a registration object. I would be somewhat reluctant to start > with > > > this. > > > > Agreed. I'm just throwing it out as a possible thing that could be done > > due to this change. I'm not convinced of its usefulness. > > In number registry space, it might help with people tracking potential > hijacked > nets. We're considering some issues around mandatory change logging on top > level > objects. Equally, this can be done offline, its more about information > management than lookup. > > I think I have some problems conceptualizing what 'sort' means in some of > these > contexts. If you mean 'by time' then the sort isn't on the status, its on > the > date of the status. If there are other more complex sort orders, why isn't > that > being done in the client? > > -George > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net From stahura at enom.com Thu Nov 13 16:26:55 2003 From: stahura at enom.com (Paul Stahura) Date: Thu Nov 13 16:26:30 2003 Subject: [Ietf-not43] IRIS Open Issues Message-ID: I see usefulness for that feature. Many times names are transferred from one registrar to another and from one registrant to another and sometimes a long chain of registrants/registrars results. These transfers (and re-registrations) happen either purposely, maliciously, or inadvertently. I think the ability to obtain the whois and other history would be useful, especially to the new registrant, much like a title search is useful when you buy a home. Transfers and re-registrations will happen more often in the future than in the past, and the chain of "ownership" will grow longer in the future, so the feature will become more useful/valuable as time goes on. -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, November 13, 2003 9:08 AM To: David Blacka Cc: ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] IRIS Open Issues David Blacka wrote: > > Nothing else in CRISP has pointed toward using it to see historical data > about a registration object. I would be somewhat reluctant to start with > this. Agreed. I'm just throwing it out as a possible thing that could be done due to this change. I'm not convinced of its usefulness. > To be clear, the way you represent an "unordered set" in XMLSchema is to > create a sequence of choices. When you do that, you make it impossible to > enforce the property of uniqueness. So you could have: Hence the use of RFC 2119 language to formalize it. -andy _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From stahura at enom.com Thu Nov 13 16:34:02 2003 From: stahura at enom.com (Paul Stahura) Date: Thu Nov 13 16:33:45 2003 Subject: [Ietf-not43] IRIS Open Issues Message-ID: I believe ICANN requires the gaining registrar to obtain and store the whois information it acquired before transfer, and also to store all changes to the registrant name field. Not 100% sure on this last one, but I know eNom keeps all changes. I'm pretty sure NSI does too, which is how they (and not just them, I'm using NSI as an example) can send marketing emails to registrants that are no longer NSI customers (even years afterward) without looking up the whois (email addresses) in the gaining registrar's whois. -----Original Message----- From: George Michaelson [mailto:ggm@apnic.net] Sent: Thursday, November 13, 2003 11:28 AM To: Ryan Lehning Cc: ietf-not43@lists.verisignlabs.com; David Blacka; Andrew Newton Subject: Re: [Ietf-not43] IRIS Open Issues On Thu, 13 Nov 2003 13:55:20 -0500 Ryan Lehning wrote: > George, forgive the newbie question, can you defined "mandatory change > logging?" > > Thanks, > Ryan if somebody changes a IP address block registry object, and its not detailing customer-specific records (which probably change a LOT, and are therefore less likely to be ameanable to tracking in depth, and in any case get to privacy issues) then it should be required that you can find out the historical data against that block. so the change logging which currently in RPSL/RIPE WHOIS V.3 can be deleted at the maintainers request (its just a field in the block, and can be added or removed at will) would become readonly/append mode. A growing list of dates at which changes were made. This is not a policy requirement, its a loose proposal which might become a policy requirement. -George > > -----Original Message----- > From: George Michaelson [mailto:ggm@apnic.net] > Sent: Thursday, November 13, 2003 12:55 PM > To: Andrew Newton > Cc: David Blacka; ietf-not43@lists.verisignlabs.com > Subject: Re: [Ietf-not43] IRIS Open Issues > > > On Thu, 13 Nov 2003 12:08:21 -0500 Andrew Newton wrote: > > > David Blacka wrote: > > > > > > Nothing else in CRISP has pointed toward using it to see historical data > > > > about a registration object. I would be somewhat reluctant to start > with > > > this. > > > > Agreed. I'm just throwing it out as a possible thing that could be done > > due to this change. I'm not convinced of its usefulness. > > In number registry space, it might help with people tracking potential > hijacked > nets. We're considering some issues around mandatory change logging on top > level > objects. Equally, this can be done offline, its more about information > management than lookup. > > I think I have some problems conceptualizing what 'sort' means in some of > these > contexts. If you mean 'by time' then the sort isn't on the status, its on > the > date of the status. If there are other more complex sort orders, why isn't > that > being done in the client? > > -George > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From sanz at denic.de Thu Nov 13 16:46:01 2003 From: sanz at denic.de (Marcos Sanz/Denic) Date: Thu Nov 13 16:46:06 2003 Subject: [Ietf-not43] status in Domain In-Reply-To: <3FB3B863.5020408@hxr.us> Message-ID: > The change as described in part two: > > > > > > I don't feel comfortable with this possibility. The service wasn't conceived to supply historical information and it may be that we are missing the scope if we walk down that way. Regards, Marcos From andy at hxr.us Thu Nov 13 17:11:45 2003 From: andy at hxr.us (Andrew Newton) Date: Thu Nov 13 17:11:51 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF01A70C5B@vsvapostal8.vasrv.verisign.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF01A70C5B@vsvapostal8.vasrv.verisign.com> Message-ID: <3FB401A1.5000605@hxr.us> Hollenbeck, Scott wrote: > > I think an unordered set is better represented using the "all" model group > than a sequence of choices. According to the schema primer description of > an "all" group: "All the elements in the group may appear once or not at > all, and they may appear in any order". > > Note the "once or not at all" part. And the "may". I'm not sure why I overlooked this. -andy From andy at hxr.us Thu Nov 13 17:20:42 2003 From: andy at hxr.us (Andrew Newton) Date: Thu Nov 13 17:20:50 2003 Subject: [Ietf-not43] status in Domain In-Reply-To: References: Message-ID: <3FB403BA.3090007@hxr.us> Marcos Sanz/Denic wrote: >>The change as described in part two: >> >> >> >> >> >> > > > I don't feel comfortable with this possibility. The service wasn't > conceived to supply historical information and it may be that we are > missing the scope if we walk down that way. I should note that this attribute would be optional. There is no amount of specifying that can help if the operator doesn't have the data. After being slapped about by a couple of individuals here at the IETF meeting, I've come to the conclusion that this feature should only be included if there is a stronger use-case than "it would be a neat feature." -andy From sanz at denic.de Thu Nov 13 21:28:07 2003 From: sanz at denic.de (Marcos Sanz/Denic) Date: Thu Nov 13 21:28:12 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: Message-ID: > I believe ICANN requires the gaining registrar to obtain and store the > whois information it acquired before transfer, and also to store > all changes to the registrant name field. Not 100% sure on this last one, > but I know eNom keeps all changes. The registry I work for keeps *lots* of things, however doesn't make them available via 43 Regards, Marcos From jaap at sidn.nl Thu Nov 13 21:49:56 2003 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Thu Nov 13 21:50:10 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: Your message of Fri, 14 Nov 2003 03:28:07 +0100. Message-ID: <200311140249.hAE2nurP061623@bartok.sidn.nl> > I believe ICANN requires the gaining registrar to obtain and store the > whois information it acquired before transfer, and also to store > all changes to the registrant name field. Not 100% sure on this last one, > but I know eNom keeps all changes. The registry I work for keeps *lots* of things, however doesn't make them available via 43 The same for mine, and not because ICANN wants it. Furthermore, there are privacy regulation which disallow us to publish this data. Most of the times it requires court orders. Anyway, this all is policy. As I have always understand it, the CRISP effort tries to be give to define a set of tools which can be used under various different policy regimes. jaap From stahura at enom.com Fri Nov 14 13:39:07 2003 From: stahura at enom.com (Paul Stahura) Date: Fri Nov 14 13:38:22 2003 Subject: [Ietf-not43] IRIS Open Issues Message-ID: I agree, eNom does not make that info available (over port-43) either at this time (but has via other channels to law enforcement for example). Alls I'm saying is that I can see: 1) how it would be a good idea to have functionality already built-in to the spec which allowed someone to look up the whois history (or other information) on a domain (or an IP address too). 2) why such a policy (requiring the storage and disclosure of the info) would be beneficial to law enforcement for example. If it is left out wouldn't it constrain the policy makers to not be able to make that policy? Also, lets say there is no policy made by the policy makers. What if a group of thin-registry-registrars/registries wanted to provide a "domain title search" product for a fee (lets assume the've kept the info over the years)? To enable them to do so, would then CRISP have to be modified at that time? Or would they have to come up with an entirely different mechanism? Why not stick it in now? No biggie, just wondering. Paul -----Original Message----- From: Jaap Akkerhuis [mailto:jaap@sidn.nl] Sent: Thursday, November 13, 2003 6:50 PM To: Marcos Sanz/Denic Cc: ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] IRIS Open Issues > I believe ICANN requires the gaining registrar to obtain and store the > whois information it acquired before transfer, and also to store > all changes to the registrant name field. Not 100% sure on this last one, > but I know eNom keeps all changes. The registry I work for keeps *lots* of things, however doesn't make them available via 43 The same for mine, and not because ICANN wants it. Furthermore, there are privacy regulation which disallow us to publish this data. Most of the times it requires court orders. Anyway, this all is policy. As I have always understand it, the CRISP effort tries to be give to define a set of tools which can be used under various different policy regimes. jaap _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From andy at hxr.us Sun Nov 16 10:11:37 2003 From: andy at hxr.us (Andrew Newton) Date: Sun Nov 16 10:11:48 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: References: Message-ID: <3FB793A9.9090905@hxr.us> I hear you, but I think the apprehension is that not much is really known about requirements for such a feature, especially when it appears that nobody does this today. That's not to say it won't be done, but perhaps a feature for version 2 when more deployment experience is available. I'd like to point out that the current dreg spec does support this in the "classic" sense. That is, there is explicit support for domain handles. If a registry/registrar desired, they could point to instances of a domain-in-time with a domain handle in the seeAlso section of a domain looked up by domain name. -andy Paul Stahura wrote: > I agree, eNom does not make that info available > (over port-43) either at this time (but has via other channels to law > enforcement for example). > > Alls I'm saying is that I can see: > 1) how it would be a good idea to have functionality already > built-in to the spec which allowed someone to look > up the whois history (or other information) on a domain (or an IP address > too). > 2) why such a policy (requiring the storage and disclosure of the info) > would be beneficial to law enforcement for example. > > If it is left out wouldn't it constrain the policy makers to > not be able to make that policy? > > Also, lets say there is no policy made by the policy makers. > What if a group of thin-registry-registrars/registries wanted to provide a > "domain title search" product for a fee (lets assume the've kept the info > over the years)? > To enable them to do so, would then CRISP have to be modified at that time? > Or would they have to come up with an entirely different mechanism? > Why not stick it in now? > > No biggie, just wondering. > Paul From sanz at denic.de Fri Nov 14 16:49:56 2003 From: sanz at denic.de (Marcos Sanz/Denic) Date: Thu Nov 20 11:29:12 2003 Subject: [Ietf-not43] IRIS Open Issues In-Reply-To: Message-ID: > What if a group of thin-registry-registrars/registries wanted to provide a > "domain title search" product for a fee (lets assume the've kept the info > over the years)? For me those are still hypothetical use cases and a vague motivation to make such kind of changes now. But this is just my opinion. Regards, Marcos