From ehall@ehsco.com Tue Apr 2 03:47:41 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 01 Apr 2002 21:47:41 -0600 Subject: [Ietf-not43] BoF summary? Message-ID: <3CA929DD.3CC0F44F@ehsco.com> How did the BoF go? Anything come of it? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@verisignlabs.com Tue Apr 2 19:40:21 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 02 Apr 2002 14:40:21 -0500 Subject: [Ietf-not43] BoF summary? In-Reply-To: <3CA929DD.3CC0F44F@ehsco.com> References: <3CA929DD.3CC0F44F@ehsco.com> Message-ID: <1017776422.4380.17.camel@zedonthego.admin.cto.netsol.com> Hmmm... we probably should find the scribe and get the minutes published. -andy On Mon, 2002-04-01 at 22:47, Eric A. Hall wrote: > > How did the BoF go? Anything come of it? > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.research.netsol.com > http://lists.research.netsol.com/mailman/listinfo/ietf-not43 From Ted.Hardie@nominum.com Tue Apr 2 19:44:36 2002 From: Ted.Hardie@nominum.com (Ted Hardie) Date: Tue, 2 Apr 2002 11:44:36 -0800 Subject: [Ietf-not43] BoF summary? In-Reply-To: <1017776422.4380.17.camel@zedonthego.admin.cto.netsol.com>; from anewton@verisignlabs.com on Tue, Apr 02, 2002 at 02:40:21PM -0500 References: <3CA929DD.3CC0F44F@ehsco.com> <1017776422.4380.17.camel@zedonthego.admin.cto.netsol.com> Message-ID: <20020402114436.A66003@shell.nominum.com> Andy, The scribe gave me the minutes the night of the BoF, and it is my fault that they weren't sent to the list (or the Secretariat, yet). I need to do a little cleaning of names and such, and will do so by tomorrow afternoon at the latest. Ted On Tue, Apr 02, 2002 at 02:40:21PM -0500, Andrew Newton wrote: > Hmmm... we probably should find the scribe and get the minutes > published. > > -andy > > On Mon, 2002-04-01 at 22:47, Eric A. Hall wrote: > > > > How did the BoF go? Anything come of it? > > > > -- > > Eric A. Hall http://www.ehsco.com/ > > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > _______________________________________________ > > Ietf-not43 mailing list > > Ietf-not43@lists.research.netsol.com > > http://lists.research.netsol.com/mailman/listinfo/ietf-not43 > > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.research.netsol.com > http://lists.research.netsol.com/mailman/listinfo/ietf-not43 From Ted.Hardie@nominum.com Thu Apr 4 01:14:45 2002 From: Ted.Hardie@nominum.com (Ted Hardie) Date: Wed, 3 Apr 2002 17:14:45 -0800 Subject: [Ietf-not43] DRAFT minutes Message-ID: <20020403171445.A8569@shell.nominum.com> Below are the draft minutes for the BoF session in Minneapolis. My thanks to Lisa for her help and skills; any errors were, no doubt, introduced by my own poor editing. Comments to me or the list as soon as possible, as the final minutes are due fairly soon. thanks, Ted Hardie CRISP BOF Ted Hardie, Chair 53rd IETF, March 18, 2002 Minutes taken by Lisa Dusseault (lisa@xythos.com) Edited by Ted Hardie (Ted.Hardie@nominum.com) Summary: The BoF session discussed the audience and requirements for a cross-registry information service protocol. The consensus of the room was that the overlap in requirements among the identified audiences was not clear enough to warrant the scope proposed by the BoF organizers. As a first step towards clarifying the requirements, it was agreed that a set of use cases would be supplied to the mailing list; a requirements list or document prepared from the use cases would then be the basis for further discussion. Details of BoF presentations and discussion: Why registries need a new solution Presentation by Stig Venaas of Uninett Why are Norwegian registries interested in alternatives to WHOIS? * The main problem is no authentication. The registry should be able to provide almost no information to anonymous users, and by contrast provide full information to registrars. * Another problem is the need to limit query responses according to the IP address requesting, or even better, by authenticated ID. * Need a standardized query language to allow the same tools to query multiple registries * Need a standardized structured output to allow the same tools to parse responses from multiple registries Storage of registry information is in a SQL database, but LDAP access to that database would involve slow responses because of the different structures required. Currently the Norwegian registries are using LDAP, but that involves replicating data from the SQL server to LDAP in order to get fast queries. EU Privacy rules Issue about European protection and privacy issues and how they related to this. Answer: registries have to use different rules, depending on whether the records are describing individuals or organizations. The rules in Sweden, according to Patrick F, is that the registry may not publish information about private persons (name, telephone number, postal address). This is interesting information, in so far as it produces requirements for the system. The requirement for the system is that the registry records must be taggable with policy such as this. Decisions may be related to the entry type. Performance of LDAP compared to WHOIS Using an oracle database and constrained query sets, Network Solutions tests have shown that LDAP can sustain the same query rates as WHOIS. Whois-like information is getting more and more fragmented. This is another opportunity to try and fix it. Unified Front-end problems Demonstration of Geektools retrieval of whois information by Ted. A unified front end has been built but it is difficult to do anything useful with the unstructured data from various back-ends. The kind of tagging on the data from the Australian registry is much more extensive than that available from the American registry. Processing is difficult. Anything that would be logical to prevent data mining by spammers also prevents legitimate use. Servers should be able to reference each other, perhaps in chains, so that front ends don't have to do so much work RIR Input Regarding WHOIS deficiencies Presentation by Cathy Murphy, on behalf of ARIN (not the RIRs) * Need a one-stop lookup service This would only be needed to handle IP address space and AS (Aut-num) queries. Data mirroring is a possibility. Perhaps a set of limited- function servers could know what RIR to query? Then the appropriate RIR could actually respond to the query. ARIN membership specifically requested the RWhois model. * Data accuracy concerns * Misuse of contact information: Currently all information is public, and sources of that information must know that. We're thinking of doing a private service in the future. Currently ARIN does make data available in bulk, subject to an acceptable use policy. * Increased server load: Better software and hardware and architectures are needed to handle 2-6 x load increases in past year. What are we not doing: Ted Hardie Note that the word WHOIS is not in the name of the BOF. It is specifically not supposed to be backward compatible with WHOIS. Requirements Draft Requirements have already been discussed at several venues so could be pretty mature. Users and Scope Some different communities of users have been identified, but the scope of the problem has been narrowed to those that administer the Internet: * Address registry operators: RIR, NIR, LIR. * Domain registry operators * Law enforcement and intellectual property enforcers This is about accessing data, not provisioning. The focus is on interaction between registry and end-user. Requirements Standard requirements apply: standard, extensible, decentralized, use existing solutions. More particular requirements: * Access control: level of access, techniques to prevent anonymous data miners * DNS referencing: use DNS to locate appropriate servers. E.g. using SRV records. * Must be able to lookup specific information given a key. * Must be able to search * Standard formats must be produced. Address, domain and routing registries share most of these requirements. In addition, routing registries require mirroring. In addition, domain registries need escrow support. Discussion on identification of users: Are these the right users to select? Do they really share the same needs? In some address applications, multiple registries might be involved in producing a single answer. That creates some difficulties. Cathy noted that any distributed system has that. In RWhois, referral provides the way to get additional information. Rick pointed out that this same discussion has happened before in the IETF. Are the users really ready for it, this time? Will they stand up and help work with us to do this? We can write this stuff and agree to it within the IETF. Let's hear that Verisign wants this. They're not here? That's a problem. Ted notes that it's not just the United States registries that are concerned. We have here a broad population of people who are somewhat content to keep doing the same thing they're doing. To attract those people, we need to have a concrete proposal, with a concrete set of advantages, to present to them. We don't have that yet. But does it mean we give up now? Should we eliminate some of the user communities we've already identified? E.g. forget about the routing registries for now, and perhaps expand later? Crocker suggested we need several concrete usage scenarios to drive design. Questioning the Need Is there a really serious user requirement that isn't being satisfied? Well, the registrars have a real need for a standard representation because of how transfers occur. Now they do compete against each other, and it's difficult at times to get to provide resources. There are certain user communities that need certain parts of what's currently provided by WHOIS. What they do does not work very well. For example, the incident report CERT equivalent folks. They need to track down in near real-time, who claims responsibility for a net block or domain. Right now, its very difficult or time-consuming for them to track this information through the layers where it is now: NIR to RIR to LIR. Alexander French, speaking as an operator, says yes we want solutions to the requirements outlined. However, we're not the ones who need to implement solutions. Goals: Is this meant to supplement WHOIS, replace WHOIS, or be redundant with WHOIS? IF the aim is to replace, then uptake will be slow. CRISP is not to change the interior workings of registries business, nor how they store their information. Without changing either of these, it should be possible to provide query capability and structure for responses. Scope and Complexity Is this too much work to try to solve? Crocker seemed to think so. Jaap repeated that specificity and narrow scope is good, that there are even other kinds of registries, not covered here. Response was general agreement that of course we're not considering user groups not considered here. Rick suggested that when a service has been abused, and you're trying to find all the entities that must be contacted about that abuse, this work would really make that task easier. Specifically on Routing registries If RPSL solves this problem, we should use it. One of the problems we see today is that data is separated, and you can't get good authentication unless you combine the data in the same store. Since the routing registration data necessary falls out of the address data, it's not as crazy as it sounds. Proposal Overview Leslie Daigle Two proposals have been put forward: ldap-whois and iris. Neither of these was written by Leslie, but this is just intended to be an overview. Both proposals stay focused on the intended audience (IRRs, RIRs, domain registries, network operators). Clients can be written to any server software; the bigger issue is the care and feeding of servers. LDAP-WHOIS This proposal leverages LDAP for the query response model, and has a data model that spans all the applications identified in the requirements. See the draft for details. Performance of LDAP in this space? Issues about whether LDAP is capable of scaling to the size of data and number of queries required? Reassurances from some people who have actually tried, that it does. IRIS This proposal uses XML schema based query and responses. The data model is inferred. HTTP has been proposed for a transport. Currently IRIS is for individual servers. No way to get references to other authorities. See the draft for details. IRIS vs. LDAP Global Service Either IRIS or LDAP-WHOIS could be a front-end to existing registry databases, instead of completely replacing them. Missing pieces Neither proposal addresses cross-registry searches. Cannot aggregate If you are thinking of a service that will take others' whois information and store it in a 3rd party location, that is doomed to fail for numerous reasons. Some entities are prevented from allowing their information to be aggregated in this manner. Problems solved by FreeBSD client To a certain extent, the FreeBSD project has solved a lot of these problems with a smart WHOIS client. It parses the user's request and attempts to look up, through a DNS query with the TLD, who is the appropriate WHOIS server to ask. It's not perfect, and later versions are better than earlier versions. Some of the work that you're suggesting has therefore already been done. However, no work has been done to parse the response or do anything with it. Note that the output they get is limited. You're left with a situation where a human can parse the information that is returned and do something with it. Also note that the client implementation community is always chasing an increasing number of servers with different formats etc. This is at least a point to start from. Privacy again Opposition to queries that go to all the registries that are out there, collating information about an individual. It may be inevitable but must be opposed. However, are there some kinds of things we should be able to search across all registries? E.g. the existence of a particular domain name across all TLDs? So what is the requirement for a protocol? Is there a new technical requirement in addition to the requirements we've already presented for authentication and policy? Apparently not. Data accuracy George suggested that data accuracy must be out of scope. Of course data must be as accurate as possible, but that's a matter of human process, not something that can be standardized. Of course we can't guarantee quality of data. However, we can Different schemas There are commonalities among the information presented, but they are not the same. Different people present different information. If we chose RPSL as a schema language, or some other, and the schema elements for an RIR are different from those for a different registry, but they use the same protocol, is that a problem? There may also be a common way to do referrals Some records will always be so advanced that they are unparsable. User groups are or are not interested in standardization Somebody stated that many of the supposed end users of this solution don't want a standard solution. RIPE NCC doesn't want this. We are convinced we have a system that works. It took a while to develop and make work. It has been extensively tuned. You mentioned incident response teams? We rolled out a system to support European incident response teams. If you are going to throw out everything we have for a utopic system that is going to cause more trouble than it is going to remove Another (12) RIPE NCC member(s) said that they would love to see this. There's been a big effort to remove DNS information from the RIPE database, and that's a fine thing. However it doesn't mean that we can't access that information with the same mechanisms. A draft that we could hit people with and ask them to implement it now, please. You would then see registries, registrars and RIRs coming around. Existing solutions RIPE 81 is an existing solution. When we did RPSL we looked around to see what was out there. We started from something without that. If we are going to change that standard, let's do it for a good reason, not just XML. The requirements that I'm hearing have more to do with domain registries. Is there a requirement that the two registries have to be the same? What ties domain name registries with routing registries? Answers: Perhaps it's that they share the same end users, that the same customers go to each of these registries looking for information. There was some discussion about specific scenarios where the end user would actually want to pull information from various different registries and collate it. Work Plan Ted Hardie [NOTE: See charter for specific work plan proposal] RIPE will not have an implementation of the proposal by Feb 2003 (the suggested Proposed Standard date) Rick noted that the iris draft looks easily as complex as implementing a LDAP server. A requirements document can either be agreed upon quickly, or never. The difference between the two is whether you can get agreement on what it is you're intending to do. The presentation earlier is helpful in that regard though still hand-waving. Resources are there for writing the necessary documents as evidenced by the two proposals and requirements draft are already written. The question is rather whether there is agreement what this is about. Statement: Usage scenarios will be written, that will feed into the requirements document. Agreement that this is useful? Significant hum for yes, none for no. From ehall@ehsco.com Thu Apr 4 03:41:23 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 03 Apr 2002 21:41:23 -0600 Subject: [Ietf-not43] DRAFT minutes References: <20020403171445.A8569@shell.nominum.com> Message-ID: <3CABCB63.86C43662@ehsco.com> Ted Hardie wrote: > > Below are the draft minutes for the BoF session in > Minneapolis. My thanks to Lisa for her help and skills; > any errors were, no doubt, introduced by my own poor > editing. Comments to me or the list as soon as possible, > as the final minutes are due fairly soon. Thanks Ted, sounds like a useful discussion. Comments and questions: > Answer: registries have to use different rules, depending on whether > the records are describing individuals or organizations. The rules in > Sweden, according to Patrick F, is that the registry may not publish > information about private persons (name, telephone number, postal > address). This is interesting information, in so far as it produces > requirements for the system. My take would be that this produces requirements for the provider rather than the system, although the provider requirement may introduce system requirements. Can this be one of the usage scenarios so that this is more better explored? > What are we not doing: Ted Hardie > * Address registry operators: RIR, NIR, LIR. > * Domain registry operators > * Law enforcement and intellectual property enforcers > > This is about accessing data, not provisioning. > The focus is on interaction between registry and end-user. Personally 100% agree. My interest in this project results from an inability to locate and reach operators of public resources, primarily. > Should we eliminate some of the user communities we've already > identified? E.g. forget about the routing registries for now, and > perhaps expand later? This is certainly something to consider. The use of player-specific schema makes extensibility an option. However, some core schema cannot be easily modified after-the-fact so the more positive involvement there is up-front will provably result in a better, more-stable design. My personal opinion is that asking for their involvement is free, while not asking has known hidden costs. We should at least make sure that the core schema are sufficient for secondary audiences to build layered services onto. > Goals: Is this meant to supplement WHOIS, replace WHOIS, or be > redundant with WHOIS? IF the aim is to replace, then uptake will be > slow. This is a distributed query service, which is something different than the legacy WHOIS service. If somebody wants to put a perl front-end for this service on their local tcp/43, that should work fine, but that's not the goal, nor is it an objective. > Privacy again Opposition to queries that go to all the registries that > are out there, collating information about an individual. > However, are there some kinds of things we should be able to search > across all registries? Three options that I can see here. First is to build a back-end query mechanism into the distributed servers. That really loads up the server requirements. Nor is in spirit with the traditional Internet model of having clients do their own work. It is possible however. One other potential concern is that this may make reusing existing technologies somewhat difficult, or that it will require back-end locator technologies that can't use the same public locator services as the clients, nevermind the additional authentication and authorization requirements. Another option here is to let the clients do their own work, and use referrals for redirection and SeeAlso data. Personally, I tried to include attributes that would let people tell you this stuff if they wanted you to know it. Since the ACLs are per-jurisdiction anyway, this seems like the only thing that will work in the end. One more option is a catalog service. The Internet community could go out and build their own catalog service to do this "right" but I don't think anybody really wants another branch of Internet governance, which would pretty much be required to manage this stuff. Alternatively, encourage the Googles of the world to setup their own catalog servers, just as they did with other services. This seems somewhat inevitable to me anyway. In the end, the lawyer-actors would probably prefer a catalog service with global access. However, they get paid by the hour, so I don't feel bad about making them work for a living. > Statement: Usage scenarios will be written, that will feed into the > requirements document. Agreement that this is useful? Significant hum > for yes, none for no. Is this somebody's action item? Thanks for the great notes -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@verisignlabs.com Thu Apr 4 14:21:30 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 04 Apr 2002 09:21:30 -0500 Subject: [Ietf-not43] DRAFT minutes In-Reply-To: <3CABCB63.86C43662@ehsco.com> References: <20020403171445.A8569@shell.nominum.com> <3CABCB63.86C43662@ehsco.com> Message-ID: <1017930091.4380.153.camel@zedonthego.admin.cto.netsol.com> On Wed, 2002-04-03 at 22:41, Eric A. Hall wrote: > > My take would be that this produces requirements for the provider rather > than the system, although the provider requirement may introduce system > requirements. Can this be one of the usage scenarios so that this is more > better explored? I have the same reaction. This appears to be an implementation issue and not necessarily a protocol issue. However, if it gets twisted just a bit further into something where the contact info for individuals must be kept private except to the owner of the data, then we get into a protocol issue. A use-case on this might flesh it out further. Good point. > Another option here is to let the clients do their own work, and use > referrals for redirection and SeeAlso data. Personally, I tried to include > attributes that would let people tell you this stuff if they wanted you to > know it. Since the ACLs are per-jurisdiction anyway, this seems like the > only thing that will work in the end. I agree. > > Statement: Usage scenarios will be written, that will feed into the > > requirements document. Agreement that this is useful? Significant hum > > for yes, none for no. > > Is this somebody's action item? Yes. However, it doesn't stop others from contributing or presenting their own. -andy From ehall@ehsco.com Thu Apr 4 16:06:39 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 04 Apr 2002 10:06:39 -0600 Subject: [Ietf-not43] DRAFT minutes References: <20020403171445.A8569@shell.nominum.com> <3CABCB63.86C43662@ehsco.com> <1017930091.4380.153.camel@zedonthego.admin.cto.netsol.com> Message-ID: <3CAC7A0F.735E47F4@ehsco.com> Andrew Newton wrote: > > On Wed, 2002-04-03 at 22:41, Eric A. Hall wrote: > > > > My take would be that this produces requirements for the provider > > rather than the system, although the provider requirement may > > introduce system requirements. Can this be one of the usage scenarios > > so that this is more better explored? > > I have the same reaction. This appears to be an implementation issue > and not necessarily a protocol issue. However, if it gets twisted just > a bit further into something where the contact info for individuals must > be kept private except to the owner of the data, then we get into a > protocol issue. > > A use-case on this might flesh it out further. Good point. Is paf on this list? The case that would probably be most-illustrative of this issue would be a Swedish user registering a domain in the com gTLD. Would the law require that the com operator restrict the information in that case? Another variation on this would be that a Swedish registrar sells domains from the com registry. Would the Swedish registrar have to restrict information about the American user (and all other users) or would they only restrict information about Swedes? Some of those issues may result in bleed-overs. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From es@nrm.se Fri Apr 5 10:27:17 2002 From: es@nrm.se (Eva Stengard) Date: Fri, 5 Apr 2002 12:27:17 +0200 (MEST) Subject: [Ietf-not43] DRAFT minutes In-Reply-To: <3CAC7A0F.735E47F4@ehsco.com> Message-ID: Hi, don't know about paf but we are more Swedes on this list... The Swedish implementation of the European Data Protection Act is said to be the most rigourous. I cannot tell as I haven't compared it with other implementations. However, I'm uncertain to what extent what I'm saying below regarding the Swedish case also is valid in a more European context. That will take a lawyer majoring in European law to answer. > The case that would probably be most-illustrative of this issue would be a > Swedish user registering a domain in the com gTLD. Would the law require > that the com operator restrict the information in that case? Assuming that all information is gathered and kept by a non-Swedish entity outside of Sweden the law is not applicable. > Another variation on this would be that a Swedish registrar sells domains > from the com registry. Would the Swedish registrar have to restrict > information about the American user (and all other users) or would they > only restrict information about Swedes? The law does not make any distinction between the nationality of those from whom the information originates. Therefore, in this case, the law will apply. For those of you interested I've tried to make a summary of the law (what I think is relevant here) below. FYI, though I've had professional reasons to familiarize myself with the law, I'm not a lawyer. IMHO, there are things in the law that make it necessary for the protocol to permit transport of certain data regardless of implementation. But as I haven't done my homework properly yet (going through all the material produced by this group) I will not make any suggestions. I hope the text below will shed some light on the problem for those more familiar with the protocol specifications. Eva Stengård Project Associate MuseDoma ------------------- The law applies in all cases where the gathering party is established in Sweden (regardless of where the data is kept). It also applies when parties established outside of Sweden keeps/ process data on equipment located in Sweden. A number of basic requirements is put on any processing. The gathering party is responsible for making sure that - the data are only used for legal purposes; - the data are always processed correctly and in correspondance with 'good common praxis'; - data are only collected for especially specified and relevant tasks (any processing inconsistent with these tasks is forbidden); - only data relevant (and no more) to the tasks at hand are collected; - the data processed are correct and, if necessary, up to date; - best effort is made to correct, block or remove data that are incorrect or incomplete with regard to the purpose; - data is not kept longer than necessary. [Historical, statistical and scientific purposes are deemed always consistent with the original tasks.] The gathering party is also responsible for inform the person what data are collected and how it's going to be used as wells as keeping the data safe from irregular use. [Detailed regulation.] Processing is OK when the person from whom the data originates has given his/ her consent OR - it is necessary to fulfill or make possible to fulfill an agreement with the person; - the gathering party is fulfilling a legal obligation; - vital interests of the person is to be protected; - a task of common interest needs to be performed; - it is necessary in connection to 'governmental purposes' [it's more rigid in the original text but I'm uncertain about the translation]; - it is necessary in connection with a relevant interest deemed being more important than personal integrity. Processing is NOT OK in connection to 'targeted marketing' [spam] IF the person, in writing, has opposed this [opt-out]. There are also special rules regarding processing of 'sensitive data'. Of interest may also be that it is in general forbidden to transfer processed data or data for processing to a third country. Exceptions is made if - the person has given his/ her consent; - it is necessary to fulfill or make possible to fulfill an agreement with the person; - legal claims are to be confirmed, made valid or protected; - vital interests of the person is to be protected; It's possible to get some other exceptions in certain circumstances. From ehall@ehsco.com Fri Apr 5 17:09:46 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Fri, 05 Apr 2002 11:09:46 -0600 Subject: [Ietf-not43] DRAFT minutes References: Message-ID: <3CADDA59.D04CF217@ehsco.com> Thanks Eva. Based on the material below, it would appear to me that the requirements are only applicable to the providers, and do not impose any special demands on the protocol. To the extent that a provider has to conform to these demands, they can: 1) get authorization from the user during the registration process 2) provide limited information locally and use referrals to redirect queries to user-managed contact information In either or both of those cases, the demands (as I understand them) would be satisfied. My opinion/interpretation Eva Stengard wrote: > > Hi, > don't know about paf but we are more Swedes on this list... > > The Swedish implementation of the European Data Protection Act is said to > be the most rigourous. I cannot tell as I haven't compared it with other > implementations. However, I'm uncertain to what extent what I'm saying > below regarding the Swedish case also is valid in a more European > context. That will take a lawyer majoring in European law to answer. > > > The case that would probably be most-illustrative of this issue would be a > > Swedish user registering a domain in the com gTLD. Would the law require > > that the com operator restrict the information in that case? > > Assuming that all information is gathered and kept by a non-Swedish entity > outside of Sweden the law is not applicable. > > > Another variation on this would be that a Swedish registrar sells domains > > from the com registry. Would the Swedish registrar have to restrict > > information about the American user (and all other users) or would they > > only restrict information about Swedes? > > The law does not make any distinction between the nationality of those > from whom the information originates. Therefore, in this case, the law > will apply. > > For those of you interested I've tried to make a summary of the law > (what I think is relevant here) below. FYI, though I've had professional > reasons to familiarize myself with the law, I'm not a lawyer. > > IMHO, there are things in the law that make it necessary for the protocol > to permit transport of certain data regardless of implementation. But as I > haven't done my homework properly yet (going through all the material > produced by this group) I will not make any suggestions. I hope the text > below will shed some light on the problem for those more familiar with the > protocol specifications. > > Eva Stengård > Project Associate > MuseDoma > > ------------------- > > The law applies in all cases where the gathering party is established in > Sweden (regardless of where the data is kept). It also applies when > parties established outside of Sweden keeps/ process data on equipment > located in Sweden. > > A number of basic requirements is put on any processing. > The gathering party is responsible for making sure that > - the data are only used for legal purposes; > - the data are always processed correctly and in correspondance with 'good > common praxis'; > - data are only collected for especially specified and relevant tasks (any > processing inconsistent with these tasks is forbidden); > - only data relevant (and no more) to the tasks at hand are collected; > - the data processed are correct and, if necessary, up to date; > - best effort is made to correct, block or remove data that are incorrect > or incomplete with regard to the purpose; > - data is not kept longer than necessary. > [Historical, statistical and scientific purposes are deemed always > consistent with the original tasks.] > > The gathering party is also responsible for inform the person what data > are collected and how it's going to be used as wells as keeping the data > safe from irregular use. [Detailed regulation.] > > Processing is OK when the person from whom the data originates has given > his/ her consent OR > - it is necessary to fulfill or make possible to fulfill an agreement with > the person; > - the gathering party is fulfilling a legal obligation; > - vital interests of the person is to be protected; > - a task of common interest needs to be performed; > - it is necessary in connection to 'governmental purposes' [it's more > rigid in the original text but I'm uncertain about the translation]; > - it is necessary in connection with a relevant interest deemed being more > important than personal integrity. > > Processing is NOT OK in connection to 'targeted marketing' [spam] IF the > person, in writing, has opposed this [opt-out]. > > There are also special rules regarding processing of 'sensitive data'. > > Of interest may also be that it is in general forbidden to transfer > processed data or data for processing to a third country. > Exceptions is made if > - the person has given his/ her consent; > - it is necessary to fulfill or make possible to fulfill an agreement with > the person; > - legal claims are to be confirmed, made valid or protected; > - vital interests of the person is to be protected; > It's possible to get some other exceptions in certain circumstances. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@verisignlabs.com Mon Apr 8 16:21:08 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 08 Apr 2002 11:21:08 -0400 Subject: [Ietf-not43] DRAFT minutes In-Reply-To: <3CADDA59.D04CF217@ehsco.com> References: <3CADDA59.D04CF217@ehsco.com> Message-ID: <1018279272.24989.10.camel@zedonthego.admin.cto.netsol.com> On Fri, 2002-04-05 at 12:09, Eric A. Hall wrote: > > Based on the material below, it would appear to me that the requirements > are only applicable to the providers, and do not impose any special > demands on the protocol. To the extent that a provider has to conform to > these demands, they can: > > 1) get authorization from the user during the registration process I agree. > 2) provide limited information locally and use referrals to redirect > queries to user-managed contact information The need for referrals is a demand for a requirement of the protocol. [... parts snipped ...] > > Processing is OK when the person from whom the data originates has given > > his/ her consent OR > > - the gathering party is fulfilling a legal obligation; > > - it is necessary in connection to 'governmental purposes' [it's more > > rigid in the original text but I'm uncertain about the translation]; > > - it is necessary in connection with a relevant interest deemed being more > > important than personal integrity. > > > > Processing is NOT OK in connection to 'targeted marketing' [spam] IF the > > person, in writing, has opposed this [opt-out]. It would seem that preventing spam for a person who has opted out and fulfilling legal obligations or providing data for governmental purposes may also place requirements on the protocol. -andy From ehall@ehsco.com Mon Apr 8 18:48:22 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 08 Apr 2002 12:48:22 -0500 Subject: [Ietf-not43] DRAFT minutes References: <3CADDA59.D04CF217@ehsco.com> <1018279272.24989.10.camel@zedonthego.admin.cto.netsol.com> Message-ID: <3CB1D7E5.B27896D3@ehsco.com> Andrew Newton wrote: > > 2) provide limited information locally and use referrals to redirect > > queries to user-managed contact information > > The need for referrals is a demand for a requirement of the protocol. Yeah, it certainly should be in the requirements if it isn't already. Specifically, this is a need for continuation referrals, where the registrar provides *some* information but where *more* information is available at this other location. I do not want all contact data to exist in a remote database, as that model lets spammers and other abusers hide themselves very easily. It would be nice if we could demand some sort of public key certificate for this stuff so that we could always see some form of identify. Probably won't work, either for technical, political or nationalist (exposes some personal data) reasons. > It would seem that preventing spam for a person who has opted out and > fulfilling legal obligations or providing data for governmental purposes > may also place requirements on the protocol. Wouldn't that kind of flag be part of the provisioning database rather than the query database? EG, you could make this data available as data in the lists which are sold, rather than through the not43 interface. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From shane@ripe.net Mon Apr 8 20:27:06 2002 From: shane@ripe.net (Shane Kerr) Date: Mon, 8 Apr 2002 21:27:06 +0200 Subject: [Ietf-not43] DRAFT minutes In-Reply-To: <3CB1D7E5.B27896D3@ehsco.com> References: <3CADDA59.D04CF217@ehsco.com> <1018279272.24989.10.camel@zedonthego.admin.cto.netsol.com> <3CB1D7E5.B27896D3@ehsco.com> Message-ID: <20020408192706.GA26773@penguin.ripe.net> On 2002-04-08 12:48:22 -0500, Eric A. Hall wrote: > > Andrew Newton wrote: > > > > 2) provide limited information locally and use referrals to > > > redirect queries to user-managed contact information > > > > The need for referrals is a demand for a requirement of the > > protocol. > > Yeah, it certainly should be in the requirements if it isn't > already. Specifically, this is a need for continuation referrals, > where the registrar provides *some* information but where *more* > information is available at this other location. I do not want all > contact data to exist in a remote database, as that model lets > spammers and other abusers hide themselves very easily. I like the idea of continuation referrals. In fact, this seems like it could fit in well with *ahem* extending existing protocols. I'm not exactly sure what the issue with spammers and other abusers is, however, or why they may more easily take advantage of referrals. > It would be nice if we could demand some sort of public key > certificate for this stuff so that we could always see some form of > identify. Probably won't work, either for technical, political or > nationalist (exposes some personal data) reasons. I'm also not sure how the desire for a certificate fits in with the desire for a continuation referral. Or why it wont work. :P -- Shane Kerr Only representing my own interests here. From anewton@verisignlabs.com Mon Apr 8 21:57:55 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 08 Apr 2002 16:57:55 -0400 Subject: [Ietf-not43] DRAFT minutes In-Reply-To: <20020408192706.GA26773@penguin.ripe.net> References: <3CADDA59.D04CF217@ehsco.com> <1018279272.24989.10.camel@zedonthego.admin.cto.netsol.com> <3CB1D7E5.B27896D3@ehsco.com> <20020408192706.GA26773@penguin.ripe.net> Message-ID: <1018299476.24990.40.camel@zedonthego.admin.cto.netsol.com> On Mon, 2002-04-08 at 15:27, Shane Kerr wrote: > I like the idea of continuation referrals. In fact, this seems like > it could fit in well with *ahem* extending existing protocols. I think this is probably one of the reasons why an LDAP solution to this space might be better... not because of the technology but because of the adoption. How many of us believe a registrant is going to setup a whois server, an rwhois server, or even an IRIS server just to do this? The reality is that they probably already have an LDAP server... if it isn't AD present in XP or Exchange, it is probably iPlanet or OpenLDAP doing NIS or white pages for their Postfix or Courier setup, or one of the other many reasons (applications) for which they have deployed it. -andy From ehall@ehsco.com Mon Apr 8 22:09:43 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 08 Apr 2002 16:09:43 -0500 Subject: [Ietf-not43] DRAFT minutes References: <3CADDA59.D04CF217@ehsco.com> <1018279272.24989.10.camel@zedonthego.admin.cto.netsol.com> <3CB1D7E5.B27896D3@ehsco.com> <20020408192706.GA26773@penguin.ripe.net> Message-ID: <3CB20716.13E9F5B2@ehsco.com> Shane Kerr wrote: > I'm not exactly sure what the issue with spammers and other abusers > is, however, or why they may more easily take advantage of referrals. There are multiple kinds of referrals. Subordinate referralsa say that *all* of the data is at some location. The problem there is that the user can provide intentionally misleading information. EG, a spammer who doesn't want to get their account yanked could provide false information, either to mislead ("I am Donald Duck") or to defame ("I am Shane Kerr"). Continuation referrals provide *some* information locally, but provide pointers to *more* information at some other location. EG, the registrar says "he is Joe Spammer" while the referral says "I am somebody else". > I'm also not sure how the desire for a certificate fits in with the > desire for a continuation referral. Or why it wont work. :P Certs would provide third-party validation of who the operator really is. EG, there could be: registry --> "he registered as Joe Operator" certauth --> "the cert is for Joe Operator, and is valid" operator --> "I am Donald Duck" There are lots of reasons why people don't want this, or why it isn't entirely feasible to demand it. On the other hand, this application in particular is only for certain audiences, so it is possibly to mandate that this limited audience provide the information. Dunno, but it seems like this would be an extremely political can of worms to get into. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@verisignlabs.com Fri Apr 12 17:49:55 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 12 Apr 2002 12:49:55 -0400 Subject: [Ietf-not43] use case: unwanted email Message-ID: <1018630196.29676.74.camel@zedonthego.admin.cto.netsol.com> As noted in the BoF minutes, concensus was that 3 use cases be developed. Here is the first one. Comments and questions welcomed. Use Case: Unwanted E-mail From A Domain Description: Actor A is receiving a large amount of e-mail from Actor B. This e-mail contains large attachments and is of no use or desire to Actor A. Requests to have the e-mail stopped have gone unanswered or bounce with error messages indicating the mail box for Actor B is full. Actor A would like to contact a technical administrator. Actor A would also not like to resort to such tactics as blocking all e-mail from Actor B's domain as it would block very important e-mail from other addresses with that domain. Problem Statement #1: Actor A is unfamiliar with the .us domain and does not know the name of the administrative information server. There is no prescribed method for him to determine the name of any server for any domain. Possible Solutions to #1: A) A registering authority for all administrative information servers can be setup to be the central repository for all the server names. The possible risk to this solution is that it places too much power into the hands of a single organization and also risks being a central point of failure for all administrative information lookups. B) A naming scheme could be defined to standardize how the names are to be found and allow for the use of other advanced features that can be offered by use of the best common practices of a modern, federated naming system. Problem Statement #2: The contact information held at the registering authority for the technical contact of Actor B's domain contains only a disconnected phone number. Possible Solutions to #2: A) Defer to a policy statement to fix the problem. B) Define a mechanism to allow referrals to a registrant's information server. Some registrants may opt to run one of these and therefore may be more inclined to keep it up to date. In addition, they may decide to offer more information than would be collected or distributed by the registering authority, such as a separate e-mail address to send e-mail abuse or problems versus just an e-mail address for a domain contact. From Hong.Liu@neustar.biz Fri Apr 12 18:44:04 2002 From: Hong.Liu@neustar.biz (Liu, Hong) Date: Fri, 12 Apr 2002 12:44:04 -0500 Subject: [Ietf-not43] use case: unwanted email Message-ID: Andrew, I have a number of comments regarding this use case: (1) The real issue in this use case is about finding out the contact information of a DNS delegation. This is a general problem regarding stale contact information in a registry. I am not sure the federated name scheme will solve the problem any better than a thick registry approach. It really boils down to having all registrants cooperate, be it through their own servers or through registry policy. (2) The argument against the thick registry approach is questionable. The single point of failure can be resolved by a registry that deploys redundant whois servers. (3) It seems that the need to collect information from various sources other than the registry itself is a legacy problem primarily related to thin registries. We are well aware of this problem in the .us locality space and we are in the process of consolidating the information using a thick registry approach. I am not so sure how frequent this happens to domain names under .us, as opposed to those under other more popular thin registries. I would suggest that the reference to .us in the use case be replaced by a more generic term such as "thin registry". (4) It is possible to associate multiple contacts with a domain in EPP. There is no limit in the protocol regarding how many contact objects can be associated with a domain object. So if a registrant so chooses to have a different contact for handling email abuse, it can create an additional admin contact for that purpose. Of course, EPP does not define a contact type as "email abuse", but it does relieve the "single contact problem" mentioned in your email. Cheers, --Hong -----Original Message----- From: Andrew Newton [mailto:anewton@verisignlabs.com] Sent: Friday, April 12, 2002 12:50 PM To: ietf-not43@lists.research.netsol.com Subject: [Ietf-not43] use case: unwanted email As noted in the BoF minutes, concensus was that 3 use cases be developed. Here is the first one. Comments and questions welcomed. Use Case: Unwanted E-mail From A Domain Description: Actor A is receiving a large amount of e-mail from Actor B. This e-mail contains large attachments and is of no use or desire to Actor A. Requests to have the e-mail stopped have gone unanswered or bounce with error messages indicating the mail box for Actor B is full. Actor A would like to contact a technical administrator. Actor A would also not like to resort to such tactics as blocking all e-mail from Actor B's domain as it would block very important e-mail from other addresses with that domain. Problem Statement #1: Actor A is unfamiliar with the .us domain and does not know the name of the administrative information server. There is no prescribed method for him to determine the name of any server for any domain. Possible Solutions to #1: A) A registering authority for all administrative information servers can be setup to be the central repository for all the server names. The possible risk to this solution is that it places too much power into the hands of a single organization and also risks being a central point of failure for all administrative information lookups. B) A naming scheme could be defined to standardize how the names are to be found and allow for the use of other advanced features that can be offered by use of the best common practices of a modern, federated naming system. Problem Statement #2: The contact information held at the registering authority for the technical contact of Actor B's domain contains only a disconnected phone number. Possible Solutions to #2: A) Defer to a policy statement to fix the problem. B) Define a mechanism to allow referrals to a registrant's information server. Some registrants may opt to run one of these and therefore may be more inclined to keep it up to date. In addition, they may decide to offer more information than would be collected or distributed by the registering authority, such as a separate e-mail address to send e-mail abuse or problems versus just an e-mail address for a domain contact. _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.research.netsol.com http://lists.research.netsol.com/mailman/listinfo/ietf-not43 From anewton@verisignlabs.com Fri Apr 12 19:45:20 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 12 Apr 2002 14:45:20 -0400 Subject: [Ietf-not43] use case: unwanted email In-Reply-To: References: Message-ID: <1018637121.29675.106.camel@zedonthego.admin.cto.netsol.com> On Fri, 2002-04-12 at 13:44, Liu, Hong wrote: > > (1) The real issue in this use case is about finding out the contact > information of a DNS delegation. This is a general problem regarding stale > contact information in a registry. I am not sure the federated name scheme > will solve the problem any better than a thick registry approach. It really > boils down to having all registrants cooperate, be it through their own > servers or through registry policy. No, you have mixed two of the problem statements with one of the solutions. The first problem is that a user does not know where to start looking. The second problem is about the delegations. > (2) The argument against the thick registry approach is questionable. The > single point of failure can be resolved by a registry that deploys redundant > whois servers. And who is going to run this uber whois server? It would make more sense to take advantage of an existing infrastructure than to build a new one. The problem isn't just how I follow the information from registry to registrar, but also how do I find the proper registry in the first place. > (3) It seems that the need to collect information from various sources other > than the registry itself is a legacy problem primarily related to thin > registries. We are well aware of this problem in the .us locality space and > we are in the process of consolidating the information using a thick > registry approach. I am not so sure how frequent this happens to domain > names under .us, as opposed to those under other more popular thin > registries. I would suggest that the reference to .us in the use case be > replaced by a more generic term such as "thin registry". First off, I'm sorry that .us slipped in there. I orginially was going to use some-country.big-state.us as an example for a problem statement concerning a non-functioning whois server, but I decided to take it out. I guess I missed the references to it. Second, I just checked with my local Internet historian and he assures me that thick registries walked the earth first. This possibly places them in the category of "legacy". Third, you are right that the reference to .us should come out (see above). However, I don't believe the problem is specific to thin or thick registries. I just tried the "smart" whois client that comes with Mandrake 8.2 on fairfax.va.us. It's answer "This TLD has no whois server." > (4) It is possible to associate multiple contacts with a domain in EPP. > There is no limit in the protocol regarding how many contact objects can be > associated with a domain object. So if a registrant so chooses to have a > different contact for handling email abuse, it can create an additional > admin contact for that purpose. Of course, EPP does not define a contact > type as "email abuse", but it does relieve the "single contact problem" > mentioned in your email. And if registry X decides they don't care to publish such information or even keep it around... Besides, what is wrong with allowing registrants the ability to have their own server in this system? I know that if I could do it for my domains, I would be much more likely to keep that info up to date. And I'd also have the ability to restrict its use as I see fit. -andy From Hong.Liu@neustar.biz Fri Apr 12 20:52:20 2002 From: Hong.Liu@neustar.biz (Liu, Hong) Date: Fri, 12 Apr 2002 14:52:20 -0500 Subject: [Ietf-not43] use case: unwanted email Message-ID: Andrew, Please see my comments in line. Cheers, --Hong -----Original Message----- From: Andrew Newton [mailto:anewton@verisignlabs.com] Sent: Friday, April 12, 2002 2:45 PM To: Liu, Hong Cc: ietf-not43@lists.research.netsol.com Subject: RE: [Ietf-not43] use case: unwanted email On Fri, 2002-04-12 at 13:44, Liu, Hong wrote: > > (1) The real issue in this use case is about finding out the contact > information of a DNS delegation. This is a general problem regarding stale > contact information in a registry. I am not sure the federated name scheme > will solve the problem any better than a thick registry approach. It really > boils down to having all registrants cooperate, be it through their own > servers or through registry policy. No, you have mixed two of the problem statements with one of the solutions. The first problem is that a user does not know where to start looking. The second problem is about the delegations. So let me back off a bit and ask the question: is the respective registry the natural place to start with? Sure, as you pointed out, the whois informaiton you get from the query may not be up-to-date or even exist. But that is a separate probelm. <\HL> > (2) The argument against the thick registry approach is questionable. The > single point of failure can be resolved by a registry that deploys redundant > whois servers. And who is going to run this uber whois server? It would make more sense to take advantage of an existing infrastructure than to build a new one. The problem isn't just how I follow the information from registry to registrar, but also how do I find the proper registry in the first place. To your first question, I think any modern web server farm technology will do to provide the level of redundancy required. If you are talking about domain names only (forget about RIR for the moment), then (taking your use case) one can deduce the TLD from the email address, right? Then one can find out the registry for that TLD. The search space is bounded and is small, though the whole process may not be fully automated. I may be missing something since you emphasize twice about not knowing how to locate the registry. Could you give me an example? <\HL> > (3) It seems that the need to collect information from various sources other > than the registry itself is a legacy problem primarily related to thin > registries. We are well aware of this problem in the .us locality space and > we are in the process of consolidating the information using a thick > registry approach. I am not so sure how frequent this happens to domain > names under .us, as opposed to those under other more popular thin > registries. I would suggest that the reference to .us in the use case be > replaced by a more generic term such as "thin registry". First off, I'm sorry that .us slipped in there. I orginially was going to use some-country.big-state.us as an example for a problem statement concerning a non-functioning whois server, but I decided to take it out. I guess I missed the references to it. Second, I just checked with my local Internet historian and he assures me that thick registries walked the earth first. This possibly places them in the category of "legacy". Third, you are right that the reference to .us should come out (see above). However, I don't believe the problem is specific to thin or thick registries. I just tried the "smart" whois client that comes with Mandrake 8.2 on fairfax.va.us. It's answer "This TLD has no whois server." The example you cited is exactly the problem we inherited from the previous (thin) registry. In its true sense, it is a legacy issue, -:) What I was trying to say is that this is less a problem with the thick approach than the thin approach. <\HL> > (4) It is possible to associate multiple contacts with a domain in EPP. > There is no limit in the protocol regarding how many contact objects can be > associated with a domain object. So if a registrant so chooses to have a > different contact for handling email abuse, it can create an additional > admin contact for that purpose. Of course, EPP does not define a contact > type as "email abuse", but it does relieve the "single contact problem" > mentioned in your email. And if registry X decides they don't care to publish such information or even keep it around... Besides, what is wrong with allowing registrants the ability to have their own server in this system? I know that if I could do it for my domains, I would be much more likely to keep that info up to date. And I'd also have the ability to restrict its use as I see fit. Sure, a registry can decide what to do with the information and there is nothing wrong with a registrant providing more information itself. What I was saying is that mechanisms already exist for thick registries to overcome the "single contact" problem in your use case. A "good" thick registry should keep all the registrant-provisioned informaiton related to a domain and publish it according to the registry contract. Access control is also a policy issue that can be enforced by a registry. <\HL> As a general comment, I am not against developing a standard format for exchanging whois information among registries. I think this is a good thing. But the use case just does not seem to justify the need to establish a whole new infrastructure for a problem that could be largely solved by better registry practice and more cooperative registrant behaviors. I would think that many registrants are not technically savy enough to maintain their own servers. So even the latter won't solve the problem completely. <\HL> -andy From ehall@ehsco.com Fri Apr 12 21:18:14 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Fri, 12 Apr 2002 15:18:14 -0500 Subject: [Ietf-not43] use case: unwanted email References: Message-ID: <3CB74106.915CB550@ehsco.com> "Liu, Hong" wrote: > I may be missing something since you emphasize twice about not knowing > how to locate the registry. Could you give me an example? How do I know which WHOIS server to query for the .jp TLD? Trying a default of whois.jp and whois.nic.jp doesn't work. Nor would it work for all cases, since I may need to get information for tn.us which would not match against whois.nic.us (I need whois.nic.tn.us, which doesn't actually exist). Secondary to that, how does a server know where to send me for a CIDR address delegation where the delegations are not on label boundaries? Referrals are necessary for both the root domains and all resources throughout all hierarchies. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Ted.Hardie@nominum.com Mon Apr 15 17:09:37 2002 From: Ted.Hardie@nominum.com (Ted Hardie) Date: Mon, 15 Apr 2002 09:09:37 -0700 Subject: [Ietf-not43] Use Case/scenario Message-ID: <20020415090937.B33509@shell.nominum.com> Hi folks, Here's another crack at a usage scenario for CRISP. Comments to the list, please. thanks, Ted Hardie Use Case: Large Number of domains spread across registries. Description: An Organization has a large number of domains, distributed among different ccTLDs and gTLDs. The ccTLDs and gTLDs are administered by different registry operators, and the registrations occurred through several different registrars. An internal systems group or outsourced DNS service needs to verify domain data matches operational practice. The organizaton may also need to check, maintain, or end public access to contact data. An Organization may also wish to consolidate registrations for a specific TLD through a single registrar. Problem Statement: Maintaining consistent and correct information among the various service providers requires mastery of a large number of inconsistent interfaces. Currently, this mastery can be achieved only through the investment of significant resources on the part of the registrant; this creates an equally significant barrier to change in cases where the registrant wishes to change registrars or consolidate registrations. Possible Solutions: 1) The creation of a centralized administrative contact database with globally unique identifiers and a single interfaces. This solution concentrates power and the risk of failure into a single organization, raising serious concerns about privacy, jurisdiction, and the stability of the system. 2) Standardize the interface in use by service providers and create a system which allows for delegation and continuation references, so that changeable data (such as contact telephone numbers) can be maintained locally while global data (such as organization currently administering a domain) is accessible through a known interface. From leslie@thinkingcat.com Tue Apr 16 20:29:17 2002 From: leslie@thinkingcat.com (Leslie Daigle) Date: Tue, 16 Apr 2002 15:29:17 -0400 Subject: [Ietf-not43] use case: selective access Message-ID: <3CBC7B8D.C37B4A8A@thinkingcat.com> This is a multi-part message in MIME format. --------------53044F4E43EC406F7816A9AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, Here's another use case for discussion... Leslie. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- --------------53044F4E43EC406F7816A9AB Content-Type: text/plain; charset=us-ascii; name="041202-lld-use-case.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="041202-lld-use-case.txt" Use case: Registrar needs to provide selective access to collected data Description: A domain registrar is required to collect specific data from domain registrants. This may include contact or other personal (social) data. The registrar is also faced with competing requirements to make data publicly available and to provide adequate privacy for the registrants. These policy requirements vary from region to region. Problem Statement 1: The registrar may be required to allow individual domain registrants (holders) to "opt out" of allowing public presentation to ANY of their data. (E.g., open access to searches on the Internet). Possible Solution i: The registrar chooses not to make any of the collected domain holder data available publicly. [Achievable with whois today]. Issue: Public access to some domain holder data is required or desired for administrative purposes. Possible Solution ii: The registrar maintains 2 databases, using network-level access controls to secure the private one (e.g., it is only accessible on the registrar's internal network). [Achievable with whois today]. Issue: Requires maintaining and synchronizing 2 related databases. The databases would be "domain holders" and "opted out domain holders". Wreaks havoc with any kind of referral mechanism (which database is the target?). Possible Solution iii: The registrar provides one single service to access domain holder data, but enforces access control restrictions. [CANNOT be implemented with RFC954 whois today.] Problem Statement 2: The registrar may be required to allow individual domain registrants (holders) to "opt out" of allowing public presentation to SOME of their data. (E.g., open access to searches on the Internet). Possible Solution i: The registrar chooses not to make any of the collected domain holder data available publicly. [Achievable with whois today]. Issue: Public access to some domain holder data is required or desired for administrative purposes. Possible Solution ii: The registrar maintains 2 databases, using network-level access controls to secure the private one (e.g., it is only accessible on the registrar's internal network). [Achievable with whois today]. Issue: Requires maintaining and synchronizing 2 related databases. The databases would be "public data for each domain holder" and "private data for each domain holder". Possible Solution iii: The registrar provides one single service to access domain holder data, but enforces access control restrictions. [CANNOT be implemented with RFC954 whois today.] Problem Statement 3: The registrar may be required to provide access to all domain holder data to law enforcement agents. Possible Solution i: The registrar chooses not to make any of the collected domain holder data available publicly. [Achievable with whois today]. Issue: Public access to some domain holder data is required or desired for administrative purposes. Law enforcement agents would have to obtain privileged access to internal databases. Possible Solution ii: The registrar maintains 2 databases, using network-level access controls to secure the private one (e.g., it is only accessible on the registrar's internal network). [Achievable with whois today]. Issue: Requires maintaining and synchronizing 2 related databases. Depending on the requirements, that might be "domain holders" and "opted out domain holders", or "public data for each domain holder" and "private data for each domain holder". Wreaks havoc withtany kind of referral mechanism (which database is the target?). Again, requires special access and search tools for law enforcement agents. Issue: Registrars may need to be able to provide both -- allowing individual domain holders to "opt out" of public access to data, while allowing access to that data for specific classes (e.g., law enforcement). The dual database model becomes complex to design and maintain. Possible Solution iii: The registrar provides one single service to access domain holder data, but enforces access control restrictions. [CANNOT be implemented with RFC954 whois today.] --------------53044F4E43EC406F7816A9AB-- From es@nrm.se Wed Apr 17 09:26:28 2002 From: es@nrm.se (Eva Stengård - es) Date: Wed, 17 Apr 2002 10:26:28 +0200 Subject: [Ietf-not43] use case: selective access References: <3CBC7B8D.C37B4A8A@thinkingcat.com> Message-ID: <029d01c1e5ed$b03a38a0$a6f297d4@susan> Hi, whether or not data should be public/ private in an opt-out (or opt-in)=20 scheme is IMHO conditional as you normally opt-out certain specified=20 uses of the data. It's not just a decision on the data being public or = not. Therefore any data, though certain types of data such as e-mail=20 addresses probably more often, may need a battery of rules=20 associated with them. In some cases they may even need to follow=20 the data in exports. For instance (say regarding admin contact e-mail): opt-in : publishing in registrar web directory opt-out : bulk export opt-out : export to third party opt-in : bulk e-mail from registrar trusted partners opt-in : statistical use Some of the rules may be non-optional from the domain holders=20 point of view and rather dictated by legal or technical requirements. For any rule the interpretation of null must be specified. Using two databases for public/ private data does not solve the=20 problem with conditional use however a model using a master from=20 which is generated a number of 'mirror facets' (databases) at=20 regular intervals may work. Each 'mirror facet' should have one=20 specific use that is clearly stated in a standardized way (so that=20 the collection of 'mirror facets' of the same kind may serve as a=20 distributed database). Access may then be set up for each facet=20 as a whole and not per data entry in them. > Use case: Registrar needs to provide selective access to > collected data >=20 > Description: A domain registrar is required to collect specific > data from domain registrants. This may include contact or > other personal (social) data. The registrar is also faced with > competing requirements to make data publicly available and > to provide adequate privacy for the registrants. These policy > requirements vary from region to region.=20 >=20 Just some thoughts, without any regard whatsoever on what's=20 possible or not today or what have been proposed so far :-), Eva Eva Steng=E5rd MuseDoma From anewton@verisignlabs.com Wed Apr 17 15:25:02 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 17 Apr 2002 10:25:02 -0400 Subject: [Ietf-not43] use case: selective access In-Reply-To: <029d01c1e5ed$b03a38a0$a6f297d4@susan> References: <029d01c1e5ed$b03a38a0$a6f297d4@susan> Message-ID: <1019053507.17838.5.camel@zedonthego.admin.cto.netsol.com> Eva, These are some excellent points. My comments in-line... > Hi, > whether or not data should be public/ private in an opt-out (or opt-in)=20 > scheme is IMHO conditional as you normally opt-out certain specified=20 > uses of the data. It's not just a decision on the data being public or = > not. > Therefore any data, though certain types of data such as e-mail=20 > addresses probably more often, may need a battery of rules=20 > associated with them. In some cases they may even need to follow=20 > the data in exports. > For instance (say regarding admin contact e-mail): > opt-in : publishing in registrar web directory > opt-out : bulk export > opt-out : export to third party > opt-in : bulk e-mail from registrar trusted partners > opt-in : statistical use You have a valid idea here, however I think it is more relevant to the provisioning side (PROVREG) that this information is collected. I think the thing for us to understand is that if a registry has such information, the publication protocol must allow for these rules to be followed. > Using two databases for public/ private data does not solve the=20 > problem with conditional use however a model using a master from=20 > which is generated a number of 'mirror facets' (databases) at=20 > regular intervals may work. Each 'mirror facet' should have one=20 > specific use that is clearly stated in a standardized way (so that=20 > the collection of 'mirror facets' of the same kind may serve as a=20 > distributed database). Access may then be set up for each facet=20 > as a whole and not per data entry in them. Excellent point. I agree. -andy From es@nrm.se Thu Apr 18 07:41:36 2002 From: es@nrm.se (=?iso-8859-1?Q?Eva_Steng=E5rd?=) Date: Thu, 18 Apr 2002 08:41:36 +0200 (MEST) Subject: [Ietf-not43] use case: selective access In-Reply-To: <1019053507.17838.5.camel@zedonthego.admin.cto.netsol.com> Message-ID: Andy and all, > > Therefore any data, though certain types of data such as e-mail > > addresses probably more often, may need a battery of rules > > associated with them. In some cases they may even need to follow > > the data in exports. > > For instance (say regarding admin contact e-mail): > > opt-in : publishing in registrar web directory > > opt-out : bulk export > > opt-out : export to third party > > opt-in : bulk e-mail from registrar trusted partners > > opt-in : statistical use > > You have a valid idea here, however I think it is more relevant to the > provisioning side (PROVREG) that this information is collected. I think > the thing for us to understand is that if a registry has such > information, the publication protocol must allow for these rules to be > followed. I agree that most of it is applicable where the information is collected but I also think that in any case where information collected also may end up being available from another party the protocol need to support transfer of such data as above between the parties. Let's use registrar - registry as an exemple. If information collected by the registrar have been subject to opt-in/ opt-out by the domain holder gets transferred to the registry the rules needs to be included if data transferred is accessible by any other party than the registrar. With the inclusion of sponsored TLDs there's now three parties involved with somewhat overlapping needs of the data collected by the registrars. So, I believe the protocol has to support transfer of rules but are open to arguments. rgds, Eva From es@nrm.se Thu Apr 18 16:12:29 2002 From: es@nrm.se (=?iso-8859-1?Q?Eva_Steng=E5rd?=) Date: Thu, 18 Apr 2002 17:12:29 +0200 (MEST) Subject: [Ietf-not43] use case: selective access In-Reply-To: <1019053507.17838.5.camel@zedonthego.admin.cto.netsol.com> Message-ID: > You have a valid idea here, however I think it is more relevant to the > provisioning side (PROVREG) that this information is collected. I think > the thing for us to understand is that if a registry has such > information, the publication protocol must allow for these rules to be > followed. > Actually, anyone requesting information from a system that includes information that is subject to conditional access needs to state the purpose for which the request is made. To me, that suggests that the protocol has to support this. What goes in or not in the reply will then be a matter of how the rules are implemented in each system. For instance, using the same request, from one database you can get all that has not chosen opt-out for bulk e-mail and from another database you get those that have chosen opt-in for bulk e-mail (perhaps subject to local legal concerns). rgds, Eva From anewton@verisignlabs.com Thu Apr 18 16:48:48 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 18 Apr 2002 11:48:48 -0400 Subject: [Ietf-not43] use case: selective access In-Reply-To: References: Message-ID: <1019144929.21088.18.camel@zedonthego.admin.cto.netsol.com> On Thu, 2002-04-18 at 11:12, Eva Steng=E5rd wrote: > Actually, anyone requesting information from a system that includes > information that is subject to conditional access needs to state the > purpose for which the request is made. To me, that suggests that the > protocol has to support this.=20 I don't disagree with the requirement, I'm just thinking more about the details. I don't necessarily think the protocol needs to support the tagging of the data explicitly but rather the ability for a service to differentiate which users can read certain data (that was tagged perhaps in EPP or something). To me, this would be the ability to conduct authentication for the purpose of applying access controls. But we should definitely look at this to see how it is a requirement. In reply to your earlier email in this thread, I think we need to scope this so that we are talking about a service to publish information from registry/registrar/registrant to end-users for the most part. Bits that flow from registry to registry or registry to registrar might be the subject of PROVREG. -andy From ehall@ehsco.com Thu Apr 18 16:59:22 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 18 Apr 2002 10:59:22 -0500 Subject: [Ietf-not43] use case: selective access References: <3CBC7B8D.C37B4A8A@thinkingcat.com> Message-ID: <3CBEED5A.92813BF7@ehsco.com> Leslie Daigle wrote: > Here's another use case for discussion... It seems to me that this discussion has illustrated that there need to be two systems: a provisioning service which has all information, and a publishing service which provides public information. For delegated resources, the provisioning system is the read-write system, where all updates are made. Updates can only be made on the provisioning system, since that is where most of the flags are kept. The implication from this is that the publishing service is read-only, or that the data provided by the delegation authority MAY be read-only. On the other hand, the nature of the delegated hierarchy is such that the leaf-node entities MAY be read-write. I guess what I'm saying is that the resulting publishing system needs to support multiple kinds of update capabilities, ranging from NONE to FULL, with the specific level being determined by the publishing party. As for authenticated access to full data, I would think that the provisioning system is the natural exposure point, since it is where ALL of the data (including all of the flags) is kept. Even if a user has full access to the publishing service, they will not see all of the falgs from the provisioning service, so those systems are where law enforcement and other actors with court orders would likely prefer to go anyway. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall@ehsco.com Thu Apr 18 17:12:04 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 18 Apr 2002 11:12:04 -0500 Subject: [Ietf-not43] use case: selective access References: <1019144929.21088.18.camel@zedonthego.admin.cto.netsol.com> Message-ID: <3CBEF054.7E35DCE4@ehsco.com> Andrew Newton wrote: > I think we need to scope this so that we are talking about a service > to publish information from registry/registrar/registrant to end-users > for the most part. CRISP should be a system to publish and retrieve a specific set of schema. The source of the data under the schema should be somewhat irrelevant to the operation of the schema. I would think that it would be desirable to ensure that the provisioning and publishing schema are capable of supporting a common database. This means that the provisioning schema should effectively be a superset of the publishing schema (or turn that around if you want, with the publishing schema being a subset of the provisioning schema). ACLs and entry points would determine which schema you worked with. The protocol requirements between these two systems are also somewhat different. An update doesn't require the tree-walks that a query does. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Ted.Hardie@nominum.com Thu Apr 18 17:21:40 2002 From: Ted.Hardie@nominum.com (Ted Hardie) Date: Thu, 18 Apr 2002 09:21:40 -0700 Subject: [Ietf-not43] use case: selective access In-Reply-To: <3CBEED5A.92813BF7@ehsco.com>; from ehall@ehsco.com on Thu, Apr 18, 2002 at 10:59:22AM -0500 References: <3CBC7B8D.C37B4A8A@thinkingcat.com> <3CBEED5A.92813BF7@ehsco.com> Message-ID: <20020418092140.A23826@shell.nominum.com> On Thu, Apr 18, 2002 at 10:59:22AM -0500, Eric A. Hall wrote: > It seems to me that this discussion has illustrated that there need to be > two systems: a provisioning service which has all information, and a > publishing service which provides public information. Let's be clear here that "a provisioning service which has all information" does not imply a global, monolithic service. We've stressed in the past that having one monolithic data store raises a number of serious privacy and fate-sharing problems; I'd hate for folks to believe that the need to provide publishing services drove the need for that sort of thing. I agree with your analysis that the provision system is the read-write system and that CRISP relates to the publish & query interface into that system. I think we've agreed that we're trying to standardize the publish and & query interface here, and that standardizing those interfaces shouldn't force people to use a single (or even a standard) read-write backend. Similarly, I believe the provreg effort means to provide a standard interface for provisioning. without standardize the backend. regards, Ted Hardie From ehall@ehsco.com Thu Apr 18 17:23:58 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 18 Apr 2002 11:23:58 -0500 Subject: [Ietf-not43] use case: selective access References: <1019144929.21088.18.camel@zedonthego.admin.cto.netsol.com> <3CBEF054.7E35DCE4@ehsco.com> Message-ID: <3CBEF31E.93671912@ehsco.com> "Eric A. Hall" wrote: > I would think that it would be desirable to ensure that the provisioning > and publishing schema are capable of supporting a common database. > The protocol requirements between these two systems are also somewhat > different. An update doesn't require the tree-walks that a query does. Examples on this: central delegation authority (eg, ARIN) provisioning system to allocate resources has specific authorization and authentication requirements has large schema has few entry-points publishing system to advertise resources anonymous access to public data has smaller schema has multiple entry-points secondary delegation authority (eg, ISP) provisioning system to further allocate resources can be identical to top-level provisioning service similar auth requirements similar schema requirements small number of entry-points publishing system is identical to global publishing service local auth requirements identical schema requirements identical entry-points leaf-node resource consumer may need provisioning for internal resources can be identical to top-level provisioning service publishing system is identical to global publishing service -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall@ehsco.com Thu Apr 18 17:26:26 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 18 Apr 2002 11:26:26 -0500 Subject: [Ietf-not43] use case: selective access References: <3CBC7B8D.C37B4A8A@thinkingcat.com> <3CBEED5A.92813BF7@ehsco.com> <20020418092140.A23826@shell.nominum.com> Message-ID: <3CBEF3B1.B648C8B8@ehsco.com> Absolutely agree with all of this. Ted Hardie wrote: > > On Thu, Apr 18, 2002 at 10:59:22AM -0500, Eric A. Hall wrote: > > It seems to me that this discussion has illustrated that there need to be > > two systems: a provisioning service which has all information, and a > > publishing service which provides public information. > > Let's be clear here that "a provisioning service which has all > information" does not imply a global, monolithic service. We've > stressed in the past that having one monolithic data store raises a > number of serious privacy and fate-sharing problems; I'd hate for > folks to believe that the need to provide publishing services drove > the need for that sort of thing. > > I agree with your analysis that the provision system is the read-write > system and that CRISP relates to the publish & query interface > into that system. I think we've agreed that we're trying to standardize > the publish and & query interface here, and that standardizing > those interfaces shouldn't force people to use a single (or even > a standard) read-write backend. Similarly, I believe the provreg > effort means to provide a standard interface for provisioning. > without standardize the backend. > regards, > Ted Hardie -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall@ehsco.com Mon Apr 22 16:28:03 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 22 Apr 2002 10:28:03 -0500 Subject: [Ietf-not43] clear delineation of functions Message-ID: <3CC42C03.FA502F67@ehsco.com> I've been thinking about the separation issues some. What about this: CRISP is intended to function as a query-processing interface to the various distributed databases which are commonly used for provisioning Internet resources. Towards this end, CRISP is primarily intended to provide read-only access to databases which contain provisioning data. Administrators of leaf-nodes may also choose to use CRISP as a provisioning tool (either in conjunction with other tools, or as the only tool), although this usage is not a CRISP design objective. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@verisignlabs.com Mon Apr 22 17:22:24 2002 From: anewton@verisignlabs.com (Andrew Newton) Date: 22 Apr 2002 12:22:24 -0400 Subject: [Ietf-not43] clear delineation of functions In-Reply-To: <3CC42C03.FA502F67@ehsco.com> References: <3CC42C03.FA502F67@ehsco.com> Message-ID: <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> On Mon, 2002-04-22 at 11:28, Eric A. Hall wrote: > > I've been thinking about the separation issues some. What about this: > > CRISP is intended to function as a query-processing interface to the > various distributed databases which are commonly used for provisioning > Internet resources. Towards this end, CRISP is primarily intended to > provide read-only access to databases which contain provisioning data. > Administrators of leaf-nodes may also choose to use CRISP as a > provisioning tool (either in conjunction with other tools, or as the only > tool), although this usage is not a CRISP design objective. Well, this isn't what I was refering to. I was simply drawing a distinction between the provisioning protocol or something that might ought to be in it versus the administrative access protocol. Besides, in a system where delegation is so central a concept, where do you draw the line in saying something is a leaf node? Even just looking at the "official" delegations, it varies from TLD to TLD. -andy From ehall@ehsco.com Mon Apr 22 17:42:37 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 22 Apr 2002 11:42:37 -0500 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> Message-ID: <3CC43D7D.5A91F643@ehsco.com> Andrew Newton wrote: > Besides, in a system where delegation is so central a concept, where do > you draw the line in saying something is a leaf node? Good point. Technically a leaf-node doesn't perform delegation (it's a leaf-node). "Resource administrators may also choose to use CRISP as a provisioning tool (either in conjunction with other tools, or as the only tool), although this usage is not a CRISP design objective." -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie@thinkingcat.com Tue Apr 23 03:25:28 2002 From: leslie@thinkingcat.com (Leslie Daigle) Date: Mon, 22 Apr 2002 22:25:28 -0400 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> Message-ID: <3CC4C618.2ABE240B@thinkingcat.com> Howdy, I'm not sure I'd even go this far: "Eric A. Hall" wrote: > "Resource administrators may also choose to use CRISP as a provisioning > tool (either in conjunction with other tools, or as the only tool), > although this usage is not a CRISP design objective." Somebody, sometime, might like to specify some CRISP-friendly provisioning tools, but that is such another kettle of fish that I think it would distract from the design of the appropriate _query_ protocol/service to think that CRISP _could_ be used for provisioning. Leslie. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From ehall@ehsco.com Tue Apr 23 03:31:53 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 22 Apr 2002 21:31:53 -0500 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> Message-ID: <3CC4C799.486874F1@ehsco.com> Leslie Daigle wrote: > Somebody, sometime, might like to specify some CRISP-friendly > provisioning tools, but that is such another kettle of fish that > I think it would distract from the design of the appropriate > _query_ protocol/service to think that CRISP _could_ be used for > provisioning. Yes, I agree with you in a roundabout way. Obviously somebody that is looking at a piece of data *could* edit that data. But what I am really worried about is having to spec things like pushing a distribute update around to all of the delegation servers *shudder* As to the issue which brought all of this up, if we spec CRISP as just a query submission/referral navigation system, then we don't have to worry about the other usages which would further complicate it, and this includes the actor-with-court-order issue. Let's leave them out of it. Those folks should be going to the provisioning system where all of the data presumably exists. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie@thinkingcat.com Tue Apr 23 03:39:50 2002 From: leslie@thinkingcat.com (Leslie Daigle) Date: Mon, 22 Apr 2002 22:39:50 -0400 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> Message-ID: <3CC4C976.80EFA8E9@thinkingcat.com> Howdy, I'm not going to give that one up easily, in that today's whois service is in fact used by law enforcement agencies to dig up information. I don't really think we can sweep that into the backend, or call it a different problem. One intention of the scenario was to illustrate that there is a need to allow differentiated access, and I think we have to explore that -- even if only looking at the query end of the stick. Leslie. "Eric A. Hall" wrote: > As to the issue which brought all of this up, if we spec CRISP as just a > query submission/referral navigation system, then we don't have to worry > about the other usages which would further complicate it, and this > includes the actor-with-court-order issue. Let's leave them out of it. > Those folks should be going to the provisioning system where all of the > data presumably exists. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From ehall@ehsco.com Tue Apr 23 03:53:37 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 22 Apr 2002 21:53:37 -0500 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> <3CC4C976.80EFA8E9@thinkingcat.com> Message-ID: <3CC4CCB0.6E0B9F54@ehsco.com> Leslie Daigle wrote: > I'm not going to give that one up easily, in that today's whois > service is in fact used by law enforcement agencies to dig up > information. The same whois that the rest of us mortals use? I could see that they would use this as a first-round approximation, but I would hope they don't rely on it as a credible source. Billing information from credit cards is where the warrants and subpoenas should go, and that data won't be available through any view of any CRISP schema under discussion. > One intention of the scenario was to illustrate that there > is a need to allow differentiated access, and I think we > have to explore that -- even if only looking at the query > end of the stick. There is absolutely going to be a need for differentiated access within and accross organizations. I don't know if we should formalize access and schema for a specific collection of users however. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie@thinkingcat.com Tue Apr 23 04:17:59 2002 From: leslie@thinkingcat.com (Leslie Daigle) Date: Mon, 22 Apr 2002 23:17:59 -0400 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> <3CC4C976.80EFA8E9@thinkingcat.com> <3CC4CCB0.6E0B9F54@ehsco.com> Message-ID: <3CC4D267.A5EBE33A@thinkingcat.com> Howdy, "Eric A. Hall" wrote: > The same whois that the rest of us mortals use? I could see that they Scary, isn't it? :-) No, it's not that bad -- see below. > would use this as a first-round approximation, but I would hope they don't > rely on it as a credible source. Billing information from credit cards is > where the warrants and subpoenas should go, and that data won't be > available through any view of any CRISP schema under discussion. True -- but we're also talking about FINDING where to direct more, umm, detailed investigations, when the basic contact info is not accessible publicly. And, > > One intention of the scenario was to illustrate that there > > is a need to allow differentiated access, and I think we > > have to explore that -- even if only looking at the query > > end of the stick. > > There is absolutely going to be a need for differentiated access within > and accross organizations. I don't know if we should formalize access and > schema for a specific collection of users however. I (think I) agree, although we'll probably thumb-wrestle more on the details of this later when we get down to specifics... Leslie. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From ehall@ehsco.com Tue Apr 23 04:28:31 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 22 Apr 2002 22:28:31 -0500 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> <3CC4C976.80EFA8E9@thinkingcat.com> <3CC4CCB0.6E0B9F54@ehsco.com> <3CC4D267.A5EBE33A@thinkingcat.com> Message-ID: <3CC4D4DF.88CD116C@ehsco.com> Leslie Daigle wrote: > we're also talking about FINDING where to direct more, umm, detailed > investigations, when the basic contact info is not accessible publicly. Continue. Do you mean that they should be able to determine who the delegating authority is, or that they should be able to view hidden information? The former can be determined from the public view. If the latter, do you mean that a certain group of certificates (or whatever) should get a certain level of permissions, and that we need to document this? Can't we just say "intended to provide read-only access to public information" and then make the lawyers earn their hourlies if they want more than that? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie@thinkingcat.com Tue Apr 23 04:33:05 2002 From: leslie@thinkingcat.com (Leslie Daigle) Date: Mon, 22 Apr 2002 23:33:05 -0400 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> <3CC4C976.80EFA8E9@thinkingcat.com> <3CC4CCB0.6E0B9F54@ehsco.com> <3CC4D267.A5EBE33A@thinkingcat.com> <3CC4D4DF.88CD116C@ehsco.com> Message-ID: <3CC4D5F1.93C21672@thinkingcat.com> Howdy, "Eric A. Hall" wrote: > > Leslie Daigle wrote: > > > we're also talking about FINDING where to direct more, umm, detailed > > investigations, when the basic contact info is not accessible publicly. > > Continue. Do you mean that they should be able to determine who the > delegating authority is, or that they should be able to view hidden > information? The former can be determined from the public view. I mean determining the authority based on a query that is no longer supported in the public view (or across data that is no longer publicly accessible). Such as a search on name -- in VeriSign's whois server today: > Aborting search 10 records found ..... > Daigle (DAIGLEPE-DOM) DAIGLEPE.COM > Daigle (DA24606-OR) stupro@STUPRO.COM 9496424798 > Daigle & Associates (HYPERTEXAS-DOM) HYPERTEXAS.COM > Daigle Communication Graphique (DAIGLECOMMUNICATION-DOM) > DAIGLECOMMUNICATION.COM > Daigle Design (ROCKREQUIEM-DOM) ROCKREQUIEM.COM > Daigle Design (KITCHENSUPPLIES2-DOM) KITCHENSUPPLIES.COM > Daigle Design (TOWNCAM3-DOM) TOWNCAM.NET > Daigle Design (WINDOWSHOPPINGUSA-DOM) WINDOWSHOPPINGUSA.COM > Daigle Design (JETFLYER2-DOM) JETFLYER.NET > Daigle Design (WELLSBLOOMFIELD-DOM) WELLSBLOOMFIELD.COM > > > If the latter, do you mean that a certain group of certificates (or > whatever) should get a certain level of permissions, and that we need to > document this? Can't we just say "intended to provide read-only access to > public information" and then make the lawyers earn their hourlies if they > want more than that? One possibility is to provide the ability to support class-like certificates. Everything else is, indeed, someone else's job. Leslie. -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From ehall@ehsco.com Tue Apr 23 04:56:40 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 22 Apr 2002 22:56:40 -0500 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> <3CC4C976.80EFA8E9@thinkingcat.com> <3CC4CCB0.6E0B9F54@ehsco.com> <3CC4D267.A5EBE33A@thinkingcat.com> <3CC4D4DF.88CD116C@ehsco.com> <3CC4D5F1.93C21672@thinkingcat.com> Message-ID: <3CC4DB77.7C240E0F@ehsco.com> Leslie Daigle wrote: > I mean determining the authority based on a query that is > no longer supported in the public view (or across data that > is no longer publicly accessible). If the data is no longer available or is no longer public, then I don't know what good a system which is designed primarily for read-only access to public data would be. At that point they need to get access to the backups or some other part of the provisioning system. > One possibility is to provide the ability to support class-like > certificates. I know we're just bouncing ideas around, but refresh your memory with http://www.washingtonpost.com/wp-srv/WPlate/1999-11/10/110l-111099-idx.html and ask Fred Baker about it. I don't think you'll get a very different response on this one. Same hot-buttons. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie@thinkingcat.com Tue Apr 23 16:07:21 2002 From: leslie@thinkingcat.com (Leslie Daigle) Date: Tue, 23 Apr 2002 11:07:21 -0400 Subject: [Ietf-not43] clear delineation of functions References: <3CC42C03.FA502F67@ehsco.com> <1019492545.3983.9.camel@zedonthego.admin.cto.netsol.com> <3CC43D7D.5A91F643@ehsco.com> <3CC4C618.2ABE240B@thinkingcat.com> <3CC4C799.486874F1@ehsco.com> <3CC4C976.80EFA8E9@thinkingcat.com> <3CC4CCB0.6E0B9F54@ehsco.com> <3CC4D267.A5EBE33A@thinkingcat.com> <3CC4D4DF.88CD116C@ehsco.com> <3CC4D5F1.93C21672@thinkingcat.com> <3CC4DB77.7C240E0F@ehsco.com> Message-ID: <3CC578A9.292E6C2@thinkingcat.com> Disagree. The definition of "public" is perhaps at fault -- I am attempting to distinguish between that data which is anonymously accessible to any user of the Internet, and that which requires authenticated, or at least non-anonymous, access. All the data in question may be considered "public", or at least not "private". Leslie. "Eric A. Hall" wrote: > > Leslie Daigle wrote: > > > I mean determining the authority based on a query that is > > no longer supported in the public view (or across data that > > is no longer publicly accessible). > > If the data is no longer available or is no longer public, then I don't > know what good a system which is designed primarily for read-only access > to public data would be. At that point they need to get access to the > backups or some other part of the provisioning system. > > > One possibility is to provide the ability to support class-like > > certificates. > > I know we're just bouncing ideas around, but refresh your memory with > http://www.washingtonpost.com/wp-srv/WPlate/1999-11/10/110l-111099-idx.html > and ask Fred Baker about it. I don't think you'll get a very different > response on this one. Same hot-buttons. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.research.netsol.com > http://lists.research.netsol.com/mailman/listinfo/ietf-not43 -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From Ted.Hardie@nominum.com Thu Apr 25 23:24:59 2002 From: Ted.Hardie@nominum.com (Ted Hardie) Date: Thu, 25 Apr 2002 15:24:59 -0700 Subject: [Ietf-not43] Proposed charter Message-ID: <20020425152459.A67618@shell.nominum.com> Howdy, Based on the discussions we've had since the last IETF, I believe that the scope of the CRISP work has been narrowed to a focus on DNS-related registries, registrars, and registrants. Though I believe that there is value from a user perspective for a more general approach, I believe that deployment of such services is unlikely among other infrastructure registries using similar administrative directory services. Given that, I have put together the following straw charter, which is narrower in focus than those discussed at previous BoF sessions. Comments to the list are welcome. regards, Ted Hardie Cross-Registry Information Service Protocol (CRISP) Chair: Ted Hardie Applications Area Directors: Patrik Falstrom Ned Freed Mailing list: ietf-not43@lists.verisignlabs.com Archive/Subscription: https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 Description of Working Group: The expansion and growth of the Internet Domain Name System has seen the functions of a traditionally centralized and managed registry become the responsibility of various autonomous, functionally disparate, and globally distributed Internet registries and registrars. With that expansion, the uses of administrative directory services has also expanded from the original use of the WHOIS protocol to include: the use of whois outside the scope its specification; formal and informal definitions of syntax; undocumented security mechanisms; the use of non-standard protocols, etc. The existing situation seriously hinders interoperability from a registrant perspective, as multiple systems and procedures must be used for different registrars or registries. This working group will define a new standard service to meet the administrative directory needs requirements of DNS registrants, registrars, and registries. While the framework created will hopefully be sufficiently flexible to allow re-use by other services with related design criteria, those uses will not constrain protocol selection. Backwards compatibility with existing administrative directory services such as WHOIS is not a goal of this effort. Provisioning of data into registry or registrar systems is likewise out of scope. The CRISP service definition will define: o specific data types and queries to be supported in the global service o standard process for naming or locating authoritative servers o expression of input query o expression of result sets o standard expression of error conditions o authentication and verification of data integrity Deliverables: o Finalized requirements document for the CRISP service o Document specifying (the use of) a protocol for providing CRISP standard service. Goals and Milestones: Oct 02 Submit requirements document as an Informational RFC Nov 02 Submit first draft of protocol (use) specification Apr 03 Submit revised protocol (use) specification document as Proposed Standard. Apr 03 Enter FIN_WAIT From ehall@ehsco.com Fri Apr 26 16:08:39 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Fri, 26 Apr 2002 10:08:39 -0500 Subject: [Ietf-not43] Proposed charter References: <20020425152459.A67618@shell.nominum.com> Message-ID: <3CC96D77.51148DF6@ehsco.com> [note to list, not43 comes from lists.verisignlabs.com now, in case you need to update your filters] Ted Hardie wrote: > This working group will define a new standard service to meet the > administrative directory needs requirements of DNS registrants, > registrars, and registries. While the framework created will > hopefully be sufficiently flexible to allow re-use by other services > with related design criteria, those uses will not constrain protocol > selection. As stated earlier, there are considerations with the core schema which make an isolated design impossible, or unusable to the point of not bothering to try. What I would propose is that the WG separate the core protocol and core schema into a standards-track document, and that we publish whatever supporting schema we think will be needed as secondary specs, with those schema being on a standards-track or informational as appropriate. If the interest picks up, the informational specs can be edited/replaced by the external parties and the core won't be affected. This approach will also help as we introduce more schema later. I am noodling with a user-locator schema to address one of Leslie's concerns, for example. Using the LDAP-WHOIS model as an example, this would mean a core spec which defined the service (top-down vs bottom-up searches, namespace delegation, etc) and the main scheme (inetResources), while the other object classes (inetDnsDomain, inetIpv4Network, inetIpv6Network, and inetAsNumber, plus whatever new ones) would be defined in separate specs. The core and inetDnsDomain schema would be standards-track, while the others would be informational. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Fri Apr 26 18:01:27 2002 From: anewton@ecotroph.net (Andrew Newton) Date: Fri, 26 Apr 2002 13:01:27 -0400 Subject: [Ietf-not43] Proposed charter References: <20020425152459.A67618@shell.nominum.com> <3CC96D77.51148DF6@ehsco.com> Message-ID: <3CC987E7.940686F1@ecotroph.net> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zark.ecotroph.net-21259-1019835201-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Eric A. Hall" wrote: > > [note to list, not43 comes from lists.verisignlabs.com now, in case you > need to update your filters] Sorry about that. It would seem a certain sys admin made some modifications to the list server without notifying us (not the least of which was taking me off the list inadvertently). If anyone is experiencing any other problems, please let me know off-list. > Ted Hardie wrote: > > > This working group will define a new standard service to meet the > > administrative directory needs requirements of DNS registrants, > > registrars, and registries. While the framework created will > > hopefully be sufficiently flexible to allow re-use by other services > > with related design criteria, those uses will not constrain protocol > > selection. > > What I would propose is that the WG separate the core protocol and core > schema into a standards-track document, and that we publish whatever > supporting schema we think will be needed as secondary specs, with those > schema being on a standards-track or informational as appropriate. If the > interest picks up, the informational specs can be edited/replaced by the > external parties and the core won't be affected. This approach will also > help as we introduce more schema later. I am noodling with a user-locator > schema to address one of Leslie's concerns, for example. I don't think anybody is suggesting we don't take a layered approach. However, a charter for a general framework will not fly with the IESG (so I'm told). We need to charter for solving a problem. A general framework does not solve a problem, it is merely a smart approach to a solution. Given the following from the charter: > While the framework created will > hopefully be sufficiently flexible to allow re-use by other services > with related design criteria, those uses will not constrain protocol > selection. I think this strikes the right balance between we have an immediate problem we want to solve (domains) while saying "we aren't going to be so narrow that we come up with something that cannot even solve related matters" and at the same time say "we aren't going to be so broad as to be considered fixing the entire universe." There has to be balance. And we cannot propose a charter for a solution looking for a problem to solve. -andy --=_zark.ecotroph.net-21259-1019835201-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIII9AYJKoZIhvcNAQcCoIII5TCCCOECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BkYwggMGMIICb6ADAgECAgMHMt4wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA0MTAxODU4MjBaFw0wMzA0MTAxODU4MjBa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGFu ZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5Kc4 10hpxiGBE08UE3H/qKMXC/cx3lQeVKk7/dKSUNZkspeOXZiH/oFyl9tQtcIxQ216EvXo53T1 2QBB044fo+CkitDYvt1zZSHLQY9cBDR3s8FqA7HVHOAyC7BMqUPaSBaliaXDOlPbXBxOkuGY sBdRAzRv51UdW3HoWAhkGBWCzMCVMru7e1ZGrwtrYqaWXJN37spr7QgHdVmXhjOSu7rMmiDC UW5IneJomR+nHNiFmjqFqMxFpJw/5MmdjPCjS8iVwbSU0QpFepenIc/Fr0pBH/qDlEX1Tawr sLlRJA+npwO97b2VViAdajF35k+6c7ZMl4C5NAF0fvN6qzEWfQIDAQABozEwLzAfBgNVHREE GDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAHF4Ljf5CziCiMSNwm++3gO/XyAXz0aPUNoQNtPj+C3CndMZIgKsxIUnYbLM0EYcZFDZ O2QTpLB53zq2hT1sdPs3YpgXkJY31s+JsT6zOR6zDYYtdqNuE0cb/BzIZIzhRJlcl3M7zHoy h/0PnY54cc7m6StJtmfbc2n/sCu1YCoyMIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6R ATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRx oKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGH gzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3 J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBd avl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYICdjCCAnICAQEw gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBzLeMAkGBSsO AwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIw NDI2MTcwMTI3WjAjBgkqhkiG9w0BCQQxFgQUPer7BpvkWisrEPkGZVH2cYy6P6cwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZI hvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEATR/fm1TAVZtZ7Loo 7Q25iSxsgXFqQJh+KI4gVGO+MBIRfy3t/3bvx730LzaxeOocX7FheDNzKKqixlF5N15eHnJx hzw2VVf9d+UFYGbArFNO+oDnKd2sm8riZVzz1iFOhQ9v8FME01ST9gdH2qOM9SLSgGjN6ryS XjumD/ylnhd5S/S/GJGOJjj+ZnAd8Q1kscPunenTwDAycbV0STuIcL/OOo44qsJmRjRBM9dy BV8Tm0PfoviZdfqDrW87U1nI6plLTQJAGGp8aHotLWoJwuB5Qb+TH68WeKje8khmrx0rsSDb 4ci51XQLBzjl0KRqrZUdd8RkaZiCCoIMRom2QA== --=_zark.ecotroph.net-21259-1019835201-0001-2-- From ehall@ehsco.com Fri Apr 26 18:21:54 2002 From: ehall@ehsco.com (Eric A. Hall) Date: Fri, 26 Apr 2002 12:21:54 -0500 Subject: [Ietf-not43] Proposed charter References: <20020425152459.A67618@shell.nominum.com> <3CC96D77.51148DF6@ehsco.com> <3CC987E7.940686F1@ecotroph.net> Message-ID: <3CC98CB1.2E5126C3@ehsco.com> Andrew Newton wrote: > > What I would propose is that the WG separate the core protocol and > > core schema into a standards-track document, and that we publish > > whatever supporting schema we think will be needed as secondary > > specs, with those schema being on a standards-track or informational > > as appropriate. > I don't think anybody is suggesting we don't take a layered approach. > However, a charter for a general framework will not fly with the IESG > (so I'm told). We need to charter for solving a problem. A general > framework does not solve a problem, it is merely a smart approach to a > solution. I'm not suggesting that the additional schema or that a framework be specified as a charter. I'm suggesting that we define two deliverables, one of which is the core proto/schema, and another of which is the inetDnsDomain schema. Furthermore, I'm suggesting that we (or me, if that's the politically expedient method) publish the ancillary schema as informational so that the core schema can reference the data-types when it needs to do so. Is that workable? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Fri Apr 26 18:48:15 2002 From: anewton@ecotroph.net (Andrew Newton) Date: Fri, 26 Apr 2002 13:48:15 -0400 Subject: [Ietf-not43] Proposed charter References: <20020425152459.A67618@shell.nominum.com> <3CC96D77.51148DF6@ehsco.com> <3CC987E7.940686F1@ecotroph.net> <3CC98CB1.2E5126C3@ehsco.com> Message-ID: <3CC992DF.DC31FDD6@ecotroph.net> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zark.ecotroph.net-21851-1019838009-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Eric A. Hall" wrote: > > I'm not suggesting that the additional schema or that a framework be > specified as a charter. I'm suggesting that we define two deliverables, > one of which is the core proto/schema, and another of which is the > inetDnsDomain schema. Furthermore, I'm suggesting that we (or me, if > that's the politically expedient method) publish the ancillary schema as > informational so that the core schema can reference the data-types when it > needs to do so. > > Is that workable? Sorry for the misinterpretation. I think the two deliverables is workable. -andy --=_zark.ecotroph.net-21851-1019838009-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIII9AYJKoZIhvcNAQcCoIII5TCCCOECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BkYwggMGMIICb6ADAgECAgMHMt4wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA0MTAxODU4MjBaFw0wMzA0MTAxODU4MjBa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGFu ZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5Kc4 10hpxiGBE08UE3H/qKMXC/cx3lQeVKk7/dKSUNZkspeOXZiH/oFyl9tQtcIxQ216EvXo53T1 2QBB044fo+CkitDYvt1zZSHLQY9cBDR3s8FqA7HVHOAyC7BMqUPaSBaliaXDOlPbXBxOkuGY sBdRAzRv51UdW3HoWAhkGBWCzMCVMru7e1ZGrwtrYqaWXJN37spr7QgHdVmXhjOSu7rMmiDC UW5IneJomR+nHNiFmjqFqMxFpJw/5MmdjPCjS8iVwbSU0QpFepenIc/Fr0pBH/qDlEX1Tawr sLlRJA+npwO97b2VViAdajF35k+6c7ZMl4C5NAF0fvN6qzEWfQIDAQABozEwLzAfBgNVHREE GDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAHF4Ljf5CziCiMSNwm++3gO/XyAXz0aPUNoQNtPj+C3CndMZIgKsxIUnYbLM0EYcZFDZ O2QTpLB53zq2hT1sdPs3YpgXkJY31s+JsT6zOR6zDYYtdqNuE0cb/BzIZIzhRJlcl3M7zHoy h/0PnY54cc7m6StJtmfbc2n/sCu1YCoyMIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6R ATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRx oKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGH gzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3 J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBd avl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYICdjCCAnICAQEw gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBzLeMAkGBSsO AwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIw NDI2MTc0ODE1WjAjBgkqhkiG9w0BCQQxFgQU/KmbTMvdarnm2PQWVew4ikN3wdIwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZI hvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAYtAdOkjHNJcnUaSv LI1vRn0qUnoGjGDuio88S8VdulXombSDkrBPAsVFCJOolbUorr3NXke1qUVvDsu/XCKq0+ku MKI7qFbLqYhdr0dRaWeEZa0EZBkw3pN9EewenSON+6h4YqJi4X8z0gPS60ve54qrO8sW6xXv 49BoJ1dWG9xH5L+uvCxRpHtTBqXprZ9Nnh0RMZalRyd9Hx/LTJLBp1EtUb1ul3obAuYZXY1o qTt82m2bWOsO0buQPXPoCUNg+CvNOPkcLTOdQHsdrFCNTo9aE+v8DkRgp+KQXUVd+apTAXAe 9x95wotCQi3xz5OleUmVOxLjjCr1qS4cvv1ufw== --=_zark.ecotroph.net-21851-1019838009-0001-2--