From ehall@ehsco.com Mon Jan 13 23:13:24 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Mon, 13 Jan 2003 17:13:24 -0600 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-02.txt In-Reply-To: <3E0A525C.20602@ehsco.com> References: <200211051103.GAA09878@ietf.org> <3E0A525C.20602@ehsco.com> Message-ID: <3E234814.1010707@ehsco.com> Presumably the original post was lost to many people as part of the post-xmas purging. on 12/25/2002 6:50 PM Eric A. Hall wrote: > A couple of additional comments on the requirements draft > > 1) slight rewording of 3.1.3 > > | 3.1.3 Standard and Extensible Schemas > | > | The service MUST define standard schemas for the exchange of data > | needed to implement the functionality in this document. In addition, > | there MUST be a means to allow the use of schemas not defined by the > | needs of this document. Both types of schemas MUST use the same > | schema language. The schemas MUST be able to express data elements > | with identifying tags for the purpose of localization of > | internationalized data element labels > > The last sentence seems to imply that i18n data is to be expressly > identified when the only real concern is that the service be able to > accomodate this data, whether tagged or not. Localization tagging is > another issue, and that kind of tagging should be provided when the > untagged form would cause corruption. > > I would therefore suggest that the sentence be rewritten as "The schemas > MUST be able to accomodate internationalized data elements, and MUST be > able to denote any localized forms of any data which would otherwise cause > interoperability problems." > > 2) Does section 3.2.3 define a requirement for an organizational lookup, > similar to but different (larger) than the contact lookup as defined in > section 3.2.1? For example, does it mean that rather than finding all of > the domains I may have registered over the years, I need to be able to > find all of the domains that were registered under the name of my company > or one of my clients? > > This would involve defining something that could be used as an org-handle > and then finding something to map this onto, which isn't as simple as just > mapping an email address (and even that isn't easy). > > I think this is a good idea and an interesting feature which would give > clear benefit over legacy WHOIS. I just want to make sure I'm reading it > as what I think it is? > > Can we change this to a SHOULD? I note for effect that section 3.2.5 only > calls for a MAY requirement, and that is existing functionality. > > 3) I'd like to see a requirement for versioning. In those cases where the > nature of the protocol, schema or data elements need to be adjusted, there > will be a need for end-stations to negotiate or identify the version(s) in > use. I guarantee this will happen. For example, in the case of LDAP-WHOIS, > it may be that the core schema has to be extended, or that a specific > schema associated with a specific resource has to be redefined. > > I feel sufficiently strongly about this that I think it should be a MUST > requirement. EG, "Service proposals MUST provide mechanisms for > identifying and/or negotiating the version of the protocol, schema, or > data elements which constitute the service to an extent that any or all of > these may be changed and the service will continue to function." > -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From vb@bertola.eu.org Tue Jan 14 09:49:16 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Tue, 14 Jan 2003 10:49:16 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document Message-ID: Hello, first of all, this is the first time I take part in an IETF working group. Please pardon me for any inappropriate behaviour I might unvoluntarily have. I have discovered the existence of this group only in the last few weeks, thanks to a post on ICANN's General Assembly list. Though being an ICT engineer, I do not work for any DNS-related company, and in this field I am more interested in the policy aspects related to individual users of the Internet, than in the actual technical details. This is why (speaking personally, and not for any of the orgs I participate in) I really want to say a couple of things about the draft requirements document, and in particular about a couple of paragraphs that I find really worrying. a) =A72.4.2 >Intellectual Property Holders have legal rights to the use of domain >names based on copyright and trademark laws of various governments. This statement is clearly incorrect. In fact, according to international trademark law (but also to the UDRP), trademark owners have a right not to see domain names equal or confusingly similar to their trademarks used for improper competition or registered in bad faith with the purpose of resale. However, they have no specific "right to the use" of a domain name. Not all trademark owners on a given alphanumeric string own the same string as a domain name - often it is owned by the owner of a trademark on the same string in another country or commercial sector, or by a non-trademark owner who is not using it to infringe the trademark rights. This is perfectly legitimate and shows that there is no "right to the use", but only a right not to see it used by someone else in an infringing way. Moreover, most countries recognize other potential rights on alphanumeric strings - for example, individuals have a right to their identity and to prevent defamation (so "john-doe-is-a-jerk.com" might be illegal in many countries), or countries and other geopolitical entities have some rights to monitor and restrict the usage of their names. I think that the IETF should not enter into the (mined) field of stating who has legal rights to the use of domain names - something which is not a technical task at all. So I would definitely suggest that you wipe this paragraph out completely. However, if you want to keep it as an informational statement, I suggest it is substituted with a more balanced sentence such as: "A number of parties, such as trademark, service mark and intellectual property holders, individuals, governments and other geopolitical entities, have some legal rights on certain alphanumeric strings. They use the directory services of Internet registries, mostly domain registries and registrars, for purposes of maintaining and defending claims to domain names consistent with applicable laws and regulations." b) =A73.2.3 This feature, if deployed widely, would in practice allow to track down the worldwide DNS activities of a given registrant with a single query. Especially in the case when this registrant is an individual and has not specifically consented to this, this would constitute an unacceptable break of the personal privacy, and would likely be illegal under the laws of many countries (for example the European Union). Similar concerns may apply to other types of search designed in the document. If such technical capabilities are to be developed, IMHO it is mandatory that at the same time other technical capabilities are added to allow for a simple implementation of the protections to people's privacy required by law. In the absence of this, the specifications and the resulting implementations and services will either be deployed illegally or discarded because of their illegality. In both cases, the specifications will be practically useless or even damaging. Practically, I think that the service should be able to classify data (not by class, but at the level of a single data field entry of a single domain name, to allow for the maximum flexibility) as "private" if the registrant has not consented to distribute them publicly through the service. Queries by domain name must return a standard string (for example "") when the required field contains an entry marked as private. Queries by other fields must not return results when the lookup string is found inside an entry marked as private. As an exception to this, the system should be able to support "full access" authenticated accounts that can query the private entries too - to be distributed to law enforcement and investigation agencies. Of course the requirements should not enter into discussing which fields should be allowed to be marked public or private, and under which conditions, or who should be able to get full access accounts - these are policy issues that are likely to be defined by each registry's applicable law and by the local community. But it is important that the protocol has the flexibility to allow each registry to adopt its own policy without being bound by technical limitations. Perhaps this could be accomplished by the "privilege" mechanism described in =A73.1.4. However, as I have been told that that mechanism was designed for other purposes, what I propose is to add a new paragraph among the base functions. I have tried to draft it, but certainly there are people here who can do it better than me... however here it is: "3.1.12 Privacy Protection Support The service MUST be capable of associating to the value of each field of each row of data (e.g. domain name or address block) a flag marking the value as "private". Queries MUST NOT return those results for which the value of the queried field matches the query but is marked as "private". In this case, the service MUST NOT give indication that a private result was found. Results of queries which include values that have been marked as "private" MUST substitute those values with the standard string "" before sending back the result to the user. As the only exception to this, the service MUST be capable of authenticating entities who have a right to full access to the database (i.e. those described in 2.4.3). For all queries submitted by such entities after authentication, all values marked as "private" will be considered as if they were not marked. All other levels of access (either anonymous or authenticated) MUST NOT have any way to access data marked as "private"." As a further enhancement, the system could support more than one level of privacy (for example: total privacy, publicity only for non-commercial and statistic use, total publicity) but it would get even more complex and depending on local policies. I think that the mechanism described above would already be a great step forward. --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From bortzmeyer@nic.fr Tue Jan 14 13:35:37 2003 From: bortzmeyer@nic.fr (Stephane Bortzmeyer) Date: Tue, 14 Jan 2003 14:35:37 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: References: Message-ID: <20030114133537.GA12463@nic.fr> On Tue, Jan 14, 2003 at 10:49:16AM +0100, Vittorio Bertola wrote a message of 142 lines which said: > Practically, I think that the service should be able to classify data > (not by class, but at the level of a single data field entry of a > single domain name, to allow for the maximum flexibility) as "private" > if the registrant has not consented to distribute them publicly > through the service. Queries by domain name must return a standard > string (for example "") when the required field contains an It should be noted there is currently a difficult discussion on the companion IETF Working Group ProvReg (which tries to standardize the registry interface for modifications, Crisp dealing with "read-only" queries). The IESG froze the progress of the EPP protocol documents to the RFC level because of privacy concerns (the lack of a standard way to express privacy preferences for the registrant). A good part of the discussion revolves around wether a simple binary (Disclose/doNotDisclose) capability is better than nothing or if we should use a full-fledged system like W3C's P3P to express privacy preferences. From shollenbeck@verisign.com Tue Jan 14 13:44:53 2003 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Tue, 14 Jan 2003 08:44:53 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements docum ent Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337050D@vsvapostal3.prod.netsol.com> > The IESG froze the progress of the EPP protocol documents to the RFC > level because of privacy concerns (the lack of a standard way to > express privacy preferences for the registrant). Not quite true. The IESG sent back a review comment that the WG has yet to reach consensus on. Once the WG gets its act together, the IESG will likely approve the documents. This is very different than the IESG putting a stop to the effort. -Scott- From vb@bertola.eu.org Tue Jan 14 14:04:07 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Tue, 14 Jan 2003 15:04:07 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements docum ent In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337050D@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337050D@vsvapostal3.prod.netsol.com> Message-ID: On Tue, 14 Jan 2003 08:44:53 -0500, you wrote: >> The IESG froze the progress of the EPP protocol documents to the RFC >> level because of privacy concerns (the lack of a standard way to >> express privacy preferences for the registrant). > >Not quite true. The IESG sent back a review comment that the WG has yet= to >reach consensus on. Once the WG gets its act together, the IESG will = likely >approve the documents. This is very different than the IESG putting a = stop >to the effort. Anyway, it seems to me that given the request by the IESG for proper privacy addressing in the provisioning protocol, a similar objection is likely to be raised if this protocol does not do the same. IMHO, this is one more reason to add some privacy-related provision to the crisp requirements too. Moreover, implementing privacy on this side of the system is easier, because independently from the complexity of the choices and algorithms that may be applied during provisioning and retrieval to determine the level of privacy of the value, from the point of view of answering queries, either the value is private in regard to the query's authentication level or it is not - so a binary value might be enough after all. --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From anewton@ecotroph.net Tue Jan 14 14:21:21 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 14 Jan 2003 09:21:21 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: References: Message-ID: <3E241CE1.7080900@ecotroph.net> Vittorio, The inclusion of 2.4.2 and most of section 2 is to scope the problem. However, there is no use of MUST/SHOULD language there and we are not attempting to define an intellectual property holder. This section just describes the user scope. That being said, I have no problems with your proposed substitution. It sounds reasonable to me. Regarding your proposal for 3.1.12: this seems to actually specify policy, which is probably not universal. I also so no need for the protocol to specify "this thing is private". Either the user has authorization to see the data or they don't. This seems more appropriate for the provisioning side (see the current fuss in the PROVREG WG). In addition, the access levels and privilege levels in the current document seem to only indicate two tiers. This is a mistake and will be corrected. The intent is that there may be multiple levels of access defined by the policy used by the operator. 3.1.4 needs to be rewritten, but there is no reason why it wouldn't apply to 3.2.3. From the text of section 3: For instance, this document may say that the service "MUST" support search features. An actual service operator is always free to disable it (and then to return an error such as "permission denied"). -andy Vittorio Bertola wrote: > Hello, > > first of all, this is the first time I take part in an IETF working > group. Please pardon me for any inappropriate behaviour I might > unvoluntarily have. > > I have discovered the existence of this group only in the last few > weeks, thanks to a post on ICANN's General Assembly list. Though being > an ICT engineer, I do not work for any DNS-related company, and in > this field I am more interested in the policy aspects related to > individual users of the Internet, than in the actual technical > details. This is why (speaking personally, and not for any of the orgs > I participate in) I really want to say a couple of things about the > draft requirements document, and in particular about a couple of > paragraphs that I find really worrying. > > > a) §2.4.2 > > >>Intellectual Property Holders have legal rights to the use of domain >>names based on copyright and trademark laws of various governments. > > > This statement is clearly incorrect. In fact, according to > international trademark law (but also to the UDRP), trademark owners > have a right not to see domain names equal or confusingly similar to > their trademarks used for improper competition or registered in bad > faith with the purpose of resale. However, they have no specific > "right to the use" of a domain name. Not all trademark owners on a > given alphanumeric string own the same string as a domain name - often > it is owned by the owner of a trademark on the same string in another > country or commercial sector, or by a non-trademark owner who is not > using it to infringe the trademark rights. This is perfectly > legitimate and shows that there is no "right to the use", but only a > right not to see it used by someone else in an infringing way. > > Moreover, most countries recognize other potential rights on > alphanumeric strings - for example, individuals have a right to their > identity and to prevent defamation (so "john-doe-is-a-jerk.com" might > be illegal in many countries), or countries and other geopolitical > entities have some rights to monitor and restrict the usage of their > names. > > I think that the IETF should not enter into the (mined) field of > stating who has legal rights to the use of domain names - something > which is not a technical task at all. So I would definitely suggest > that you wipe this paragraph out completely. However, if you want to > keep it as an informational statement, I suggest it is substituted > with a more balanced sentence such as: > > "A number of parties, such as trademark, service mark and intellectual > property holders, individuals, governments and other geopolitical > entities, have some legal rights on certain alphanumeric strings. They > use the directory services of Internet registries, mostly domain > registries and registrars, for purposes of maintaining and defending > claims to domain names consistent with applicable laws and > regulations." > > > b) §3.2.3 > > This feature, if deployed widely, would in practice allow to track > down the worldwide DNS activities of a given registrant with a single > query. Especially in the case when this registrant is an individual > and has not specifically consented to this, this would constitute an > unacceptable break of the personal privacy, and would likely be > illegal under the laws of many countries (for example the European > Union). Similar concerns may apply to other types of search designed > in the document. > > If such technical capabilities are to be developed, IMHO it is > mandatory that at the same time other technical capabilities are added > to allow for a simple implementation of the protections to people's > privacy required by law. In the absence of this, the specifications > and the resulting implementations and services will either be deployed > illegally or discarded because of their illegality. In both cases, the > specifications will be practically useless or even damaging. > > Practically, I think that the service should be able to classify data > (not by class, but at the level of a single data field entry of a > single domain name, to allow for the maximum flexibility) as "private" > if the registrant has not consented to distribute them publicly > through the service. Queries by domain name must return a standard > string (for example "") when the required field contains an > entry marked as private. Queries by other fields must not return > results when the lookup string is found inside an entry marked as > private. As an exception to this, the system should be able to support > "full access" authenticated accounts that can query the private > entries too - to be distributed to law enforcement and investigation > agencies. > > Of course the requirements should not enter into discussing which > fields should be allowed to be marked public or private, and under > which conditions, or who should be able to get full access accounts - > these are policy issues that are likely to be defined by each > registry's applicable law and by the local community. But it is > important that the protocol has the flexibility to allow each registry > to adopt its own policy without being bound by technical limitations. > > Perhaps this could be accomplished by the "privilege" mechanism > described in §3.1.4. However, as I have been told that that mechanism > was designed for other purposes, what I propose is to add a new > paragraph among the base functions. I have tried to draft it, but > certainly there are people here who can do it better than me... > however here it is: > > > "3.1.12 Privacy Protection Support > > The service MUST be capable of associating to the value of each field > of each row of data (e.g. domain name or address block) a flag marking > the value as "private". > > Queries MUST NOT return those results for which the value of the > queried field matches the query but is marked as "private". In this > case, the service MUST NOT give indication that a private result was > found. > > Results of queries which include values that have been marked as > "private" MUST substitute those values with the standard string > "" before sending back the result to the user. > > As the only exception to this, the service MUST be capable of > authenticating entities who have a right to full access to the > database (i.e. those described in 2.4.3). For all queries submitted by > such entities after authentication, all values marked as "private" > will be considered as if they were not marked. All other levels of > access (either anonymous or authenticated) MUST NOT have any way to > access data marked as "private"." > > > As a further enhancement, the system could support more than one level > of privacy (for example: total privacy, publicity only for > non-commercial and statistic use, total publicity) but it would get > even more complex and depending on local policies. I think that the > mechanism described above would already be a great step forward. From ehall@ehsco.com Tue Jan 14 17:20:35 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Tue, 14 Jan 2003 11:20:35 -0600 Subject: [Ietf-not43] Suggestions of changes to the requirements docum ent In-Reply-To: References: <3CD14E451751BD42BA48AAA50B07BAD60337050D@vsvapostal3.prod.netsol.com> Message-ID: <3E2446E3.5020506@ehsco.com> on 1/14/2003 8:04 AM Vittorio Bertola wrote: > Moreover, implementing privacy on this side of the system is easier, There is nothing to be gained from doing so. > because independently from the complexity of the choices and > algorithms that may be applied during provisioning and retrieval to > determine the level of privacy of the value, from the point of view of > answering queries, either the value is private in regard to the > query's authentication level or it is not - so a binary value might be > enough after all. Privacy requirements vary by jurisdiction. Any data which may be returned has to be presumed as being allowed by the jurisdiction under which that server operates. Adding bits and widgets to the protocol or data will not affect this. If some greater level of privacy is desired, users can register with a provider who offers it, or can attempt to change the privacy rules for the governing jurisdiction of their preferred registry. Adding bits and widgets to the protocol or data will not affect this, either. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From vb@bertola.eu.org Mon Jan 20 10:12:33 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Mon, 20 Jan 2003 11:12:33 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <3E241CE1.7080900@ecotroph.net> References: <3E241CE1.7080900@ecotroph.net> Message-ID: On Tue, 14 Jan 2003 09:21:21 -0500, you wrote: >Vittorio, > >The inclusion of 2.4.2 and most of section 2 is to scope the problem.=20 >However, there is no use of MUST/SHOULD language there and we are not=20 >attempting to define an intellectual property holder. This section just= =20 >describes the user scope. That being said, I have no problems with your= =20 >proposed substitution. It sounds reasonable to me. Thanks :-) The proposed substitution is intended to preserve the informational value without upsetting any policy-oriented reader :-)) >Regarding your proposal for 3.1.12: this seems to actually specify=20 >policy, which is probably not universal. Well - in my opinion, it was not meant to specify policy, but rather, to define the meaning of the "private" value when attached to a field. There's no mention of which data should be marked as private, or how, or by whom, or under which conditions - it just defines that the "private" flag has some consequences on the behaviour of the service, i.e. that data must not be shown unless to specially authorized queries. >I also so no need for the=20 >protocol to specify "this thing is private". Either the user has=20 >authorization to see the data or they don't. So you should simply omit private fields from answers, rather than substituting them with a warning message such as "", as per my proposal? Personally, I think that there should be an explicit and standard "" answer, because it will allow the user (and the maintainer of the service) to tell between incomplete or missing answers that happen because the rest of the data are private, and incomplete or missing answers that happen because of a bug in the implementation, a fault, or a problem in the data base. Otherwise you may risk that users try again and again to submit queries that do not receive complete answers due to privacy settings, because they think they were incomplete due to a temporary fault. The only exception to this is when the private field is the one that your lookup string is matching - in this case, indicating that a private match has been found is an information that should not be given to the user, as it would put the privacy of the value at risk. >In addition, the access levels and privilege levels in the current=20 >document seem to only indicate two tiers. This is a mistake and will be= =20 >corrected. The intent is that there may be multiple levels of access=20 >defined by the policy used by the operator. 3.1.4 needs to be=20 >rewritten, but there is no reason why it wouldn't apply to 3.2.3. As I told in the previous message, 3.1.4 was my first idea, before thinking that it was maybe intended for other uses (e.g. paid bulk access). But then, if you want to use 3.1.4 for more general purposes including privacy protection, it lacks a couple of things: - as you say, the protocol must be able to support more than one level of access; - there should be some definition of a specially named level of access that is the only one allowed to access data marked as private during the provisioning phase; the implementations of the protocol should mandatorily support secure authentication for that level of access; - it must be specified that the level of access must be evaluated at the level of each single value of each single item, and not simply at the whole row or whole column level of the database. =46or the rest, as I said, I'm not the expert in writing RFCs here :-) My only desire is to see these points clearly specified in the requirements, to be sure that they won't be missed by the actual protocols and the subsequent implementations. From=20 >the text of section 3: > For instance, this > document may say that the service "MUST" support search features. = An > actual service operator is always free to disable it (and then to > return an error such as "permission denied"). Yes. But I do not want an operator to disable the search features completely. I only want the operator to support proper authentication and permissions of access to each single piece of information of his database. This way, he will be able to support both privacy and searching in a proper manner, without having to choose between them. Thanks, --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From jaap@sidn.nl Mon Jan 20 10:23:30 2003 From: jaap@sidn.nl (Jaap Akkerhuis) Date: Mon, 20 Jan 2003 11:23:30 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: Your message of Mon, 20 Jan 2003 11:12:33 +0100. Message-ID: <200301201023.h0KANUTQ098947@bartok.sidn.nl> So you should simply omit private fields from answers, rather than substituting them with a warning message such as "", as per my proposal? Personally, I think that there should be an explicit and standard "" answer, because it will allow the user (and the maintainer of the service) to tell between incomplete or missing answers that happen because the rest of the data are private, and incomplete or missing answers that happen because of a bug in the implementation, a fault, or a problem in the data base. Otherwise you may risk that users try again and again to submit queries that do not receive complete answers due to privacy settings, because they think they were incomplete due to a temporary fault. What the answer is on such "private" fields is policy as well. In the Dutch registry some opt-out fields are silently replaced by other information. Contact data for registrants, when opted-out is replaced by contact data of the registrar. The assumption is here that if there are really urgent matters why the registrant needs to be contact, the registrar is the most likely one to know. Otjer registries are likely to have other policies. Just flagging "opted out" or somethong like that is just one option. jaap From bortzmeyer@nic.fr Tue Jan 21 14:20:38 2003 From: bortzmeyer@nic.fr (Stephane Bortzmeyer) Date: Tue, 21 Jan 2003 15:20:38 +0100 Subject: [Ietf-not43] I-D: "Using DNS SRV records to locate whois servers" Message-ID: <20030121142038.GA7372@nic.fr> A new version of the Internet-Draft is available at . I find it really interesting and I personally much prefer the use of the SRV rather than a new protocol with a referral mechanism. Comments welcome, I suggest to Cc: the authors, I do not think they are on this mailing list. From anewton@ecotroph.net Tue Jan 21 17:09:04 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 21 Jan 2003 12:09:04 -0500 Subject: [Ietf-not43] requirements draft revision Message-ID: <3E2D7EB0.3050607@ecotroph.net> I'm working on the revision to the requirements document, and, according to the minutes of the last meeting, there are a couple of people that still owe me text. If you are such a person or persons, could you please send me what you have (or have something to send me). Thanks to those who have sent me text. -andy From vb@bertola.eu.org Tue Jan 21 17:40:10 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Tue, 21 Jan 2003 18:40:10 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <200301201023.h0KANUTQ098947@bartok.sidn.nl> References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> Message-ID: On Mon, 20 Jan 2003 11:23:30 +0100, you wrote: >What the answer is on such "private" fields is policy as well. Ok - I got your point, you're right. I'm still wondering whether, in case the decision is "hide the field behind a <> indication", such indication should be made standard (or at least recommended) to increase interoperability (for example, the client could parse the field and recognize such standard answer). But OTOH some registries might want, for example, to replace it with a message in the local language. --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From anewton@ecotroph.net Tue Jan 21 18:03:26 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 21 Jan 2003 13:03:26 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> Message-ID: <3E2D8B6E.50401@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. --=_zak-28855-1043171847-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vittorio Bertola wrote: > On Mon, 20 Jan 2003 11:23:30 +0100, you wrote: > > >>What the answer is on such "private" fields is policy as well. > > > Ok - I got your point, you're right. I'm still wondering whether, in > case the decision is "hide the field behind a <> indication", > such indication should be made standard (or at least recommended) to > increase interoperability (for example, the client could parse the > field and recognize such standard answer). But OTOH some registries > might want, for example, to replace it with a message in the local > language. That's probably not a bad thing. What's the proposed text for this? -andy --=_zak-28855-1043171847-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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwcy3jANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDQxMDE4NTgyMFoXDTAzMDQxMDE4NTgyMFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYW5ld3Rv bkBlY290cm9waC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDkpzjXSGnG IYETTxQTcf+ooxcL9zHeVB5UqTv90pJQ1mSyl45dmIf+gXKX21C1wjFDbXoS9ejndPXZAEHT jh+j4KSK0Ni+3XNlIctBj1wENHezwWoDsdUc4DILsEypQ9pIFqWJpcM6U9tcHE6S4ZiwF1ED NG/nVR1bcehYCGQYFYLMwJUyu7t7VkavC2tippZck3fuymvtCAd1WZeGM5K7usyaIMJRbkid 4miZH6cc2IWaOoWozEWknD/kyZ2M8KNLyJXBtJTRCkV6l6chz8WvSkEf+oOURfVNrCuwuVEk D6enA73tvZVWIB1qMXfmT7pztkyXgLk0AXR+83qrMRZ9AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGFuZXd0b25AZWNvdHJvcGgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA cXguN/kLOIKIxI3Cb77eA79fIBfPRo9Q2hA20+P4LcKd0xkiAqzEhSdhsszQRhxkUNk7ZBOk sHnfOraFPWx0+zdimBeQljfWz4mxPrM5HrMNhi12o24TRxv8HMhkjOFEmVyXczvMejKH/Q+d jnhxzubpK0m2Z9tzaf+wK7VgKjIwggMGMIICb6ADAgECAgMHMt4wDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA0MTAxODU4 MjBaFw0wMzA0MTAxODU4MjBaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGFuZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA5Kc410hpxiGBE08UE3H/qKMXC/cx3lQeVKk7/dKSUNZkspeOXZiH /oFyl9tQtcIxQ216EvXo53T12QBB044fo+CkitDYvt1zZSHLQY9cBDR3s8FqA7HVHOAyC7BM qUPaSBaliaXDOlPbXBxOkuGYsBdRAzRv51UdW3HoWAhkGBWCzMCVMru7e1ZGrwtrYqaWXJN3 7spr7QgHdVmXhjOSu7rMmiDCUW5IneJomR+nHNiFmjqFqMxFpJw/5MmdjPCjS8iVwbSU0QpF epenIc/Fr0pBH/qDlEX1TawrsLlRJA+npwO97b2VViAdajF35k+6c7ZMl4C5NAF0fvN6qzEW fQIDAQABozEwLzAfBgNVHREEGDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAHF4Ljf5CziCiMSNwm++3gO/XyAXz0aPUNoQNtPj+C3C ndMZIgKsxIUnYbLM0EYcZFDZO2QTpLB53zq2hT1sdPs3YpgXkJY31s+JsT6zOR6zDYYtdqNu E0cb/BzIZIzhRJlcl3M7zHoyh/0PnY54cc7m6StJtmfbc2n/sCu1YCoyMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBzLeMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDEyMTE4MDMyNlowIwYJKoZIhvcNAQkEMRYEFPopEVxEeOSy 30aTBrnOC3WXNDezMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBzLe MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMHMt4wDQYJKoZIhvcNAQEBBQAEggEAlAE3p9evSnckHcUYgE2ChcOE/FEY wFq9FyEXJgQR3csTfl3rTAxF8EgoaxUbsJ/I1k/1qfZQuxSCcRcqJQ6J7bjdJ+NXP/Vauogo zYf8eoM5lzRpYZG8TPRCJUlZUg3pfeQzf3zEiK8cepDrJB42mIJNLHNOpwUIJ0UtZMUG32I1 49BJ+ptriquxfy0xWfTXL34ZdlaC/4AnLlJZeh/dUQLWmVETepiWde+SbQdLEa0ga3ejR37Y ynlTejypqSj7/63NFMiCtn//Z3fT7I6Onzq4kF9Tkxfo5RmYbEbGqNXlhrxCtvfOSaNUBd3+ 15hIPAkYEUbmQE6E26Xi1uq/YwAAAAAAAA== --=_zak-28855-1043171847-0001-2-- From leslie@thinkingcat.com Tue Jan 21 19:33:50 2003 From: leslie@thinkingcat.com (Leslie Daigle) Date: Tue, 21 Jan 2003 14:33:50 -0500 Subject: [Ietf-not43] I-D: "Using DNS SRV records to locate whois servers" References: <20030121142038.GA7372@nic.fr> Message-ID: <3E2DA09E.5000508@thinkingcat.com> That is a proposal for a (non-authoritative) convention for finding whois servers. This WG is addressing the fact that whois, the protocol, is insufficient for today's (domain) registry & (domain) registrant needs. As a part of proposing the overall service, this WG is also looking at using the DNS as an (authoritative) mechanism for finding servers participating in that new service. These are different things. Leslie. Stephane Bortzmeyer wrote: > A new version of the Internet-Draft is available at > . > > I find it really interesting and I personally much prefer the use of > the SRV rather than a new protocol with a referral mechanism. > > Comments welcome, I suggest to Cc: the authors, I do not think they > are on this mailing list. > > > > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- ------------------------------------------------------------------- "An essential element of a successful journey is recognizing when you have arrived." -- ThinkingCat (c.1983 - 2002) Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From bortzmeyer@nic.fr Wed Jan 22 08:42:43 2003 From: bortzmeyer@nic.fr (Stephane Bortzmeyer) Date: Wed, 22 Jan 2003 09:42:43 +0100 Subject: [Ietf-not43] I-D: "Using DNS SRV records to locate whois servers" In-Reply-To: <200301211806.KAA26394@geode.he.net> References: <20030121142038.GA7372@nic.fr> <200301211806.KAA26394@geode.he.net> Message-ID: <20030122084243.GA13561@nic.fr> [This is also a reply to Leslie Daigle.] On Tue, Jan 21, 2003 at 10:06:17AM -0800, Ted Hardie wrote a message of 33 lines which said: > This draft is specific to mechanisms for discovering whois > servers. I know :-) > While this may be interesting work for many members of the > working group, please remember that compatibility with whois is > explicitly not required for the CRISP work and that discussion of > whois should take place elsewhere. Again, I know. My point was that the mechanisme described in this draft is not dependant on whois. It can be used with any client-server protocol. For instance, with IRIS and then, IRIS would no longer need referrals. > If you are interested in discussing the use of SRV records as > a discovery mechanism for one of the candidate protocols, Yes, that was my idea. > do that. Note, however, that discovery and referral are not the > same. IMHO, they fill the same purpose (being able to ask a question without knowing the actual server which holds the answer). From anewton@ecotroph.net Wed Jan 22 14:02:10 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 22 Jan 2003 09:02:10 -0500 Subject: [Ietf-not43] I-D: "Using DNS SRV records to locate whois servers" In-Reply-To: <20030122084243.GA13561@nic.fr> References: <20030121142038.GA7372@nic.fr> <200301211806.KAA26394@geode.he.net> <20030122084243.GA13561@nic.fr> Message-ID: <3E2EA462.3060301@ecotroph.net> First, I'm not sure where Ted's email went. I certainly didn't get it, and it isn't in the archives. Stephane Bortzmeyer wrote: > > Again, I know. My point was that the mechanisme described in this > draft is not dependant on whois. It can be used with any client-server > protocol. For instance, with IRIS and then, IRIS would no longer need > referrals. IRIS does make use of SRV for discovery. It's in the drafts. >>do that. Note, however, that discovery and referral are not the >>same. > > > IMHO, they fill the same purpose (being able to ask a question without > knowing the actual server which holds the answer). Ted is right. They are not the same thing. Examples: *) An SRV record can only point to a host/port pair, while a referral can actually point to a specific entry. For example, you may use an SRV record to discover the authoritative record for a domain, but that record may point to another record stating the AUP. Consult the IRIS drafts for an example of this. *) An SRV record cannot help you find the registrar of a domain, because the registrar is not in the DNS delegation hierarchy. Therefore a referral is needed from the registry or registrant to the registrar. An example of this is also in the IRIS drafts. -andy From anewton@ecotroph.net Wed Jan 22 19:02:56 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 22 Jan 2003 14:02:56 -0500 Subject: [Ietf-not43] MUST/SHOULD protocol/service schism Message-ID: <3E2EEAE0.9060205@ecotroph.net> In rewriting the requirements draft so that MUST/SHOULD language is not used for service descriptions, a problem has been made more evident. First, the current draft actually rarely uses the word "protocol", instead using "service" in places where we would naturally want to say protocol. So if we went through the draft and strictly changed the capital case in those places, the draft actaully won't specify too much of anything. So I went back and changed the word "service" to "protocol" in places where the requirement was about a protocol issue. However, now the draft has a schizophrenic feel. Here are a few examples: The protocol MUST provide the capability of searching for registrants, within limits set by the policy of an operator, by exact name match or a reasonable name subset. This search must comply with Section 3.2.8. The service must provide a mechanism to distribute this search across all applicable domain registries and registrars. The protocol SHOULD have a means to narrow the scope of a search to a specific TLD. The protocol MUST be able to specify an empty result set should the search yield no results. and The protocol MAY allow the ability, within the limits of the operator, to list all domains hosted by a specific nameserver given the fully-qualified host name or IP address, if applicable, of the nameserver. The service may provide a mechanism to distribute this search across all applicable domain registries and registrars. I do not think this makes it clear that the service requirements are OPTIONAL depending on the policy of an operator. It is confusing. I'd like to restructure the document so that service model descriptions are separated from the client/server protocol interactions. I think by placing them in separate sections, it would be clearer. The MUST/SHOULD language on the service descriptions would be lowercased or removed altogether. Please let me know what you think. I'd rather get out a good document than one that can't be understood by anybody. -andy From shollenbeck@verisign.com Wed Jan 22 19:10:14 2003 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 22 Jan 2003 14:10:14 -0500 Subject: [Ietf-not43] MUST/SHOULD protocol/service schism Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370575@vsvapostal3.prod.netsol.com> > Please let me know what you think. I'd rather get out a good > document > than one that can't be understood by anybody. Seems like a reasonable approach. -Scott- From jaap@sidn.nl Wed Jan 22 19:58:49 2003 From: jaap@sidn.nl (Jaap Akkerhuis) Date: Wed, 22 Jan 2003 20:58:49 +0100 Subject: [Ietf-not43] MUST/SHOULD protocol/service schism In-Reply-To: Your message of Wed, 22 Jan 2003 14:02:56 -0500. <3E2EEAE0.9060205@ecotroph.net> Message-ID: <200301221958.h0MJwnTQ048606@bartok.sidn.nl> I'd like to restructure the document so that service model descriptions are separated from the client/server protocol interactions. I think by placing them in separate sections, it would be clearer. The MUST/SHOULD language on the service descriptions would be lowercased or removed altogether. Please let me know what you think. I'd rather get out a good document than one that can't be understood by anybody. Seems good to me. It will separate the policy issues about the service from the protocol capabilaties. jaap From vb@bertola.eu.org Thu Jan 23 09:31:24 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Thu, 23 Jan 2003 10:31:24 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <3E2D8B6E.50401@ecotroph.net> References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> Message-ID: <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> On Tue, 21 Jan 2003 13:03:26 -0500, you wrote: >> Ok - I got your point, you're right. I'm still wondering whether, in >> case the decision is "hide the field behind a <> indication", >> such indication should be made standard (or at least recommended) to >> increase interoperability (for example, the client could parse the >> field and recognize such standard answer). But OTOH some registries >> might want, for example, to replace it with a message in the local >> language. > >That's probably not a bad thing. What's the proposed text for this? I have tried to rephrase 3.1.4 a little to include this. I have included the concept of "type of authentication" to allow for more than one level of privilege. I think that we should talk about "types", not "levels", because it's not a hierarchical structure - you could define a type of privilege such as "privacy-protected" and another type such as "needs payment to be accessed", but entities who can access privileged data of the first type should not necessarily be able to access those of the second, and vice versa; so the authentication should be per-type (i.e. the protocol should be able to authenticate you, and the service should be able to determine whether you can access one type, the other, or both types of privileged data). I'm not sure whether we need the new paragraph #2. You possibly need it if you talk about the service, not if you talk about the protocol. 3.1.4 Level of Access The service MUST allow the classification of data as being either privileged or non-privileged, for the purpose of restricting access to privileged data. Note that this requirement makes no assumption or prescription as to what data (social or operational) might be considered privileged, but merely provides the ability to make the classification as necessary. The system SHOULD support more than one type of privileges. The service MUST be capable of associating a type of privilege (or the lack of any privilege requirement) to each single value of each entry. The service MUST be capable of serving both privileged and non- privileged data. The service MUST be capable of authenticating privileged entities and ensuring that only those entities have access to privileged data of the type(s) for which they were authenticated. The service MUST be capable of providing access to non-privileged data without requiring authentication of any type (i.e. anonymous access). When the answer to be returned to a user after a query contains values of a privilege type for which the user does not have authorization, the service MUST NOT return such values. In case the choice is made to make it explicit that those values are not being returned due to insufficient permissions, the service SHOULD return the standard string "[permission denied]" in place of such values. In case such values are being denied for privacy protection reasons and the choice is made to make it explicit that those values are not being returned due to privacy protection reasons, the service SHOULD return the standard string "[private]" in place of such values. --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From anewton@ecotroph.net Thu Jan 23 19:23:01 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 23 Jan 2003 14:23:01 -0500 Subject: [Ietf-not43] example changes Message-ID: <3E304115.9050300@ecotroph.net> Based on the point of the MUST/SHOULD language as it relates to protocol requirements and service descriptions, I thought I'd throw a few samples out just to show what am doing. If you have objections or suggestions, please speak now. Example 1: Before: 3.1.1 Mining Prevention The protocol MUST have a mechanism to limit the amount of data that may be accessed. The service may have different limits for different types of data, as well as for authenticated and non-authenticated entities. The protocol SHOULD be capable of expressing to the client these access limitations based on queries per session per unit of time, queries per source IP address per unit of time, and total queries from all client sessions per unit of time. The service should be able to limit the amount of data based on the above types of limitations. After: 3.1.1 Mining Prevention 3.1.1.1 Protocol Requirement The protocol MUST have a mechanism to limit the amount of data that may be accessed. The protocol SHOULD be capable of expressing to the client these access limitations based on queries per session per unit of time, queries per source IP address per unit of time, and total queries from all client sessions per unit of time. 3.1.1.2 Service Description The limits placed on differing types of data or applied depending upon access status will most likely differ from server to server based on policy and need. Servers should express these limitations to the client if policy allows. Example 2: Before: 3.1.7 Decentralization The service must be decentralized in design and principle and must not require the aggregation of data to a central repository, server, or entity. The service may allow for the optional aggregation of data indexes or hints. The protocol MUST NOT require aggregation of data indexes or hints. After: 3.1.7 Decentralization 3.1.7.1 Protocol Requirement The protoocl MUST NOT require the aggregation of data to a central repository, server, or entity. The protocol MUST NOT require aggregation of data indexes or hints to a central repository, server, or entity. 3.1.7.2 Service Description Some server operators may have a need to coordinate service in a mesh or some other framework with other server operators. However, the ability to operate a CRISP compliant server should not require this. -andy From anewton@ecotroph.net Thu Jan 23 19:35:00 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 23 Jan 2003 14:35:00 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> Message-ID: <3E3043E4.1000307@ecotroph.net> I'd like to list this as its own item, perhaps making a reference to 3.1.4. I think that would be clearer. -andy Vittorio Bertola wrote: > On Tue, 21 Jan 2003 13:03:26 -0500, you wrote: > > >>>Ok - I got your point, you're right. I'm still wondering whether, in >>>case the decision is "hide the field behind a <> indication", >>>such indication should be made standard (or at least recommended) to >>>increase interoperability (for example, the client could parse the >>>field and recognize such standard answer). But OTOH some registries >>>might want, for example, to replace it with a message in the local >>>language. >> >>That's probably not a bad thing. What's the proposed text for this? > > > I have tried to rephrase 3.1.4 a little to include this. > > I have included the concept of "type of authentication" to allow for > more than one level of privilege. I think that we should talk about > "types", not "levels", because it's not a hierarchical structure - you > could define a type of privilege such as "privacy-protected" and > another type such as "needs payment to be accessed", but entities who > can access privileged data of the first type should not necessarily be > able to access those of the second, and vice versa; so the > authentication should be per-type (i.e. the protocol should be able to > authenticate you, and the service should be able to determine whether > you can access one type, the other, or both types of privileged data). > > I'm not sure whether we need the new paragraph #2. You possibly need > it if you talk about the service, not if you talk about the protocol. > > > 3.1.4 Level of Access > > The service MUST allow the classification of data as being either > privileged or non-privileged, for the purpose of restricting access > to privileged data. Note that this requirement makes no assumption > or prescription as to what data (social or operational) might be > considered privileged, but merely provides the ability to make the > classification as necessary. The system SHOULD support more > than one type of privileges. > > The service MUST be capable of associating a type of privilege > (or the lack of any privilege requirement) to each single value of > each entry. > > The service MUST be capable of serving both privileged and non- > privileged data. > > The service MUST be capable of authenticating privileged entities > and ensuring that only those entities have access to > privileged data of the type(s) for which they were > authenticated. > > The service MUST be capable of providing access to non-privileged > data without requiring authentication of any type (i.e. anonymous > access). > > When the answer to be returned to a user after a query > contains values of a privilege type for which the user does not > have authorization, the service MUST NOT return such values. In > case the choice is made to make it explicit that those values are > not being returned due to insufficient permissions, the service > SHOULD return the standard string "[permission denied]" in place of > such values. In case such values are being denied for privacy > protection reasons and the choice is made to make it explicit that > those values are not being returned due to privacy protection > reasons, the service SHOULD return the standard string "[private]" > in place of such values. From anewton@ecotroph.net Thu Jan 23 21:30:58 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 23 Jan 2003 16:30:58 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> Message-ID: <3E305F12.8000604@ecotroph.net> Vittorio, Based on my previous comment that I'd like to separate these two items, here is what I have... let me know if this doesn't work. 3.1.4 Level of Access 3.1.4.1 Protocol Requirement The protocol MUST NOT prohibit an operator from assigning multiple types of access to data according to the policies of the operator. The protocol MUST provide an authentication mechanism and MUST NOT prohibit an operator from granting types of access based on authentication. The protocol MUST provide an anonymous access mechanism that may be turned on or off based on the policy of an operator. 3.1.4.2 Service Description Server operators will offer varying degrees of access depending on policy and need. The following are some examples: o users will be allowed access only to data for which they have a relationship o unauthenticated or anonymous access status may not yield any contact information o full access may be granted to a special group of authenticated users The types of access allowed by a server will most likely vary from one operator to the next. 3.2.11 Data Omission 3.2.11.1 Protocol Requirements When a value in an answer to a query cannot be given due to policy contraints, the protocol MUST be capable of expressing the value in one of three ways: 1. complete omission of the value without explanation 2. an indication that the value cannot be given due to insufficient authorization 3. an indication that the value cannot be given due to privacy constraints regardless of authorization status 3.2.11.2 Service Description Internet registries will have varying constraints regarding their ability to expose certain types of data, usually social information. Server operators must have the ability to accomodate this need while client software will more useful when provided with proper explanations. Therefore, depending on policy, a server operator has a choice between not returning the data at all, signaling a permission error, or indicating a privacy constraint. Vittorio Bertola wrote: > On Tue, 21 Jan 2003 13:03:26 -0500, you wrote: > > >>>Ok - I got your point, you're right. I'm still wondering whether, in >>>case the decision is "hide the field behind a <> indication", >>>such indication should be made standard (or at least recommended) to >>>increase interoperability (for example, the client could parse the >>>field and recognize such standard answer). But OTOH some registries >>>might want, for example, to replace it with a message in the local >>>language. >> >>That's probably not a bad thing. What's the proposed text for this? > > > I have tried to rephrase 3.1.4 a little to include this. > > I have included the concept of "type of authentication" to allow for > more than one level of privilege. I think that we should talk about > "types", not "levels", because it's not a hierarchical structure - you > could define a type of privilege such as "privacy-protected" and > another type such as "needs payment to be accessed", but entities who > can access privileged data of the first type should not necessarily be > able to access those of the second, and vice versa; so the > authentication should be per-type (i.e. the protocol should be able to > authenticate you, and the service should be able to determine whether > you can access one type, the other, or both types of privileged data). > > I'm not sure whether we need the new paragraph #2. You possibly need > it if you talk about the service, not if you talk about the protocol. > > > 3.1.4 Level of Access > > The service MUST allow the classification of data as being either > privileged or non-privileged, for the purpose of restricting access > to privileged data. Note that this requirement makes no assumption > or prescription as to what data (social or operational) might be > considered privileged, but merely provides the ability to make the > classification as necessary. The system SHOULD support more > than one type of privileges. > > The service MUST be capable of associating a type of privilege > (or the lack of any privilege requirement) to each single value of > each entry. > > The service MUST be capable of serving both privileged and non- > privileged data. > > The service MUST be capable of authenticating privileged entities > and ensuring that only those entities have access to > privileged data of the type(s) for which they were > authenticated. > > The service MUST be capable of providing access to non-privileged > data without requiring authentication of any type (i.e. anonymous > access). > > When the answer to be returned to a user after a query > contains values of a privilege type for which the user does not > have authorization, the service MUST NOT return such values. In > case the choice is made to make it explicit that those values are > not being returned due to insufficient permissions, the service > SHOULD return the standard string "[permission denied]" in place of > such values. In case such values are being denied for privacy > protection reasons and the choice is made to make it explicit that > those values are not being returned due to privacy protection > reasons, the service SHOULD return the standard string "[private]" > in place of such values. From anewton@ecotroph.net Thu Jan 23 22:32:50 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 23 Jan 2003 17:32:50 -0500 Subject: [Ietf-not43] another structural change Message-ID: <3E306D92.8090205@ecotroph.net> For readability, I'd like to make another change with the consent of the group. I'd like to consolidate the various domain lookup requirements into one section and the various domain search requirements into another section. For instance, here is what the lookup section would look like: 3.2.1 Lookups 3.2.1.1 Protocol Requirement The protocol MUST contain the following lookup functions: 1. Contact lookup given a unique reference to a contact of a resource. 2. Nameserver lookup given a fully-qualified host name or IP address of a nameserver. 3. Domain lookup given a fully-qualfied domain name. The protocol MUST be capable of supplying the following information relevant to the domain for this lookup: * activation status * registrant * nameservers * technical, billing or other contacts * registry delegating the domain * registrar for the domain The data set for the domain MUST be able to express arbitrary textual information for extensions on an individual operator basis. Examples of such information are license agreements, authorzed use policies, extended status notifications, marketing/ for sale notices, and URI references to other sources. The data sets for contacts, nameservers, and domains MUST be able to express and represent the attributes and allowable values of registration requests in domain registration and provisioning 3.2.1.2 Service Description These lookups are all single index queries and should produce zero or only one result. Depending on the policy and need of an Internet registry, a server operator may not allow all or any of these lookups to successfully return part or all of the information. Here is what we currently have: 3.2.1 Contact Lookup The service MUST allow access to social data of contact entities given a unique reference to the contact entity. The contact information set MUST be able to express and represent the attributes and allowable values of contact registration requests in domain registration and provisioning protocols. 3.2.2 Nameserver Lookup The service MUST allow access to operational and social data of a nameserver given the fully-qualified host name or IP address of a nameserver. The host information set MUST be able to express and represent the attributes and allowable values of nameservers in domain registration and provisioning protocols. 3.2.4 Domain Information Lookup The service MUST provide access to operational and social data specific to a domain given the domain's fully qualified name (FQDN). The service MUST be capable of supplying the following information for this lookup: o activation status o registrant name and contact data o hosting nameservers o technical, billing or other entity types associated with the domain and their relevant contact data, if any exist o the name of or a reference to the registry delegating the domain o the name of or a reference to the registrar for the domain, if one exists The domain information set MUST be able to express and represent the attributes and allowable values of domain registration requests in domain registration and provisioning protocols. From leslie@thinkingcat.com Sat Jan 25 21:48:36 2003 From: leslie@thinkingcat.com (Leslie Daigle) Date: Sat, 25 Jan 2003 16:48:36 -0500 Subject: [Ietf-not43] example changes References: <3E304115.9050300@ecotroph.net> Message-ID: <3E330634.6060303@thinkingcat.com> Hmmm. I agree that splitting these sections allows clarity. I'm not convinced (from these 2 examples) that the first on is really "protocol". Comments inline: Andrew Newton wrote: > Based on the point of the MUST/SHOULD language as it relates to protocol > requirements and service descriptions, I thought I'd throw a few samples > out just to show what am doing. If you have objections or suggestions, > please speak now. > > > Example 1: > > Before: > 3.1.1 Mining Prevention > > The protocol MUST have a mechanism to limit the amount of data that > may be accessed. The service may have different limits for different > types of data, as well as for authenticated and non-authenticated > entities. The protocol SHOULD be capable of expressing to the client > these access limitations based on queries per session per unit of > time, queries per source IP address per unit of time, and total > queries from all client sessions per unit of time. The service > should be able to limit the amount of data based on the above types > of limitations. > > After: > 3.1.1 Mining Prevention > > 3.1.1.1 Protocol Requirement > > The protocol MUST have a mechanism to limit the amount of data that > may be accessed. The protocol SHOULD be capable of expressing to the > client these access limitations based on queries per session per unit > of time, queries per source IP address per unit of time, and total > queries from all client sessions per unit of time. I don't see where there is (necessarily) a protocol issue in limiting the amount of data that is accessed. The protocol exists to transmit requests and responses; I don't see why it is not possible to have a protocol that has NO concept of limits (except the ability to return a message indicating the fact that the server hit one). > > 3.1.1.2 Service Description > > The limits placed on differing types of data or applied depending > upon access status will most likely differ from server to server > based on policy and need. Servers should express these limitations > to the client if policy allows. > > > Example 2: > > Before: > 3.1.7 Decentralization > > The service must be decentralized in design and principle and must > not require the aggregation of data to a central repository, server, > or entity. The service may allow for the optional aggregation of > data indexes or hints. The protocol MUST NOT require aggregation of > data indexes or hints. > > After: > 3.1.7 Decentralization > > 3.1.7.1 Protocol Requirement > > The protoocl MUST NOT require the aggregation of data to a central > repository, server, or entity. The protocol MUST NOT require > aggregation of data indexes or hints to a central repository, server, > or entity. Again, it seems stilted at best to think of the protocol requiring aggregation of data to a central repository. When you're using "protocol" here, do you mean "on the wire protocol" (which is what seems to be the usual use of the word), or are you trying to talk about the server implementation? the conventions or use of a protocol to implement a service? or...? If not the first, a different word/phrase would be helpful. Leslie. From vb@bertola.eu.org Mon Jan 27 08:11:43 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Mon, 27 Jan 2003 09:11:43 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <3E305F12.8000604@ecotroph.net> References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> <3E305F12.8000604@ecotroph.net> Message-ID: <3ip93v04e613dl4un9b5q6qnc3pu9sdvq1@4ax.com> On Thu, 23 Jan 2003 16:30:58 -0500, you wrote: >Vittorio, > >Based on my previous comment that I'd like to separate these two items,=20 >here is what I have... let me know if this doesn't work. I hope I understood correctly the "must not prohibit" statement in 3.1.4.1 - basically you can't mandate support for access privileges here, because it's a matter of the provisioning side, but you have to be certain that the retrieval protocol will not have any characteristic that prevents the operator from implementing such support. Perhaps the only slight change I'd do is "types of access to each piece of data" in the second line, to make sure that we are talking of privileges that are customizable at a granular level. Don't know if "piece of data" is English, though :-) Also, I'm wondering whether in 3.2.11.1 you should say "at least in one of the following ways", rather than "in one of three ways"; you would then allow for additional types of reasons to be specified by the protocol. (Perhaps you would allow also for non-standard extensions done by the operator/implementor, unless you rule them out by adding another sentence there.) Anyway, it seems great (obviously much better than mine). Thanks. --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From anewton@ecotroph.net Mon Jan 27 10:45:31 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Mon, 27 Jan 2003 05:45:31 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements document References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> <3E305F12.8000604@ecotroph.net> <3ip93v04e613dl4un9b5q6qnc3pu9sdvq1@4ax.com> Message-ID: <3E350DCB.8060008@ecotroph.net> Vittorio, > I hope I understood correctly the "must not prohibit" statement in > 3.1.4.1 - basically you can't mandate support for access privileges > here, because it's a matter of the provisioning side, but you have to > be certain that the retrieval protocol will not have any > characteristic that prevents the operator from implementing such > support. Perhaps the only slight change I'd do is "types of access to > each piece of data" in the second line, to make sure that we are > talking of privileges that are customizable at a granular level. Don't > know if "piece of data" is English, though :-) Would it be ok just to say: ...MUST NOT prohibit an operator from assigning multiple types of access to granular data... Otherwise, the other works. > Also, I'm wondering whether in 3.2.11.1 you should say "at least in > one of the following ways", rather than "in one of three ways"; you > would then allow for additional types of reasons to be specified by > the protocol. (Perhaps you would allow also for non-standard > extensions done by the operator/implementor, unless you rule them out > by adding another sentence there.) Good point. We just want to point out the minimum set, but there doesn't seem to be a reason to limit it to just three. > Anyway, it seems great (obviously much better than mine). Thanks. Thanks. -andy From anewton@ecotroph.net Tue Jan 28 08:19:52 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 28 Jan 2003 03:19:52 -0500 Subject: [Ietf-not43] example changes References: <3E304115.9050300@ecotroph.net> <3E330634.6060303@thinkingcat.com> Message-ID: <3E363D28.8040408@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. --=_zak-11935-1043742244-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Leslie Daigle wrote: >> 3.1.1 Mining Prevention >> >> 3.1.1.1 Protocol Requirement >> >> The protocol MUST have a mechanism to limit the amount of data that >> may be accessed. The protocol SHOULD be capable of expressing to the >> client these access limitations based on queries per session per unit >> of time, queries per source IP address per unit of time, and total >> queries from all client sessions per unit of time. > > > I don't see where there is (necessarily) a protocol issue in limiting > the amount of data that is accessed. The protocol exists to transmit > requests and responses; I don't see why it is not possible to have > a protocol that has NO concept of limits (except the ability to return > a message indicating the fact that the server hit one). Well, it very well could be that the protocol has explicit timing considerations or paged results, or some other thing that is definitly part of the protocol. The actual "limit-exceeded" requirement, which is part of the protocol, is covered under a different requirement already. However, the above is all speculation. The truth is that this is an outgrowth of what is currently happening with whois/port 43 with regard to throttling. And that throttling is not part of 954. So it may not be necessary for CRISP as well (as part of the spec). So I see your point. But I see three ways to change it: 1) Change the MUST to a SHOULD. 2) Remove the 3.1.1.1 language and just leave 3.1.1.2 so that people understand that such things might happen but are not explicitly part of the protocol. 3) Remove 3.1.1 completely. I'm in favor of #2 or #3. >> 3.1.1.2 Service Description >> >> The limits placed on differing types of data or applied depending >> upon access status will most likely differ from server to server >> based on policy and need. Servers should express these limitations >> to the client if policy allows. >> >> 3.1.7 Decentralization >> >> 3.1.7.1 Protocol Requirement >> >> The protoocl MUST NOT require the aggregation of data to a central >> repository, server, or entity. The protocol MUST NOT require >> aggregation of data indexes or hints to a central repository, server, >> or entity. > > > Again, it seems stilted at best to think of the protocol requiring > aggregation of data to a central repository. > > When you're using "protocol" here, do you mean "on the wire protocol" > (which is what seems to be the usual use of the word), > or are you trying to talk about the server implementation? the > conventions or use of a protocol to implement a service? or...? If > not the first, a different word/phrase would be helpful. I was thinking of "on-the-wire" protocol. However, I still think this is needed. While it seems a little rediculous, lets remember that 954 would require aggregation of data to meet certain service models. A CRISP protocol with improperly specified referrals (such as the omission of an authority component in a URI, or worse, a hard-coded authority component in a URI) would also not pass this test. So I agree this might be a little on the paranoid side, but I think it should stay. -andy --=_zak-11935-1043742244-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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJgjCC Ax8wggKIoAMCAQICAwgtAzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgzMDAxMzA0N1oXDTAzMDgzMDAxMzA0N1owXzEP MA0GA1UEBBMGTmV3dG9uMQ8wDQYDVQQqEwZBbmRyZXcxFjAUBgNVBAMTDUFuZHJldyBOZXd0 b24xIzAhBgkqhkiG9w0BCQEWFGFuZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuYBxNZFmUWWS+dN6aBcGmYEiGRzoS+MAPLzsamlpAe45HLyM qi/jMkYGTFFqQewAfq6m6Bqe8GvOQhauFdhXxXF2fuprkxsTDYBazTV9edsH4v1nwBNrTtjn O90klF2JYae3lxLq9VmnrAy0BMMeiI5W5KG59deSlfLfYrNUKgrJWRG0n+lDoqDUlhsY3Rlp 1V8vyjdkQ6lhJEzQNWnuUAgqWYNlUuZ05gEImorARY4/etptL4+uLZvkKFwq+TJKGHizTayn m2fCGRrubG2+rd0OE4QclA8H4Y8P8txrnT/2N47JjUDH47u5VjnpSPa5hfmuNrA8v1AoDbx/ Qe0LHQIDAQABozEwLzAfBgNVHREEGDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM9earp4VZUSsCJVLoWh/GOTdLCmdCGu4lzmLDqH maXGZVeyL+7YViaNHD/QfndxnOmk7+dEEr4t8y8cfeiIs//E9V8t59iB13PZi3PR0FFR8w58 YtE51QQiKdXZWw8Q5QzJKbmAN0q5jiTqBGY510/Kst4VzsHtwwNKPdn+QsFVMIIDHzCCAoig AwIBAgIDCC0DMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzAwHhcNMDIwODMwMDEzMDQ3WhcNMDMwODMwMDEzMDQ3WjBfMQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEG CSqGSIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC5gHE1kWZRZZL503poFwaZgSIZHOhL4wA8vOxqaWkB7jkcvIyqL+MyRgZM UWpB7AB+rqboGp7wa85CFq4V2FfFcXZ+6muTGxMNgFrNNX152wfi/WfAE2tO2Oc73SSUXYlh p7eXEur1WaesDLQEwx6Ijlbkobn115KV8t9is1QqCslZEbSf6UOioNSWGxjdGWnVXy/KN2RD qWEkTNA1ae5QCCpZg2VS5nTmAQiaisBFjj962m0vj64tm+QoXCr5MkoYeLNNrKebZ8IZGu5s bb6t3Q4ThByUDwfhjw/y3GudP/Y3jsmNQMfju7lWOelI9rmF+a42sDy/UCgNvH9B7QsdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFGFuZXd0b25AZWNvdHJvcGgubmV0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAz15qunhVlRKwIlUuhaH8Y5N0sKZ0Ia7iXOYsOoeZpcZlV7Iv 7thWJo0cP9B+d3Gc6aTv50QSvi3zLxx96Iiz/8T1Xy3n2IHXc9mLc9HQUVHzDnxi0TnVBCIp 1dlbDxDlDMkpuYA3SrmOJOoEZjnXT8qy3hXOwe3DA0o92f5CwVUwggM4MIICoaADAgECAhBm RXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UE CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBD b25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1 OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6 3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR 3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB /wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiN MUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKt BcYxggMnMIIDIwIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMILQMwCQYFKw4DAhoFAKCCAWEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDMwMTI4MDgxOTUyWjAjBgkqhkiG9w0BCQQxFgQU+YwOcFA0SGdzGWFr Q+qP9n5TOyAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwga0GCyqGSIb3DQEJEAIL MYGdoIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwgtAzAN BgkqhkiG9w0BAQEFAASCAQA2/8Ah3jLF3ReW+HQh5pL7Z2YkgrGMaoWictGs0Pj1v0bl6O4K ixhzU4aFCLcO5KqpWzKT+ay/g7iQdBP/tghsOjgB7xmSMRYGhIgHhx7mWPOWWb+DBUWZRsmz AE2g4zn0UGcTSeUSqTuebIH1mDzKmTWY+H8vZI7E01WAyAWC1ra7jqFTxxDI7SBdH+5R1udy sGId0I8aQrGdsCDoHrwRvtFFXn4kx2YoMLNKVnrjk3/L+XLXuPm0DreP69Vt/SFv6/8FxZAg ZuV/NXCCDqoOFg0dL8wfyoG5dg8z9GUxJPA4v6yUXPzdmz2hC0FXwR/neROgPiFX4uuDjwer 4QI+AAAAAAAA --=_zak-11935-1043742244-0001-2-- From vb@bertola.eu.org Tue Jan 28 10:07:26 2003 From: vb@bertola.eu.org (Vittorio Bertola) Date: Tue, 28 Jan 2003 11:07:26 +0100 Subject: [Ietf-not43] Suggestions of changes to the requirements document In-Reply-To: <3E350DCB.8060008@ecotroph.net> References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> <3E305F12.8000604@ecotroph.net> <3ip93v04e613dl4un9b5q6qnc3pu9sdvq1@4ax.com> <3E350DCB.8060008@ecotroph.net> Message-ID: <0dlc3voge8obrr8rt6cijfiv7mp4nvbf02@4ax.com> On Mon, 27 Jan 2003 05:45:31 -0500, you wrote: >Would it be ok just to say: ...MUST NOT prohibit an operator from=20 >assigning multiple types of access to granular data... Perhaps "granularly assigning multiple types of access" (the assignment is granular, not the data). --=20 vb. [Vittorio Bertola - vb [at] bertola.eu.org]<--- -------------------> http://bertola.eu.org/ <----------------------- From anewton@ecotroph.net Tue Jan 28 10:20:29 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 28 Jan 2003 05:20:29 -0500 Subject: [Ietf-not43] Suggestions of changes to the requirements document References: <200301201023.h0KANUTQ098947@bartok.sidn.nl> <3E2D8B6E.50401@ecotroph.net> <81cv2vc97s4r45udglvbk5kdv5gm033017@4ax.com> <3E305F12.8000604@ecotroph.net> <3ip93v04e613dl4un9b5q6qnc3pu9sdvq1@4ax.com> <3E350DCB.8060008@ecotroph.net> <0dlc3voge8obrr8rt6cijfiv7mp4nvbf02@4ax.com> Message-ID: <3E36596D.1090308@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. --=_zak-14123-1043749478-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vittorio Bertola wrote: > On Mon, 27 Jan 2003 05:45:31 -0500, you wrote: > > >>Would it be ok just to say: ...MUST NOT prohibit an operator from >>assigning multiple types of access to granular data... > > > Perhaps "granularly assigning multiple types of access" (the > assignment is granular, not the data). Sounds good to me. -andy --=_zak-14123-1043749478-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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJgjCC Ax8wggKIoAMCAQICAwgtAzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgzMDAxMzA0N1oXDTAzMDgzMDAxMzA0N1owXzEP MA0GA1UEBBMGTmV3dG9uMQ8wDQYDVQQqEwZBbmRyZXcxFjAUBgNVBAMTDUFuZHJldyBOZXd0 b24xIzAhBgkqhkiG9w0BCQEWFGFuZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuYBxNZFmUWWS+dN6aBcGmYEiGRzoS+MAPLzsamlpAe45HLyM qi/jMkYGTFFqQewAfq6m6Bqe8GvOQhauFdhXxXF2fuprkxsTDYBazTV9edsH4v1nwBNrTtjn O90klF2JYae3lxLq9VmnrAy0BMMeiI5W5KG59deSlfLfYrNUKgrJWRG0n+lDoqDUlhsY3Rlp 1V8vyjdkQ6lhJEzQNWnuUAgqWYNlUuZ05gEImorARY4/etptL4+uLZvkKFwq+TJKGHizTayn m2fCGRrubG2+rd0OE4QclA8H4Y8P8txrnT/2N47JjUDH47u5VjnpSPa5hfmuNrA8v1AoDbx/ Qe0LHQIDAQABozEwLzAfBgNVHREEGDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM9earp4VZUSsCJVLoWh/GOTdLCmdCGu4lzmLDqH maXGZVeyL+7YViaNHD/QfndxnOmk7+dEEr4t8y8cfeiIs//E9V8t59iB13PZi3PR0FFR8w58 YtE51QQiKdXZWw8Q5QzJKbmAN0q5jiTqBGY510/Kst4VzsHtwwNKPdn+QsFVMIIDHzCCAoig AwIBAgIDCC0DMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzAwHhcNMDIwODMwMDEzMDQ3WhcNMDMwODMwMDEzMDQ3WjBfMQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEG CSqGSIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC5gHE1kWZRZZL503poFwaZgSIZHOhL4wA8vOxqaWkB7jkcvIyqL+MyRgZM UWpB7AB+rqboGp7wa85CFq4V2FfFcXZ+6muTGxMNgFrNNX152wfi/WfAE2tO2Oc73SSUXYlh p7eXEur1WaesDLQEwx6Ijlbkobn115KV8t9is1QqCslZEbSf6UOioNSWGxjdGWnVXy/KN2RD qWEkTNA1ae5QCCpZg2VS5nTmAQiaisBFjj962m0vj64tm+QoXCr5MkoYeLNNrKebZ8IZGu5s bb6t3Q4ThByUDwfhjw/y3GudP/Y3jsmNQMfju7lWOelI9rmF+a42sDy/UCgNvH9B7QsdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFGFuZXd0b25AZWNvdHJvcGgubmV0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAz15qunhVlRKwIlUuhaH8Y5N0sKZ0Ia7iXOYsOoeZpcZlV7Iv 7thWJo0cP9B+d3Gc6aTv50QSvi3zLxx96Iiz/8T1Xy3n2IHXc9mLc9HQUVHzDnxi0TnVBCIp 1dlbDxDlDMkpuYA3SrmOJOoEZjnXT8qy3hXOwe3DA0o92f5CwVUwggM4MIICoaADAgECAhBm RXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UE CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBD b25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1 OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6 3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR 3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB /wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiN MUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKt BcYxggMnMIIDIwIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMILQMwCQYFKw4DAhoFAKCCAWEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDMwMTI4MTAyMDI5WjAjBgkqhkiG9w0BCQQxFgQUdzjDli4uMGs5bzq6 Dal4x6/KogAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwga0GCyqGSIb3DQEJEAIL MYGdoIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwgtAzAN BgkqhkiG9w0BAQEFAASCAQCzN9YxbfeaiyFAGOelWKgLOwERlyhuAq5Krd5w3X+1Xi8zFXfh Od/xe7fp232smKGQEY9GHBGoE24PnV3MxrZ9Cs03+SXoDjRR0xK/BJw9VaR7edNg0JQfv7EH F905VYnf9SwVWAQij7IETX2VuW6Xy8Cz8BE7jdkA8iF3RaUjaoYDklWwYVlBExgQVeblul8s Yo32ugMgf+Va+UsapmXmyP1JaQkh3367Wdkr8PBPZI6F36nKJoMPPLiRSAmavsKUQP1Uv0zu TFVKmXAWQi/z/mmtPS4aM0mts4XGqUmmjT6u48VPBYsvD9b6unMoeGqsvGvxeYzmBLvRwbts 2yMeAAAAAAAA --=_zak-14123-1043749478-0001-2--