From Internet-Drafts@ietf.org Wed Feb 5 11:43:51 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 05 Feb 2003 06:43:51 -0500 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-03.txt Message-ID: <200302051143.GAA18853@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Cross Registry Internet Service Protocol (CRISP) Requirements Author(s) : A. Newton Filename : draft-ietf-crisp-requirements-03.txt Pages : 29 Date : 2003-2-4 Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-requirements-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-4133900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-crisp-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-crisp-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4133900.I-D@ietf.org> --OtherAccess-- --NextPart-- From anewton@ecotroph.net Wed Feb 5 16:12:21 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 05 Feb 2003 11:12:21 -0500 Subject: [Ietf-not43] Appendix B. Outstanding Issues Message-ID: <3E4137E5.2040202@ecotroph.net> Now that the draft has been in the repository for nearly 5 hours, I know everybody has read it, right? Anyway, please note the addition of: > Appendix B. Outstanding Issues After re-reading the notes and going back through the list and other email, these are the items that I think are still outstanding. To be specific, they are not items I personally think are outstanding, they are items other group participants have mentioned for which I cannot even find proposed text (hint! hint!). Also, please comment on any of the other text you feel is incorrect or needs to be fixed. -andy From ehall@ehsco.com Wed Feb 5 17:34:32 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 11:34:32 -0600 Subject: [Ietf-not43] need versioning requirement[s] In-Reply-To: <200302051143.GAA18853@ietf.org> References: <200302051143.GAA18853@ietf.org> Message-ID: <3E414B28.1030506@ehsco.com> I cannot overstate how strongly I believe there must be a requirement for version identifiers in the schema and/or protocol. X.1 The protocol MUST provide a means by which the end-systems can either identify or negotiate over the protocol version to be used for any query or set of queries. X.2 The service SHOULD allow end-systems using different protocol versions to fallback to a mutually supported protocol version. If this is not possible, the service MUST provide a meaningful error which indicates that this is the specific case. Y.1 All resource-specific schema MUST provide a version identifier attribute which uniquely and unambiguosly identifies the version of the schema being returned in the answer set to a query. Y.2 The service MUST suggest negotiation and/or recovery mechanisms for clients to use when an unknown schema version is received. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Wed Feb 5 17:53:16 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 05 Feb 2003 12:53:16 -0500 Subject: [Ietf-not43] need versioning requirement[s] In-Reply-To: <3E414B28.1030506@ehsco.com> References: <200302051143.GAA18853@ietf.org> <3E414B28.1030506@ehsco.com> Message-ID: <3E414F8C.2020301@ecotroph.net> Eric A. Hall wrote: > I cannot overstate how strongly I believe there must be a requirement for > version identifiers in the schema and/or protocol. > > X.1 The protocol MUST provide a means by which the end-systems can either > identify or negotiate over the protocol version to be used for any query > or set of queries. > > X.2 The service SHOULD allow end-systems using different protocol versions > to fallback to a mutually supported protocol version. If this is not > possible, the service MUST provide a meaningful error which indicates that > this is the specific case. > > Y.1 All resource-specific schema MUST provide a version identifier > attribute which uniquely and unambiguosly identifies the version of the > schema being returned in the answer set to a query. > > Y.2 The service MUST suggest negotiation and/or recovery mechanisms for > clients to use when an unknown schema version is received. I concur. And I believe you have stated this request before with no objections. So its my fault its not in there. Sorry about that. Thanks for the text too. Would it be ok to combine them? -andy From ehall@ehsco.com Wed Feb 5 17:57:25 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 11:57:25 -0600 Subject: [Ietf-not43] need versioning requirement[s] In-Reply-To: <3E414F8C.2020301@ecotroph.net> References: <200302051143.GAA18853@ietf.org> <3E414B28.1030506@ehsco.com> <3E414F8C.2020301@ecotroph.net> Message-ID: <3E415085.3000208@ehsco.com> on 2/5/2003 11:53 AM Andrew Newton wrote: > Thanks for the text too. Would it be ok to combine them? It's okay by me. I separated them because they are different issues, in that schema and protocol have separate requirements. Also, in my specific case, the LDAP specs satisfy the X.* requirements, but I'll have to do something to satisfy the Y.* requirements. It's easier for me to think about the issues if they are separate requirements. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall@ehsco.com Wed Feb 5 18:28:56 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 12:28:56 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E4137E5.2040202@ecotroph.net> References: <3E4137E5.2040202@ecotroph.net> Message-ID: <3E4157E8.9030302@ehsco.com> >From appendix B: | o Internationalization - Because of Internationalized Domain Names | (IDN's), it has been suggested that the requirements surrounding | the support for them be further defined and more specific. Actually my ambiguities aren't with domain names, they are with protocol data in general. We haven't really discussed these issues, but we need to reach some kind of group consensus on exactly what kind of localization and internationalization support is needed. Note that RFC 2277 doesn't really define strict policy on some of these issues. >From my POV, these are some of the l10n/i18n issues that need to be discussed in the requirements document: 1) Attribute identifiers need to capable of being converted into a language/charset of the client user's choosing. EG, something like the "abuse contact" output identifier should be able to be converted into something other than English, as should search input. I don't think this is a problem with either of the current proposals -- both of them should allow the client to convert attribute identifiers locally without imposing additional protocol overhead or without breaking subsequent queries -- but I strongly believe that this should be a formal requirement anyway. 2) Certain units of measure in attribute data needs to allow for client-side localization (dates and timestamps are the obvious elements). As with attribute identifiers, I believe this should also be spelled out with a formal requirement, but I'm not sure of the degree (see the following items). 3) Attribute data in general should probably support non-ASCII characters and data. This is tricky stuff though. It would certainly be very nice if contact data allowed folks to actually spell their names, but how useful would it be for the service in general to allow this? I mean, I'm all for letting an admin in China actually spell their name and mailing address in the language of their choosing, but how how useful would it be to an IPR lawyer in Mexico? Is a reasonable compromise position that things like contact information MUST be provided in a format which is compliant with international postal regulations? Would that be sufficient? Does anybody know what they are? What about other kinds of data, like Comments data? Should that be unencumbered? In those places where we allow free data, should we require language and charset identifiers so that user-side translation agents can be used? Note that this is an absolute requirement of RFC 2277, section 4.2. 4) Issues with certain kinds of structured data are also a concern (domain names, email addresses, etc), but since those attributes are structured they are a lot easier to deal with and have pretty much been figured out. However, there is still a need for a requirement for proposals to explicitly spell out how and where these attribute values will be transformed. I think we really need to have a discussion on point 3 before we can come to any kind of reasonable conclusion on the issue of l10n/i18n support in general. What do you folks want to see, and what's reasonable? Points 1, 2 and 4 fall under the structured data rule, although it may require enumeration of specific attribute "classes" and their disposition. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall@ehsco.com Wed Feb 5 20:50:15 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 14:50:15 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E4157E8.9030302@ehsco.com> References: <3E4137E5.2040202@ecotroph.net> <3E4157E8.9030302@ehsco.com> Message-ID: <3E417907.2020100@ehsco.com> on 2/5/2003 12:28 PM Eric A. Hall wrote: > Is a reasonable compromise position that things like > contact information MUST be provided in a format which is > compliant with international postal regulations? Would > that be sufficient? Does anybody know what they are? Couple of useful links: http://www.upu.int/post_code/en/international_addressing.shtml http://www.columbia.edu/kermit/postal.html General consensus is that all elements of an address should be used in the native language/script of the recipient (the contact person), while the destination country and zone information should also be provided in a form which the originator country can handle. In general then, I would think that the proper policy would be for contact information to allow any language/charset, with two clarifications. First is that country data must be tokenized, and second is that the remaining elements MUST have language identifiers and MUST also pass the necessary charset information (note that ~"MUST be provided in UTF-8" is a suitable instance of this). This should allow for localization on the client side. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From wessorh@ar.com Wed Feb 5 20:59:16 2003 From: wessorh@ar.com (Rick Wesson) Date: Wed, 5 Feb 2003 12:59:16 -0800 (PST) Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E417907.2020100@ehsco.com> Message-ID: Eric, Our requirements don't contain anything about formatting for delivery. We do tag the elements though the description centric to the USA. While the UPU encourages that a postal address be in local script AND roman scripts the UPU only publishes 8bit ASCII data. I propose that we have a 7bit ascii representation and a UTF-8 representation that MAY be used, butf the 7bit ascii representation is REQUIRED. kinda like we did in EPP. -rick On Wed, 5 Feb 2003, Eric A. Hall wrote: > > on 2/5/2003 12:28 PM Eric A. Hall wrote: > > > Is a reasonable compromise position that things like > > contact information MUST be provided in a format which is > > compliant with international postal regulations? Would > > that be sufficient? Does anybody know what they are? > > Couple of useful links: > > http://www.upu.int/post_code/en/international_addressing.shtml > > http://www.columbia.edu/kermit/postal.html > > General consensus is that all elements of an address should be used in the > native language/script of the recipient (the contact person), while the > destination country and zone information should also be provided in a form > which the originator country can handle. > > In general then, I would think that the proper policy would be for contact > information to allow any language/charset, with two clarifications. First > is that country data must be tokenized, and second is that the remaining > elements MUST have language identifiers and MUST also pass the necessary > charset information (note that ~"MUST be provided in UTF-8" is a suitable > instance of this). This should allow for localization on the client side. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From anewton@ecotroph.net Wed Feb 5 22:23:27 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 05 Feb 2003 17:23:27 -0500 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: References: Message-ID: <3E418EDF.2060605@ecotroph.net> Rick Wesson wrote: > Eric, > > Our requirements don't contain anything about formatting for delivery. We > do tag the elements though the description centric to the USA. While the > UPU encourages that a postal address be in local script AND roman scripts > the UPU only publishes 8bit ASCII data. > > I propose that we have a 7bit ascii representation and a UTF-8 > representation that MAY be used, butf the 7bit ascii representation is > REQUIRED. > > kinda like we did in EPP. > > -rick I think requiring 7bit ASCII isn't gonna work. If the server doesn't have a 7bit ASCII form, having it make one up on the fly or withholding the info because it isn't 7bit ASCII is no better. This is also true with the postal address format. If the server doesn't have that data in the UPU form, then no amount of MUST language is gonna put it that way. Plus, what if a particular registry doesn't want to support 7bit ASCII? Or UPU formats? My suggestion: The requirement should be that contact information should have a language identifier and a character set identifier (noting and accepting Eric's UTF-8 comment). The protocol should also support multiple instances of the contact information with differing language/charset identifiers (such as, here is Yoshi's info in Japanese and here it is in Spanish). In addition, postal information should have a format identifier. -andy From anewton@ecotroph.net Wed Feb 5 22:44:43 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 05 Feb 2003 17:44:43 -0500 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E4157E8.9030302@ehsco.com> References: <3E4137E5.2040202@ecotroph.net> <3E4157E8.9030302@ehsco.com> Message-ID: <3E4193DB.8030107@ecotroph.net> Eric A. Hall wrote: > > 1) Attribute identifiers need to capable of being converted into > a language/charset of the client user's choosing. EG, something > like the "abuse contact" output identifier should be able to be > converted into something other than English, as should search > input. I don't think this is a problem with either of the > current proposals -- both of them should allow the client to > convert attribute identifiers locally without imposing > additional protocol overhead or without breaking subsequent > queries -- but I strongly believe that this should be a formal > requirement anyway. I'd like to add this to 3.1.3 to make it clearer: The client-to-server protocol must define a standard set of data structures or schemas to be used when exchanging information. It must also posses the ability to allow for the use of newer data structures that are currently nor foreseen by this specification. In both cases, the description and specification of both types of data structures or schemas must be done in the same way (i.e. the same schema language). The schemas must also be capable of "tagging" data with a unique idenitifier. This identifier can then be used to localize the name of that type of data. For instance, a piece of data may have the value "Bob" and its type identified with the number "5.1". Client software could use this to display "Name: Bob" in an English locale or "Nombre: Bob" in a Spanish locale. Note that 3.1.3 already has some MUST/SHOULD language... this would just be in addition to what is there. > 2) Certain units of measure in attribute data needs to allow > for client-side localization (dates and timestamps are the > obvious elements). As with attribute identifiers, I believe > this should also be spelled out with a formal requirement, > but I'm not sure of the degree (see the following items). Anything much beyond dates and timestamps would probably be a big time pit. Plus, I don't think we need to do anything beyond that anyway. Everything else should just fall back to the support of the schema language. > 4) Issues with certain kinds of structured data are also a > concern (domain names, email addresses, etc), but since > those attributes are structured they are a lot easier to > deal with and have pretty much been figured out. However, > there is still a need for a requirement for proposals to > explicitly spell out how and where these attribute values > will be transformed. What do you mean by "transformed"? I'm not sure why an email address would need to be transformed. -andy From ehall@ehsco.com Wed Feb 5 23:07:49 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 17:07:49 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E418EDF.2060605@ecotroph.net> References: <3E418EDF.2060605@ecotroph.net> Message-ID: <3E419945.6020008@ehsco.com> on 2/5/2003 4:23 PM Andrew Newton wrote: > My suggestion: > The requirement should be that contact information should have a > language identifier and a character set identifier (noting and accepting > Eric's UTF-8 comment). The protocol should also support multiple > instances of the contact information with differing language/charset > identifiers (such as, here is Yoshi's info in Japanese and here it is in > Spanish). Just to raise the point. Multi-sourced data either introduces complexity to the underlying protocol or adds to the transfer requirements. Either the protocol has to support some kind of negotiation in the query (give me the English version), or all of the data has to be transferred with the client being the one who figures out which version to display. I'm not saying that these aren't livable costs, just raising the point. > In addition, postal information should have a format identifier. I'm not sure I understand what you mean here. If you mean what I think you mean, then I'm not really sure its necessary since the individual elements of the address data are provided as discrete units -- street address, city, state or province, etc -- and their "format" ordering could theoretically be handled with localization. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall@ehsco.com Wed Feb 5 23:17:06 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 17:17:06 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E4193DB.8030107@ecotroph.net> References: <3E4137E5.2040202@ecotroph.net> <3E4157E8.9030302@ehsco.com> <3E4193DB.8030107@ecotroph.net> Message-ID: <3E419B72.3070406@ehsco.com> on 2/5/2003 4:44 PM Andrew Newton wrote: > Eric A. Hall wrote: >> 4) Issues with certain kinds of structured data are also a >> concern (domain names, email addresses, etc), but since >> those attributes are structured they are a lot easier to >> deal with and have pretty much been figured out. However, >> there is still a need for a requirement for proposals to >> explicitly spell out how and where these attribute values >> will be transformed. > > What do you mean by "transformed"? I'm not sure why an email address > would need to be transformed. For example, if the user enters an email address in its i18n form (perhaps it got the email address in that form from a web page copy-n-paste), the client may have to do the transformation into IDNA before the query is actually submitted. That specific process does not have to be specified in the requirements document. What does need to be required is for proposals to describe when and where any such codec transformations may occur. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Wed Feb 5 23:38:24 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 05 Feb 2003 18:38:24 -0500 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E419945.6020008@ehsco.com> References: <3E418EDF.2060605@ecotroph.net> <3E419945.6020008@ehsco.com> Message-ID: <3E41A070.6040800@ecotroph.net> Eric A. Hall wrote: > > I'm not saying that these aren't livable costs, just raising the point. It's my guess that this will actually be a corner case and not the norm. However, I don't think it is right to stipulate 7bit ASCII as a must, as this seems like a policy decision. >> In addition, postal information should have a format identifier. > > I'm not sure I understand what you mean here. If you mean what I think you > mean, then I'm not really sure its necessary since the individual elements > of the address data are provided as discrete units -- street address, > city, state or province, etc -- and their "format" ordering could > theoretically be handled with localization. I'm not sure why you want to tokenize or transform any of the components then. -andy From anewton@ecotroph.net Wed Feb 5 23:43:05 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 05 Feb 2003 18:43:05 -0500 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E419B72.3070406@ehsco.com> References: <3E4137E5.2040202@ecotroph.net> <3E4157E8.9030302@ehsco.com> <3E4193DB.8030107@ecotroph.net> <3E419B72.3070406@ehsco.com> Message-ID: <3E41A189.8030309@ecotroph.net> Eric A. Hall wrote: > > For example, if the user enters an email address in its i18n form (perhaps > it got the email address in that form from a web page copy-n-paste), the > client may have to do the transformation into IDNA before the query is > actually submitted. > > That specific process does not have to be specified in the requirements > document. What does need to be required is for proposals to describe when > and where any such codec transformations may occur. This doesn't sound like a protocol requirement. It sounds like an implementation note. -andy From shollenbeck@verisign.com Thu Feb 6 00:17:38 2003 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 5 Feb 2003 19:17:38 -0500 Subject: [Ietf-not43] l10n/i18n issues Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60337062E@vsvapostal3.prod.netsol.com> > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Wednesday, February 05, 2003 6:38 PM > To: Eric A. Hall > Cc: Rick Wesson; ietf-not43@lists.verisignlabs.com > Subject: Re: [Ietf-not43] l10n/i18n issues > > > Eric A. Hall wrote: > > > > I'm not saying that these aren't livable costs, just > raising the point. > > It's my guess that this will actually be a corner case and > not the norm. > However, I don't think it is right to stipulate 7bit ASCII > as a must, > as this seems like a policy decision. To reword what Rick suggested a bit, we're strongly recommending UTF-8 in EPP though other character sets are possible with XML as long as they are identified appropriately. There is a subset of UTF-8 that can be represented in ASCII. We're allowing clients to specify one or two name/address forms: a "localized" form (which can contain any UTF-8 characters that make sense in the local policy context) and an "internationalized" form (that can contain only the subset of UTF-8 that can be represented in ASCII in the hope of it being internationally readable). One or the other or both can be provided. -Scott- From ehall@ehsco.com Thu Feb 6 04:58:27 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Wed, 05 Feb 2003 22:58:27 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60337062E@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60337062E@vsvapostal3.prod.netsol.com> Message-ID: <3E41EB73.5050902@ehsco.com> on 2/5/2003 6:17 PM Hollenbeck, Scott wrote: > We're allowing clients to specify one or two name/address forms: a > "localized" form (which can contain any UTF-8 characters that make > sense in the local policy context) and an "internationalized" form > (that can contain only the subset of UTF-8 that can be represented in > ASCII in the hope of it being internationally readable). One or the > other or both can be provided. When you say "clients" do you mean the typical client-side protocol agents, or do you mean something else? If protocol agents, then doesn't this model inherit the worst of both models, in that it duplicates entry management and also complicates protocol overhead? Can I get a pointer to the section of the draft[s] that describes the model so I can read up on it? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From shollenbeck@verisign.com Thu Feb 6 12:15:19 2003 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Thu, 6 Feb 2003 07:15:19 -0500 Subject: [Ietf-not43] l10n/i18n issues Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370631@vsvapostal3.prod.netsol.com> > on 2/5/2003 6:17 PM Hollenbeck, Scott wrote: > > > We're allowing clients to specify one or two name/address forms: a > > "localized" form (which can contain any UTF-8 characters that make > > sense in the local policy context) and an "internationalized" form > > (that can contain only the subset of UTF-8 that can be > represented in > > ASCII in the hope of it being internationally readable). One or the > > other or both can be provided. > > When you say "clients" do you mean the typical client-side protocol > agents, or do you mean something else? If protocol agents, > then doesn't > this model inherit the worst of both models, in that it > duplicates entry > management and also complicates protocol overhead? "Client" means client-side protocol agent acting on behalf of some human data originator. Given that there are humans with two-sided business cards with information printed using a different character set on each side of the card, we felt it important to offer the same functionality when provisioning human contact information. Since XML supports UTF-8 and both forms can be cleanly represented in UTF-8 the only additional complexity or overhead is in managing a maximum of two element sequences instead of just one. > Can I get a pointer to the section of the draft[s] that describes the > model so I can read up on it? http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt Section 3.1.2 and 3.2.1. -Scott- From ehall@ehsco.com Thu Feb 6 16:29:02 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 06 Feb 2003 10:29:02 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E418EDF.2060605@ecotroph.net> References: <3E418EDF.2060605@ecotroph.net> Message-ID: <3E428D4E.9020007@ehsco.com> on 2/6/2003 6:15 AM Hollenbeck, Scott wrote: > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt > > Section 3.1.2 and 3.2.1. Thanks. This is essentially identical to what Andy suggested: on 2/5/2003 4:23 PM Andrew Newton wrote: > My suggestion: > The requirement should be that contact information should have a > language identifier and a character set identifier (noting and accepting > Eric's UTF-8 comment). The protocol should also support multiple > instances of the contact information with differing language/charset > identifiers (such as, here is Yoshi's info in Japanese and here it is > in Spanish). In both cases, multiple instances of contact data are provided together. There isn't any negotiation, just identification. The major problem that this introduces for me is that I can no longer simply reuse the inetOrgPerson schema. This is okay from a work POV but its undesirable from an LDAP directory POV. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From hardie@qualcomm.com Thu Feb 6 17:24:12 2003 From: hardie@qualcomm.com (Ted Hardie) Date: Thu, 06 Feb 2003 09:24:12 -0800 Subject: [Ietf-not43] Agenda Slot for upcoming meeting Message-ID: <5.1.0.14.2.20030206091826.00a85b90@mage.qualcomm.com> Hey Folks, I'm about to request the agenda slot for the upcoming meeting. At the moment, I'm planning to ask for a single 2 hour slot. I think the agenda for the meeting will depend on how far we get with the discussion on the requirements draft in the next few weeks, and I encourage everyone to read and comment on the drafts as soon as possible. If you have reason to believe that we will definitely need more than one slot, please let me know, or send a comment on why to the list. I'm also putting together the list of meetings with which we should not conflict. At the moment, that list is: APPs open meeting, EPP, V6OPs, DNSEXT, DNSOPS, and the proposed LEMONADE BoF. If there are other meetings you feel we should avoid, please let me know in private email. Be aware, of course, that meeting planners will do the best they can but will have to schedule us against something. regards, Ted Hardie From anewton@ecotroph.net Thu Feb 6 18:16:50 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 06 Feb 2003 13:16:50 -0500 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E428D4E.9020007@ehsco.com> References: <3E418EDF.2060605@ecotroph.net> <3E428D4E.9020007@ehsco.com> Message-ID: <3E42A692.3000106@ecotroph.net> Eric A. Hall wrote: > The major problem that this introduces for me is that I can no longer > simply reuse the inetOrgPerson schema. This is okay from a work POV but > its undesirable from an LDAP directory POV. I take this to mean that it is doable but just not the purist approach. Correct? Some proposed text: The schema for the contact data set MUST be able to contain an identifier indicating the language used for the contact data. The protocol MUST allow multiple representations of a contact specified by the language identifier. -andy From ehall@ehsco.com Thu Feb 6 19:56:54 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 06 Feb 2003 13:56:54 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E42A692.3000106@ecotroph.net> References: <3E418EDF.2060605@ecotroph.net> <3E428D4E.9020007@ehsco.com> <3E42A692.3000106@ecotroph.net> Message-ID: <3E42BE06.8080108@ehsco.com> on 2/6/2003 12:16 PM Andrew Newton wrote: > Eric A. Hall wrote: > >>The major problem that this introduces for me is that I can no longer >>simply reuse the inetOrgPerson schema. This is okay from a work POV but >>its undesirable from an LDAP directory POV. > > I take this to mean that it is doable but just not the purist approach. > Correct? Sort of. The underlying long-term value benefit to the LDAP-WHOIS model is that it provides a baseline directory of Internet resources that other applications can build on. But if the service itself can't use (and therefore cannot provide) the inetOrgPerson schema for other applications to leverage, then this is a huge gap in the benefit. That's a bit worse than just sacrificing purity. One potential workaround is to continue using inetOrgPerson for the internationalized data, and provide an auxillary object class for the ASCII contact data. That would allow other applications to use inetOrgPerson in its pure form, while also satisfying the CRISP requirement that seems to be developing. However, these two interests don't necessarily mesh cleanly, so this wouldn't be a great solution for either of them. For example, an LDAP focus would favor the internationalized contact data over the ASCII data (we'd want to ensure that inetOrgPerson tended to have the data), while a CRISP focus would reverse the weighting (the word MUST has been used...). There are also some issues with satisfying language tagging requirements in this kind of model. > Some proposed text: > > The schema for the contact data set MUST be able to contain an > identifier indicating the language used for the contact data. The > protocol MUST allow multiple representations of a contact specified by > the language identifier. I think we need to itemize a lot of different areas, and even in this particular instance we are really talking about unstructured free text in general (these rules also need to apply to comment blocks, for example), and a particular subset of contact data. Also, the 2277 MUST rules apply to charset and language equally. Maybe something like: Z.n The service MUST conform to RFC 2277 rules regarding textual data. In particular, the protocol and/or schema MUST be able to indicate the charset and language in use with unstructured textual data. Z.m The service MUST be able to support multiple representations of contact data, with these representations complying with the requirements in section Z.n. The service SHOULD be able to provide non-ASCII contact data in its natural form as well as in US-ASCII. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Thu Feb 6 20:58:17 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 06 Feb 2003 15:58:17 -0500 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E42BE06.8080108@ehsco.com> References: <3E418EDF.2060605@ecotroph.net> <3E428D4E.9020007@ehsco.com> <3E42A692.3000106@ecotroph.net> <3E42BE06.8080108@ehsco.com> Message-ID: <3E42CC69.2020901@ecotroph.net> Eric A. Hall wrote: > > Z.n The service MUST conform to RFC 2277 rules regarding textual data. In > particular, the protocol and/or schema MUST be able to indicate the > charset and language in use with unstructured textual data. > > Z.m The service MUST be able to support multiple representations of > contact data, with these representations complying with the requirements > in section Z.n. The service SHOULD be able to provide non-ASCII contact > data in its natural form as well as in US-ASCII. > My stab: The schema defining domain related resources MUST conform to RFC 2277 regarding textual data. In particular, the schema MUST be able to indicate the charset and language in use with unstructured textual data. The protocol MUST be able to support multiple representations of contact data, with these representations complying with the requirements in Section XX. The protocol MUST be able to provide contact data in UTF-8 and SHOULD be able to provide contact data in US-ASCII and other character sets. After just re-reading 2277, it says that UTF-8 is a MUST unless a variance is provided. -andy From ehall@ehsco.com Thu Feb 6 21:07:11 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Thu, 06 Feb 2003 15:07:11 -0600 Subject: [Ietf-not43] l10n/i18n issues In-Reply-To: <3E42CC69.2020901@ecotroph.net> References: <3E418EDF.2060605@ecotroph.net> <3E428D4E.9020007@ehsco.com> <3E42A692.3000106@ecotroph.net> <3E42BE06.8080108@ehsco.com> <3E42CC69.2020901@ecotroph.net> Message-ID: <3E42CE7F.2020605@ehsco.com> on 2/6/2003 2:58 PM Andrew Newton wrote: > The schema defining domain related resources MUST conform to RFC 2277 > regarding textual data. In particular, the schema MUST be able to > indicate the charset and language in use with unstructured textual > data. > > The protocol MUST be able to support multiple representations of > contact data, with these representations complying with the > requirements in Section XX. The protocol MUST be able to provide > contact data in UTF-8 and SHOULD be able to provide contact data in > US-ASCII and other character sets. Add something about language tagging to the last part and I'm happy. Can the MUST-use-ASCII camp can live with it? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Mon Feb 10 19:51:25 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Mon, 10 Feb 2003 14:51:25 -0500 Subject: [Ietf-not43] transaction settlement issue stated in Appendix B. Message-ID: <3E4802BD.7090700@ecotroph.net> From Appendix B. of the new draft: > Query Distribution and Non-generic Query Referrals - The working > group has discussed issues surrounding query referrals and their > impact on certain classes of servers in a query referral mesh. > Proposals have been suggested for a robust referral mechanism and > a separate transaction token-passing system to provide a means to > solving this class of problems. Given the lack of response on this issue and going by the notes from the last meeting in this area, here's my attempt to tackle this one: Query Relay Bag When issuing a referral, the protocol MUST be capable of supplying a relay bag from the server to the client, and the protocol MUST be capable of allowing the client to submit this relay bag with a query to the referred server. The use of the relay bag MUST be OPTIONAL. The protocol MUST NOT make any assumptions regarding the contents of the relay bag, but the relay bag MUST be described using the schema language of the protocol. -andy From anewton@ecotroph.net Tue Feb 11 19:12:56 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 11 Feb 2003 14:12:56 -0500 Subject: [Ietf-not43] transaction settlement issue stated in Appendix B. In-Reply-To: <3E4802BD.7090700@ecotroph.net> References: <3E4802BD.7090700@ecotroph.net> Message-ID: <3E494B38.2070809@ecotroph.net> Andrew Newton wrote: > > Query Relay Bag > > When issuing a referral, the protocol MUST be capable of supplying a > relay bag from the server to the client, and the protocol MUST be > capable of allowing the client to submit this relay bag with a query > to the referred server. The use of the relay bag MUST be OPTIONAL. > The protocol MUST NOT make any assumptions regarding the contents of > the relay bag, but the relay bag MUST be described using the > schema language of the protocol. It has been brought to my attention that this definition needs explanation. I'm sorry for not doing so. Specifically, the term "bag" is not used generically enough in the computing industry for its meaning to be universally understood. From m-w.com: > a usually flexible container that may be closed for holding, storing, or carrying something I didn't want to use the word "blob" as it tends to have specific meanings to certain database people and one of the b's is often interpretted as "binary". I also didn't want to use the word "token" as that also has a separate meaning when it comes to text parsing. So perhaps the explanation that might go under "service description": In some models where service coordination among participating server operators is utilized, there might be needs to allow a referring server to pass operator-to-operator coordination data along with the referral to the referant server. Such needs might be auditing or tracking. This feature requirement allows a server to pass to the client a flexible container of unspecified data ("bag") that the client should pass to the referant server. The bag has no meaning to the client. -andy From leslie@thinkingcat.com Sun Feb 16 20:13:45 2003 From: leslie@thinkingcat.com (Leslie Daigle) Date: Sun, 16 Feb 2003 15:13:45 -0500 Subject: [Ietf-not43] transaction settlement issue stated in Appendix B. References: <3E4802BD.7090700@ecotroph.net> <3E494B38.2070809@ecotroph.net> Message-ID: <3E4FF0F9.9060900@thinkingcat.com> I think the revised text is much clearer. I also think the expected behaviour should be spelled out, e.g., for what happens if the bag has unknown or undesirable contents. In terms of requirements, that might be something like: A service MUST accept and process the query with a bag; refuse the query with an error message if it does not recognize the data in the bag; or refuse the query with a different error message if the data in the bag is of the proper format but is otherwise unacceptable (e.g., out of date tokens, or general refusal to handle referred queries at this time). The protocol MUST provide different error messages to indicate whether the bag is of unrecognized format (permanent failure), if it contains unacceptable data (permanent failure), or if it contains data that means processing is refused at this time (transient failure). Note that it would be possible to specify that the server could issue a warning message and then process the query as if it were not a referral (unbagged). However, I suspect that adds a level of complexity for little return -- in practice, clients will ignore the warning message and assume the query was successfully executed while possibly producing unexpected results. I think it's also important to make it clear that there will be no more than one bag per referral. If the referrant server generates another referral itself, it must supply a new bag (and it doesn't matter whether that's the same as the old, cumulative, or entirely new). And, Andrew Newton wrote: > In some models where service coordination among participating > server operators is utilized, there might be needs to allow a > referring server to pass operator-to-operator coordination > data along with the referral to the referant server. Such needs > might be auditing or tracking. This feature requirement > allows a server to pass to the client a flexible container > of unspecified data ("bag") that the client should pass to the > referant server. The bag has no meaning to the client. additionally, "The client {MUST | SHOULD | MAY} pass the bag as part of any query made to a referrant server as a result of this referreral." I'm not sure which of MUST, SHOULD or MAY it should be. This proposal came up in the context of handling adjustments between servers in the cases of referrals. In that case, if the client passes the bag, it's plainly acting on a referral (with whatever increments or decrements of quality of service, willingness to play, and costs that might entail). But, there's truly nothing stopping the client from making the query *without* the bag, and having it look like a completely new query at the referrant server. I.e., it's pretty hard to enforce a "MUST"; it will be effectively a "MAY" in practice. What I think that means is that the requirement should say "MUST", and that service operators will pragmaticaly have to handle life as if it's a "MAY". That is, assert that the client MUST pass the bag, and if you're trying to restrict the amount of referral traffic you serve, use some *other* way to identify "local" (direct) queries, and don't answer any non-local queries that don't have bags. With all that mental meandering done, I think it means the CRISP requirement text is: The client MUST pass the bag as part of any query made to a referrant server as a result of this referreral. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From anewton@ecotroph.net Wed Feb 19 17:09:46 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Wed, 19 Feb 2003 12:09:46 -0500 Subject: [Ietf-not43] transaction settlement issue stated in Appendix B. In-Reply-To: <3E4FF0F9.9060900@thinkingcat.com> References: <3E4802BD.7090700@ecotroph.net> <3E494B38.2070809@ecotroph.net> <3E4FF0F9.9060900@thinkingcat.com> Message-ID: <3E53BA5A.8040900@ecotroph.net> Leslie Daigle wrote: > > A service MUST accept and process the query with a bag; refuse the > query with an error message if it does not recognize the data in the > bag; or refuse the query > with a different error message if the data in the bag > is of the proper format but is otherwise unacceptable > (e.g., out of date tokens, or general refusal to handle > referred queries at this time). I'm not sure this is needed, especially given that service requirements are not longer MUST/SHOULD issues. > The protocol MUST provide different error messages to > indicate whether the bag is of unrecognized format > (permanent failure), if it contains unacceptable > data (permanent failure), or if it contains data > that means processing is refused at this time (transient > failure). However, from a protocol standpoint, this makes sense to me. > I think it's also important to make it clear that there > will be no more than one bag per referral. If the referrant > server generates another referral itself, it must supply a new > bag (and it doesn't matter whether that's the same as > the old, cumulative, or entirely new). Also a good point. >> In some models where service coordination among participating >> server operators is utilized, there might be needs to allow a >> referring server to pass operator-to-operator coordination >> data along with the referral to the referant server. Such needs >> might be auditing or tracking. This feature requirement >> allows a server to pass to the client a flexible container >> of unspecified data ("bag") that the client should pass to the >> referant server. The bag has no meaning to the client. > > > additionally, > > "The client {MUST | SHOULD | MAY} pass the bag as part of any query > made to a referrant server as a result of this referreral." > [...SNIP...] > > With all that mental meandering done, I think it means the > CRISP requirement text is: > > The client MUST pass the bag as part of any query made to a referrant > server as a result of this referreral. You had me at "additionally". -andy From leslie@thinkingcat.com Thu Feb 20 23:12:14 2003 From: leslie@thinkingcat.com (Leslie Daigle) Date: Thu, 20 Feb 2003 18:12:14 -0500 Subject: [Ietf-not43] transaction settlement issue stated in Appendix B. References: <3E4802BD.7090700@ecotroph.net> <3E494B38.2070809@ecotroph.net> <3E4FF0F9.9060900@thinkingcat.com> <3E53BA5A.8040900@ecotroph.net> Message-ID: <3E5560CE.8060107@thinkingcat.com> Andrew Newton wrote: > Leslie Daigle wrote: > >> >> A service MUST accept and process the query with a bag; refuse the >> query with an error message if it does not recognize the data in the >> bag; or refuse the query >> with a different error message if the data in the bag >> is of the proper format but is otherwise unacceptable >> (e.g., out of date tokens, or general refusal to handle >> referred queries at this time). > > > I'm not sure this is needed, especially given that service requirements > are not longer MUST/SHOULD issues. I respect the WG's consensus that it shouldn't be defining policy for the service (by making requirements on server behaviour), and my concern is just that we shouldn't specify a protocol and then imply that the spec needn't be followed (in terms of the semantics). I think that concern would be addressed by including a sentence or two, where you distinguish between service description and protocol requirements, saying that . Except, written in English, not this tortuous phrasing :-) In other words, you shouldn't return referrals if you don't mean it, etc. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From anewton@ecotroph.net Thu Feb 20 23:41:37 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 20 Feb 2003 18:41:37 -0500 Subject: [Ietf-not43] transaction settlement issue stated in Appendix B. In-Reply-To: <3E5560CE.8060107@thinkingcat.com> References: <3E4802BD.7090700@ecotroph.net> <3E494B38.2070809@ecotroph.net> <3E4FF0F9.9060900@thinkingcat.com> <3E53BA5A.8040900@ecotroph.net> <3E5560CE.8060107@thinkingcat.com> Message-ID: <3E5567B1.5010808@ecotroph.net> Leslie Daigle wrote: > > I think that concern would be addressed by including > a sentence or two, where you distinguish between service > description and protocol requirements, saying that individual servers/service operators may not support all > features that the protocol can support, they must > respect the semantics of the protocol queries and > responses>. Except, written in English, not this tortuous > phrasing :-) This sounds like a good idea to me. Perhaps that has been something that has been lost in all this. > In other words, you shouldn't return referrals if you > don't mean it, etc. And what a fine example... perhaps it should turn up in the draft. -andy From anewton@ecotroph.net Mon Feb 24 22:30:08 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Mon, 24 Feb 2003 17:30:08 -0500 Subject: [Ietf-not43] draft-ietf-crisp-requirements-04.txt Message-ID: <3E5A9CF0.2010403@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-21817-1046125195-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I submitted this today, but considering this is -00 day, the drafts administrator might be a little delayed in getting this out. So I'm attaching it for early viewing. -andy --=_zak-21817-1046125195-0001-2 Content-Type: text/plain; name="draft-ietf-crisp-requirements-04.txt"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-crisp-requirements-04.txt" Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: August 25, 2003 February 24, 2003 Cross Registry Internet Service Protocol (CRISP) Requirements draft-ietf-crisp-requirements-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. Newton Expires August 25, 2003 [Page 1] Internet-Draft crisp-requirements February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Requirements Scope . . . . . . . . . . . . . . . . . . . . 4 1.3 Requirements Specification . . . . . . . . . . . . . . . . 4 2. Internet Registry Communities . . . . . . . . . . . . . . 6 2.1 Domain Name System Registries . . . . . . . . . . . . . . 6 2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7 2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 8 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 Service Providers and Network Operators . . . . . . . . . 8 2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 8 2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9 2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 9 2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 9 2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9 3. Functional Requirements . . . . . . . . . . . . . . . . . 10 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 12 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 12 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 12 3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 13 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13 3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 14 3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 14 3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 17 3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 17 3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 18 Newton Expires August 25, 2003 [Page 2] Internet-Draft crisp-requirements February 2003 3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 18 3.2.8 Data Omission . . . . . . . . . . . . . . . . . . . . . . 19 3.2.9 Internationalization . . . . . . . . . . . . . . . . . . . 19 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 21 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 21 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 21 4.4 Structured Queries and Responses . . . . . . . . . . . . . 21 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 21 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 21 5. Internationalization Considerations . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . 24 Normative References . . . . . . . . . . . . . . . . . . . 25 Informative References . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . 26 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 27 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28 B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 28 B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . 30 Newton Expires August 25, 2003 [Page 3] Internet-Draft crisp-requirements February 2003 1. Introduction 1.1 Background The expansion and growth of the Internet has seen the registry function of a traditionally centralized and managed Network Information Center become the responsibility of various autonomous, functionally disparate, and globally distributed Internet registries. With the broadening number of Internet registries, the uses of their administrative directory services have expanded from the original and traditional use of the whois [6] protocol to include the use of whois outside the scope of its specification, formal and informal definitions of syntax, undocumented security mechanisms, the use of other protocols, such as rwhois [5], to fulfill other needs, and proposals for the use of other technologies such as LDAP [4] and XML. 1.2 Requirements Scope The scope of the requirements captured in this document relate to the directory services of Internet registries and their related communities (Section 2.3,Section 2.4, and Section 2.5). This scoping specifically targets the requirements of domain name registries (Section 2.1) while acknowledging extensibility needs for possible future support of the requirements for other registry (Section 2.2) types. The requirements are of both the current use of these directory services and the desired functionality based on input from relevant forums (Appendix B.1). These requirements are not specific to any protocol. Terms used in the definition of requirements in this document may be found in the glossary (Appendix A). The scope of the requirements in this document are also restricted to access of data from Internet registries. Requirements for modification, addition, or provisioning of data in Internet registries are out of scope. 1.3 Requirements Specification The requirements captured in this document are for the purpose of designing technical specifications. The words used in this document for compliance with RFC2119 [3] do not reference or specify policy and speak only to the capabilities in the derived technology. For instance, this document may say that the protocol "MUST" support certain features. An actual service operator is always free to disable it (and then to return an error such as "permission denied".) Requirements in this document specifying the capabilities of the protocol required for proper interaction between a client and a server will be specified with the "MUST/SHOULD" language of RFC2119 Newton Expires August 25, 2003 [Page 4] Internet-Draft crisp-requirements February 2003 [3]. This document also contains language relating to the interaction of a client with multiple servers to form a coherent, cross-network service. Such service requirements will not be described using RFC2119 language. While individual servers/service operators may not support all features that the protocol can support, they must respect the semantics of the protocol queries and responses. For example, a server should not return referrals if it does not have referent data. Newton Expires August 25, 2003 [Page 5] Internet-Draft crisp-requirements February 2003 2. Internet Registry Communities The Internet registries are composed of various communities which provide scope for the requirements in this document. These communities can be generalized into the following categories: registries, registrars, implementers, end-users, and other actors. 2.1 Domain Name System Registries 2.1.1 Domain Registries Domain registries are responsible for the registration of domains for use with DNS [1] and forward lookups (i.e. does not include the IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically served two main domain functions: as the registry for a gTLD or as a registry for a ccTLD. In some instances, one entity will operate multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry operator may be a governmental entity, non-governmental, non-commercial entity, or a commercial entity. Some ccTLD's have second-level domain registrations similar in nature to gTLD's or have distinctly separate entities operating second-level domain registries similar in nature to gTLD's within the ccTLD. Domain registries usually follow one of two models for conducting registrations of domains. The "thick" model is the more traditional model. In a "thick" domain registry, the registry contains both the operational data for the domain and the contact or social data (Appendix A) for the domain. In this model, the registry is typically the interface to the domain registrant but may also interface with the domain registrant through domain registrars. The "thin" model domain registry contains only operational data for domains. In the "thin" model, contact or social data for the domain are maintained by a domain registrar. Domain registries not described in this section (Section 2.1.1) are not the subject of this document and may have requirements that are out of scope for this subject matter. 2.1.2 Domain Registrars Domain registrars accept domain registrations from registrants on behalf of domain registries, both "thick" and "thin". In a "thin" model registry/registrar system, a domain registrar maintains the contact and social data of a domain while the registry maintains the operational data of a domain. In a "thick" model registry/registrar system, a domain registrar passes both the operational data and contact data to the registry. Domain registrars may register a Newton Expires August 25, 2003 [Page 6] Internet-Draft crisp-requirements February 2003 domain on behalf of a registrant in more than one domain registry. 2.2 Other Registries 2.2.1 Regional Internet Registries Regional Internet Registries (RIR's) administer the allocation of IP address space and autonomous system numbers. Each RIR serves a specific geographic region, and collectively they service the entire Internet. Each RIR is a membership-based, non-profit organization that facilitates and implements global addressing policy based on the direction of their regional community. 2.2.2 Local Internet Registries Local Internet Registries (LIR's) and National Internet Registries (NIR's) are sub-registries of RIR's and coordinate the same functions of the RIR's for smaller, more specific geographic regions, sovereign nations, and localities. 2.2.3 Internet Routing Registries Internet Routing Registries are routing policy databases. Their purpose is to provide information helpful in administering Internet routers. Frequently, the syntax and contents are defined by RPSL [7]. IRR's are operated by academic, commercial, governmental, and other types of organizations, including several of the RIR's. The contents of the databases vary and reflect the needs of the users directly served (e.g. an ISP may look up route entries added by their customers to decide whether to accept specific route advertisements they receive). Unlike RIR and domain registry data, IRR data is often duplicated between separate organizations. The IRR data has the unique characteristics of being largely available through other sources (i.e. it is advertised by the Internet routing protocols) and most often having a common data format, RPSL. 2.2.4 Incident Coordination Contact Registries Incident coordination contact registries allow operators of network resources such as network infrastructure, network names, or network services to register contact information for the purpose of providing a means of incident notification. Using this type of registry, an operators of network resources are provided information for contacting the operator of another network resource from which an Newton Expires August 25, 2003 [Page 7] Internet-Draft crisp-requirements February 2003 incident may be occurring. 2.2.5 Network Edge Resource Registries Network edge resource registries provide specific information about "edge" resources. They are administered by the operators of the resources. Examples of such registries are rwhois [5] servers operated by networks to describe the assignment of address space allocated by RIR's or LIR's and whois [6] servers operated by networks to specifically announce routing policy of that network. 2.3 Implementers Implementers of client software are often either affiliated with large network operators, registry operators, or commercial entities offering value-added services, or are general citizens of the Internet. Much of the client software for use with the directory services of Internet registries is either freely available, open source, or both, or available as a service. Implementers of server software are often affiliated with operators or commercial entities specializing in the out-sourcing of development for Internet registries. 2.4 End Users 2.4.1 Service Providers and Network Operators Service providers and network operators provide connectivity, routing, and naming services to many other entities, some commercial and some non-commercial, both large and small. Their operational and administrative staff often interact with Internet registries on behalf of other end-users. Service providers and network operators interact with all of the Internet registry operators outlined in this document on a frequent and consistent basis. For example, network operators use the directory services of Internet registries to determine contact information for network resources that have technical problems. 2.4.2 Intellectual Property Holders 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. Newton Expires August 25, 2003 [Page 8] Internet-Draft crisp-requirements February 2003 2.4.3 Law Enforcement Law enforcement agencies use the directory services of Internet registries to find information used to carry out the enforcement of laws within their jurisdictions. 2.4.4 Certificate Authorities Certificate authorities use the directory services of Internet registries as part of their verification process when issuing certificates for Internet named hosts. 2.4.5 DNS Users Users of the Internet have client software that resolves domain names to IP addresses. Often when trouble occurs in the resolution process of DNS, these users trouble shoot system problems with the aid of information from the directory services of Internet registries. 2.4.6 Domain Registrants Entities given authority over a domain via purchase, lease, or grant from a domain registry, either directly or via the services of a domain registrar. 2.4.7 Abusive Users The administrative directory services of Internet registries are often the target of practices by abusive users. Using information obtained from Internet registries, abusive users undertake certain activities that are counter to the acceptable use of the information as intended by a registry, registrar, or registrant. Many times, these practices violate law in the jurisdiction of the user, registry, registrar, or registrant. One example is the use of Internet registry information for the use of sending unsolicited bulk or commercial email. 2.5 Other Actors Requirements must also consider the positions and policies of other actors on the use of Internet registry directory services. These actors include governments, non-governmental policy-setting bodies, and other non-governmental organizations. Newton Expires August 25, 2003 [Page 9] Internet-Draft crisp-requirements February 2003 3. Functional Requirements Functional requirements describe an overall need or process for which the directory service is used by an Internet registry to fulfill its obligations to provide access to its respective customers, members, or other constituents. This section describes requirements in the manner specified in Section 1.3. 3.1 Base Functions This section describes basic directory service protocol requirements for domain name (Section 2.1) and other (Section 2.2) registries. Additional requirements, specific to domain registries, are described in Domain Specific Functions (Section 3.2). 3.1.1 Mining Prevention In order to prevent the inappropriate acquisition of data from an Internet registry's directory service, many servers will limit the amount of data that may be returned in a fixed time period from a server to a client. This will most likely be especially true for anonymous access uses (see Section 3.1.4). 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. Support for varying service models in the effort to limit data and prevent data mining may or may not have a direct impact on the client-to-server protocol. Section 3.2.5 also contains protocol requirements which are relevant to client/server interaction in certain domain registry service models. 3.1.2 Minimal Technical Reinvention The protocol MUST NOT employ unique technology solutions for all aspects and layers above the network and transport layers and SHOULD make use of existing technology standards where applicable. The protocol MUST employ the use of network and transport layer standards as defined by the Internet Engineering Task Force. The protocol MUST define one or more transport mechanisms for mandatory implementation. 3.1.3 Standard and Extensible Schemas 3.1.3.1 Protocol Requirement The protocol MUST contain standard schemas for the exchange of data needed to implement the functionality in this document. In addition, Newton Expires August 25, 2003 [Page 10] Internet-Draft crisp-requirements February 2003 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 the meaning of the identifying tags. 3.1.3.2 Service Description The client-to-server protocol must define a standard set of data structures or schemas to be used when exchanging information. It must also poses the ability to allow for the use of newer data structures that are currently nor foreseen by this specification. In both cases, the description and specification of both types of data structures or schemas must be done in the same way (i.e. the same schema language). The schemas must also be capable of "tagging" data with a unique identifier. This identifier can then be used to localize the name of that type of data. For instance, a piece of data may have the value "Bob" and its type identified with the number "5.1". Client software could use this to display "Name: Bob" in an English locale or "Nombre: Bob" in a Spanish locale. 3.1.4 Level of Access 3.1.4.1 Protocol Requirement The protocol MUST NOT prohibit an operator from granularly 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 Newton Expires August 25, 2003 [Page 11] Internet-Draft crisp-requirements February 2003 users The types of access allowed by a server will most likely vary from one operator to the next. 3.1.5 Client Processing The protocol MUST be capable of allowing machine parsable requests and responses. 3.1.6 Entity Referencing There MUST be a mechanism for an entity contained within a server to be referenced uniquely by an entry in another server. 3.1.7 Decentralization 3.1.7.1 Protocol Requirement The protocol 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 must not require this. 3.1.8 Query of Access Permission 3.1.8.1 Protocol Requirement The protocol MUST provide a mechanism allowing a client to determine if a query will be denied before the query is submitted according to the appropriate policies of the operator. 3.1.8.2 Service Description Because usage scenarios will differ depending on both policy and type of service, some server operators may want to provide the ability for a client to predetermine its ability to retrieve data from a query. However, some operators will not allow this for security reasons, policy restrictions, or other matters. 3.1.9 Authentication Distribution Newton Expires August 25, 2003 [Page 12] Internet-Draft crisp-requirements February 2003 3.1.9.1 Protocol Requirement The protocol MUST NOT require any Internet registry to participate in any authentication system. The protocol MUST NOT prohibit the participation by an Internet registry in federated, distributed authentication systems. 3.1.9.2 Service Description Some server operators may have a need to delegate authentication to another party or participate in a system where authentication information is distributed. However, the ability to operate a CRISP compliant server must not require this. 3.1.10 Base Error Responses The protocol MUST be capable of returning the following types of non-result or error responses to all lookups and searches: o permission denied - a response indicating that the search or lookup has failed due to insufficient authorization. o not found - the desired results do not exist. o insufficient resources - the search or lookup requires resources that cannot be allocated. 3.1.11 Query Distribution 3.1.11.1 Protocol Requirement The protocol MUST NOT prohibit a server from participating in a query distribution system. 3.1.11.2 Service Description For lookups and searches requiring distribution of queries, the client must be allowed to distribute these queries among the participants in an established mesh of server operators. It is not a requirement that the protocol enable the discovery of servers, but cooperating servers should be able to intelligently handle distribution with its established mesh. Individual server operators will respond to all queries received according to their policies for authentication, privacy, and performance. However, the ability to operate a CRISP compliant server must not require the participation in any query distribution system. Newton Expires August 25, 2003 [Page 13] Internet-Draft crisp-requirements February 2003 3.1.12 Protocol and Schema Versioning 3.1.12.1 Protocol Requirements The protocol MUST provide a means by which the end-systems can either identify or negotiate over the protocol version to be used for any query or set of queries. All resource-specific schema MUST provide a version identifier attribute which uniquely and unambiguously identifies the version of the schema being returned in the answer set to a query. 3.1.12.2 Service Description The service should allow end-systems using different protocol versions to fallback to a mutually supported protocol version. If this is not possible, the service must provide a meaningful error which indicates that this is the specific case. The service must suggest negotiation and/or recovery mechanisms for clients to use when an unknown schema version is received. 3.1.13 Relay Bag 3.1.13.1 Protocol Requirement When issuing a referral, the protocol MUST be capable of supplying a relay bag from the server to the client, and the protocol MUST be capable of allowing the client to submit this relay bag with a query to the referred server. The use of the relay bag MUST be OPTIONAL. The protocol MUST NOT make any assumptions regarding the contents of the relay bag, but the relay bag MUST be described using the schema language of the protocol. 3.1.13.2 Service Description In some models where service coordination among participating server operators is utilized, there might be needs to allow a referring server to pass operator-to-operator coordination data along with the referral to the referent server. Such needs might be auditing or tracking. This feature requirement allows a server to pass to the client a flexible container of unspecified data ("bag") that the client should pass to the referent server. The bag has no meaning to the client. 3.2 Domain Specific Functions These functions describe requirements specifically needed by domain Newton Expires August 25, 2003 [Page 14] Internet-Draft crisp-requirements February 2003 registries (Section 2.1.1) and domain registrars (Section 2.1.2). Requirements specific to other registries (Section 2.2) MUST be specified separately. No compliant server operator is required to support the functions required by every registry type. 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-qualified domain name. See Section 3.2.3 for the requirements regarding the expected return values. 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 return part or all of the information. See Section 3.2.3. 3.2.2 Searches 3.2.2.1 Protocol Requirement The protocol MUST contain the following search functions: 1. Domain name search given an exact match or reasonable subset of a name. This search SHOULD allow for parameters and qualifiers designed to allow better matching of internationalized domain names and SHOULD allow for both exact and partial matching within the limits of internationalized domain names. This search SHOULD NOT require special transformations of internationalized domain names to accommodate this search. This search MUST provide a means to narrow the search by names delegated under a particular TLD. 2. Domain registrant search by either exact name or partial name Newton Expires August 25, 2003 [Page 15] Internet-Draft crisp-requirements February 2003 match with the ability to narrow the search to registrants of a particular TLD. 3. Domains hosted by a nameserver given the fully-qualified host name or IP address of a nameserver. See Section 3.2.3 for the requirements regarding the expected return values. 3.2.2.2 Service Description Depending on the policy and need of an Internet registry, a server operator may not allow all or any of these searches to return part or all of the information. See Section 3.1.4. Access to information resulting from these searches may also be limited, depending on policy, by quantity. Section 3.2.5 describes these types of restrictions. Some Internet registries may also be participating in a query distribution system. See Section 3.1.11. 3.2.3 Information Sets 3.2.3.1 Protocol Requirements 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 protocols. The schema MUST be capable of expressing the following information for domains: o activation status o registrant o nameservers o technical, billing or other contacts o registry delegating the domain o registrar for the domain The data set for domains MUST be able to express arbitrary textual information for extensions on an individual operator basis. Examples of such information are license agreements, authorized use policies, Newton Expires August 25, 2003 [Page 16] Internet-Draft crisp-requirements February 2003 extended status notifications, marketing/for sale notices, and URI references to other sources. 3.2.3.2 Service Description It is not expected that every Internet registry supply all of the information spelled out above, however the schemas employed by the protocol must be capable of expressing this information should a registry need to provide it. The following sections describe requirements relative to the use of schemas with respect to individual registry need and policy: o Section 3.2.8 o Section 3.2.5 o Section 3.1.4 o Section 3.1.1 3.2.4 Serialization Support The schemas used by the protocol SHOULD be capable of off-line serialization Off-line serialization allows for implementation independent operations such as backup and recovery, load-balancing, etc. This MAY also make possible, in whole or in part, data escrow capabilities and other usages, however such usages are out of the scope of this document. 3.2.5 Result Set Limits 3.2.5.1 Protocol Requirement The protocol MUST contain a feature, used at the discretion of a server operator, to allow a server to express to a client a limit on the number of results from searches and lookups. When returning result sets, the protocol MUST be able to make the following distinctions: 1. an empty result set. 2. a result set truncated for the purpose of improving performance bottlenecks. Newton Expires August 25, 2003 [Page 17] Internet-Draft crisp-requirements February 2003 3. a result set truncated to comply with Section 3.1.1 3.2.5.2 Service Description Client software will operate more usefully if it can understand reasons for the truncation of result sets. Of course, some Internet registries may not be able to expose their policies for the limiting of result sets, but, when it is possible, clients will have a better operational view. This may eliminate re-queries and other repeated actions that are not desirable. 3.2.6 DNS Delegation Referencing 3.2.6.1 Protocol Requirement The protocol MUST use the delegation authority model available in DNS [1] as the primary means for determining the authoritative source for information regarding domains or any other objects when applicable. 3.2.6.2 Service Description The intent of this requirement is to have clients use the DNS delegation model to find servers authoritative for resources instead of using a master or central server containing pointer information. In other words, when a resource is naturally mapped by DNS, the desired behavior is to consult the DNS to find an authoritative server containing information about that resource. Using 'example.com', the authoritative server for information about example.com according to the registrant of that domain may be found by querying the DNS zone for example.com. To find the registry information for example.com, the DNS zone for com should be queried. There are cases where resources will not naturally map into the DNS delegation hierarchy. This requirement is not meant to force such a mapping. 3.2.7 Distribution for Domain Registry Types 3.2.7.1 Protocol Requirement The protocol MUST NOT prohibit the distribution of data to exclude any of the registry/registrar models stated in Section 2.1.1. The protocol MUST be capable of expressing referrals and entity references between the various models described in Section 2.1.1. 3.2.7.2 Service Description Newton Expires August 25, 2003 [Page 18] Internet-Draft crisp-requirements February 2003 Depending on the domain registry/registrar model in use, technical data for a domain may only reside in one server while contact data for the same domain may only reside in a server operated by a separate entity. However, in many uses, this is not the situation. Therefore, the service must accommodate for the various registration distribution models of domain registry types described in Section 2.1.1 while complying with Section 3.1.7. 3.2.8 Data Omission 3.2.8.1 Protocol Requirement When a value in an answer to a query cannot be given due to policy constraints, 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 The protocol MAY define other values for this purpose, but MUST define values defined above at a minimum. 3.2.8.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 accommodate this need while client software will be 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. 3.2.9 Internationalization The schema defining domain related resources MUST conform to RFC 2277 [2] regarding textual data. In particular, the schema MUST be able to indicate the charset and language in use with unstructured textual data. The protocol MUST be able to support multiple representations of contact data, with these representations complying with the requirements in Section 3.2.3. The protocol MUST be able to provide contact data in UTF-8 and SHOULD be able to provide contact data in Newton Expires August 25, 2003 [Page 19] Internet-Draft crisp-requirements February 2003 US-ASCII, other character sets, and capable of specifying the language of the data. Newton Expires August 25, 2003 [Page 20] Internet-Draft crisp-requirements February 2003 4. Feature Requirements Feature requirements describe the perceived need derived from the functional requirements for specific technical criteria of the directory service. This section describes requirements in the manner specified in Section 1.3. 4.1 Client Authentication Entities accessing the service (users) MUST be provided a mechanism for passing credentials to a server for the purpose of authentication. The protocol MUST provide a mechanism capable of employing many authentication types and capable of extension for future authentication types. 4.2 Referrals To distribute queries for search continuations and to issue entity references, the protocol MUST provide a referral mechanism. 4.3 Common Referral Mechanism To distribute queries for search continuations and to issue entity references, the protocol MUST define a common referral scheme and syntax. 4.4 Structured Queries and Responses To provide for machine consumption as well as human consumption, the protocol MUST employ structured queries and responses. 4.5 Existing Schema Language To provide structured queries and responses and allow for minimal technological reinvention, the protocol MUST employ a pre-existing schema language. 4.6 Defined Schemas To provide for machine consumption as well as human consumption, the protocol MUST define schemas for use by the structured queries and responses. Newton Expires August 25, 2003 [Page 21] Internet-Draft crisp-requirements February 2003 5. Internationalization Considerations Requirements defined in this document MUST consider the best practices spelled out in [2]. Newton Expires August 25, 2003 [Page 22] Internet-Draft crisp-requirements February 2003 6. IANA Considerations IANA consideration for any service meeting these requirements will depend upon the technologies chosen and MUST be specified by any document describing such a service. Newton Expires August 25, 2003 [Page 23] Internet-Draft crisp-requirements February 2003 7. Security Considerations This document contains requirements for the validation of authenticated entities and the access of authenticated entities compared with the access of non-authenticated entities. This document does not define the mechanism for validation of authenticated entities. Requirements defined in this document MUST allow for the implementation of this mechanism according best common practices. The requirement in Section 3.1.4 must be weighed against other requirements specifying search or lookup capabilities. This document contains requirements for referrals and entity references. Client implementations based on these requirements SHOULD take proper care in the safe-guarding of credential information when resolving referrals or entity references according to best common practices. This document contains requirements for the distribution of queries among a mesh of participating service providers. Protocols proposed to meet these requirements must be able to protect against the use of that distribution system as a vector of distributed denial of service attacks or unauthorized data mining. Newton Expires August 25, 2003 [Page 24] Internet-Draft crisp-requirements February 2003 Normative References [1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Newton Expires August 25, 2003 [Page 25] Internet-Draft crisp-requirements February 2003 Informative References [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997. [6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985. [7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. Newton Expires August 25, 2003 [Page 26] Internet-Draft crisp-requirements February 2003 URIs [8] [9] [10] [11] [12] Author's Address Andrew L. Newton VeriSign, Inc. 21355 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; anewton@ecotroph.net Newton Expires August 25, 2003 [Page 27] Internet-Draft crisp-requirements February 2003 Appendix A. Glossary o TLD: Initials for "top level domain." Referes to domains in DNS [1]that are hierarchically at the level just beneath the root. o ccTLD: Initials for "country code top level domain." TLD's which use one of the two character country codes defined by ISO. o gTLD: Initials for "generic top level domain." TLD's that do not use one of the two character country codes defined by ISO. o social data: Data containing names and contact information (i.e. postal addresses, phone numbers, e-mail addresses) of humans or legal entities. o operational data: Data necessary to the operation of networks and network related services and items. o RIR: Initials for "regional Internet registry." o IRR: Initials for "Internet routing registry." o forward lookup: a DNS lookup where a domain name is resolved to an IP address. o reverse lookup: a DNS lookup where an IP address is resolved to a domain name. o mining: In the context of this document, this term is specific to data mining. This is a methodical process to obtain the contents of directory service, usually as much as possible, not relevant to any immediate need. Data mining is often not a practice welcomed by registry operators. Newton Expires August 25, 2003 [Page 28] Internet-Draft crisp-requirements February 2003 Appendix B. Acknowledgements B.1 Forums The proceedings of the following public forums were used as input to the scope and requirements for this document: o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego, CA, USA o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, England o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, USA o Third UWho Consultation; November 19, 2001; Washington, DC, USA o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech Republic o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida o CENTR General Assembly, February 21-22, 2002; Rambouillet, France o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, Minnesota, USA B.2 Working Group This document is a work item of the Cross-Registry Internet Service Protocol (CRISP) Working Group in the Applications Area of the IETF. Discussions for this working group are held on the email list ietf-not43@lists.verisignlabs.com. To subscribe to this email list, send email to ietf-not43-request@lists.verisignlabs.com with a subject line of "subscribe". Archives of this list may be found out Newton Expires August 25, 2003 [Page 29] Internet-Draft crisp-requirements February 2003 http://lists.verisignlabs.com/pipermail/ietf-not43/. B.3 Contributions Comments, suggestions, and feedback of significant substance have been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric Hall, Patrick Mevzek, Marcos Sanz, and Vittorio Bertola. Newton Expires August 25, 2003 [Page 30] Internet-Draft crisp-requirements February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Newton Expires August 25, 2003 [Page 31] Internet-Draft crisp-requirements February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Newton Expires August 25, 2003 [Page 32] --=_zak-21817-1046125195-0001-2-- From hardie@qualcomm.com Mon Feb 24 22:55:16 2003 From: hardie@qualcomm.com (Ted Hardie) Date: Mon, 24 Feb 2003 14:55:16 -0800 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: <3E5A9CF0.2010403@ecotroph.net> Message-ID: <5.1.0.14.2.20030224144511.00a7c528@mage.qualcomm.com> Thanks to Andy and the other doc contributors for their work on this. This draft seems to have language to cover all of the issues raised either at or after the last IETF meeting, so I'd like to start a working group last call on it. Because the draft has not yet appeared in its official form, the last day of the last call will actually be two weeks from the draft's announcement and presence in the drafts directory. In the mean time, please read it as a candidate for advancement to Informational RFC and as the document by which the working group will conduct the protocol selection. After reviewing the document, I'd appreciate it if working group members sent a note to the list indicating that they have completed their review and their statement on the document. I'd prefer it if those comments had a subject line like "REVIEW: draft-ietf-crisp-requirement-04.txt"; they can be short (even as short as "ship it"), but more complete reviews are, of course, appreciated. This is not meant to be a ballot, but a way to collect the technical review comments on the document so we can assess where we are. regards, Ted Hardie At 05:30 PM 2/24/2003 -0500, Andrew Newton wrote: >I submitted this today, but considering this is -00 day, the drafts >administrator might be a little delayed in getting this out. > >So I'm attaching it for early viewing. > >-andy > > > > >Network Working Group A. Newton >Internet-Draft VeriSign, Inc. >Expires: August 25, 2003 February 24, 2003 > > > Cross Registry Internet Service Protocol (CRISP) Requirements > draft-ietf-crisp-requirements-04 > >Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on August 25, 2003. > >Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > >Abstract > > Internet registries expose administrative and operational data via > varying directory services. This document defines functional > requirements for the directory services of domain registries and the > common base requirements for extending the use of these services for > other types of Internet registries. > > > > > > > > > > >Newton Expires August 25, 2003 [Page 1] >Internet-Draft crisp-requirements February 2003 > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.2 Requirements Scope . . . . . . . . . . . . . . . . . . . . 4 > 1.3 Requirements Specification . . . . . . . . . . . . . . . . 4 > 2. Internet Registry Communities . . . . . . . . . . . . . . 6 > 2.1 Domain Name System Registries . . . . . . . . . . . . . . 6 > 2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6 > 2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6 > 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7 > 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7 > 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7 > 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7 > 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7 > 2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 8 > 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8 > 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8 > 2.4.1 Service Providers and Network Operators . . . . . . . . . 8 > 2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 8 > 2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9 > 2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 9 > 2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9 > 2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 9 > 2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9 > 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9 > 3. Functional Requirements . . . . . . . . . . . . . . . . . 10 > 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10 > 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10 > 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10 > 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 > 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11 > 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 12 > 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 12 > 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 12 > 3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12 > 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12 > 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 13 > 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13 > 3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 14 > 3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14 > 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 14 > 3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 16 > 3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 17 > 3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 17 > 3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 18 > > > >Newton Expires August 25, 2003 [Page 2] >Internet-Draft crisp-requirements February 2003 > > > 3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 18 > 3.2.8 Data Omission . . . . . . . . . . . . . . . . . . . . . . 19 > 3.2.9 Internationalization . . . . . . . . . . . . . . . . . . . 19 > 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 21 > 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 21 > 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 21 > 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 21 > 4.4 Structured Queries and Responses . . . . . . . . . . . . . 21 > 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 21 > 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 21 > 5. Internationalization Considerations . . . . . . . . . . . 22 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 > 7. Security Considerations . . . . . . . . . . . . . . . . . 24 > Normative References . . . . . . . . . . . . . . . . . . . 25 > Informative References . . . . . . . . . . . . . . . . . . 26 > Author's Address . . . . . . . . . . . . . . . . . . . . . 26 > A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 27 > B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28 > B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 28 > B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 28 > B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 29 > Intellectual Property and Copyright Statements . . . . . . 30 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 3] >Internet-Draft crisp-requirements February 2003 > > >1. Introduction > >1.1 Background > > The expansion and growth of the Internet has seen the registry > function of a traditionally centralized and managed Network > Information Center become the responsibility of various autonomous, > functionally disparate, and globally distributed Internet registries. > With the broadening number of Internet registries, the uses of their > administrative directory services have expanded from the original and > traditional use of the whois [6] protocol to include the use of whois > outside the scope of its specification, formal and informal > definitions of syntax, undocumented security mechanisms, the use of > other protocols, such as rwhois [5], to fulfill other needs, and > proposals for the use of other technologies such as LDAP [4] and XML. > >1.2 Requirements Scope > > The scope of the requirements captured in this document relate to the > directory services of Internet registries and their related > communities (Section 2.3,Section 2.4, and Section 2.5). This scoping > specifically targets the requirements of domain name registries > (Section 2.1) while acknowledging extensibility needs for possible > future support of the requirements for other registry (Section 2.2) > types. The requirements are of both the current use of these > directory services and the desired functionality based on input from > relevant forums (Appendix B.1). These requirements are not specific > to any protocol. Terms used in the definition of requirements in > this document may be found in the glossary (Appendix A). > > The scope of the requirements in this document are also restricted to > access of data from Internet registries. Requirements for > modification, addition, or provisioning of data in Internet > registries are out of scope. > >1.3 Requirements Specification > > The requirements captured in this document are for the purpose of > designing technical specifications. The words used in this document > for compliance with RFC2119 [3] do not reference or specify policy > and speak only to the capabilities in the derived technology. For > instance, this document may say that the protocol "MUST" support > certain features. An actual service operator is always free to > disable it (and then to return an error such as "permission denied".) > > Requirements in this document specifying the capabilities of the > protocol required for proper interaction between a client and a > server will be specified with the "MUST/SHOULD" language of RFC2119 > > > >Newton Expires August 25, 2003 [Page 4] >Internet-Draft crisp-requirements February 2003 > > > [3]. This document also contains language relating to the > interaction of a client with multiple servers to form a coherent, > cross-network service. Such service requirements will not be > described using RFC2119 language. > > While individual servers/service operators may not support all > features that the protocol can support, they must respect the > semantics of the protocol queries and responses. For example, a > server should not return referrals if it does not have referent data. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 5] >Internet-Draft crisp-requirements February 2003 > > >2. Internet Registry Communities > > The Internet registries are composed of various communities which > provide scope for the requirements in this document. These > communities can be generalized into the following categories: > registries, registrars, implementers, end-users, and other actors. > >2.1 Domain Name System Registries > >2.1.1 Domain Registries > > Domain registries are responsible for the registration of domains for > use with DNS [1] and forward lookups (i.e. does not include the > IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically > served two main domain functions: as the registry for a gTLD or as a > registry for a ccTLD. In some instances, one entity will operate > multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD > domain registry operator may be a governmental entity, > non-governmental, non-commercial entity, or a commercial entity. > > Some ccTLD's have second-level domain registrations similar in nature > to gTLD's or have distinctly separate entities operating second-level > domain registries similar in nature to gTLD's within the ccTLD. > > Domain registries usually follow one of two models for conducting > registrations of domains. The "thick" model is the more traditional > model. In a "thick" domain registry, the registry contains both the > operational data for the domain and the contact or social data > (Appendix A) for the domain. In this model, the registry is > typically the interface to the domain registrant but may also > interface with the domain registrant through domain registrars. The > "thin" model domain registry contains only operational data for > domains. In the "thin" model, contact or social data for the domain > are maintained by a domain registrar. > > Domain registries not described in this section (Section 2.1.1) are > not the subject of this document and may have requirements that are > out of scope for this subject matter. > >2.1.2 Domain Registrars > > Domain registrars accept domain registrations from registrants on > behalf of domain registries, both "thick" and "thin". In a "thin" > model registry/registrar system, a domain registrar maintains the > contact and social data of a domain while the registry maintains the > operational data of a domain. In a "thick" model registry/registrar > system, a domain registrar passes both the operational data and > contact data to the registry. Domain registrars may register a > > > >Newton Expires August 25, 2003 [Page 6] >Internet-Draft crisp-requirements February 2003 > > > domain on behalf of a registrant in more than one domain registry. > >2.2 Other Registries > >2.2.1 Regional Internet Registries > > Regional Internet Registries (RIR's) administer the allocation of IP > address space and autonomous system numbers. Each RIR serves a > specific geographic region, and collectively they service the entire > Internet. Each RIR is a membership-based, non-profit organization > that facilitates and implements global addressing policy based on the > direction of their regional community. > >2.2.2 Local Internet Registries > > Local Internet Registries (LIR's) and National Internet Registries > (NIR's) are sub-registries of RIR's and coordinate the same functions > of the RIR's for smaller, more specific geographic regions, sovereign > nations, and localities. > >2.2.3 Internet Routing Registries > > Internet Routing Registries are routing policy databases. Their > purpose is to provide information helpful in administering Internet > routers. Frequently, the syntax and contents are defined by RPSL > [7]. > > IRR's are operated by academic, commercial, governmental, and other > types of organizations, including several of the RIR's. The contents > of the databases vary and reflect the needs of the users directly > served (e.g. an ISP may look up route entries added by their > customers to decide whether to accept specific route advertisements > they receive). > > Unlike RIR and domain registry data, IRR data is often duplicated > between separate organizations. The IRR data has the unique > characteristics of being largely available through other sources > (i.e. it is advertised by the Internet routing protocols) and most > often having a common data format, RPSL. > >2.2.4 Incident Coordination Contact Registries > > Incident coordination contact registries allow operators of network > resources such as network infrastructure, network names, or network > services to register contact information for the purpose of providing > a means of incident notification. Using this type of registry, an > operators of network resources are provided information for > contacting the operator of another network resource from which an > > > >Newton Expires August 25, 2003 [Page 7] >Internet-Draft crisp-requirements February 2003 > > > incident may be occurring. > >2.2.5 Network Edge Resource Registries > > Network edge resource registries provide specific information about > "edge" resources. They are administered by the operators of the > resources. Examples of such registries are rwhois [5] servers > operated by networks to describe the assignment of address space > allocated by RIR's or LIR's and whois [6] servers operated by > networks to specifically announce routing policy of that network. > >2.3 Implementers > > Implementers of client software are often either affiliated with > large network operators, registry operators, or commercial entities > offering value-added services, or are general citizens of the > Internet. Much of the client software for use with the directory > services of Internet registries is either freely available, open > source, or both, or available as a service. Implementers of server > software are often affiliated with operators or commercial entities > specializing in the out-sourcing of development for Internet > registries. > >2.4 End Users > >2.4.1 Service Providers and Network Operators > > Service providers and network operators provide connectivity, > routing, and naming services to many other entities, some commercial > and some non-commercial, both large and small. Their operational and > administrative staff often interact with Internet registries on > behalf of other end-users. Service providers and network operators > interact with all of the Internet registry operators outlined in this > document on a frequent and consistent basis. For example, network > operators use the directory services of Internet registries to > determine contact information for network resources that have > technical problems. > >2.4.2 Intellectual Property Holders > > 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. > > > > >Newton Expires August 25, 2003 [Page 8] >Internet-Draft crisp-requirements February 2003 > > >2.4.3 Law Enforcement > > Law enforcement agencies use the directory services of Internet > registries to find information used to carry out the enforcement of > laws within their jurisdictions. > >2.4.4 Certificate Authorities > > Certificate authorities use the directory services of Internet > registries as part of their verification process when issuing > certificates for Internet named hosts. > >2.4.5 DNS Users > > Users of the Internet have client software that resolves domain names > to IP addresses. Often when trouble occurs in the resolution process > of DNS, these users trouble shoot system problems with the aid of > information from the directory services of Internet registries. > >2.4.6 Domain Registrants > > Entities given authority over a domain via purchase, lease, or grant > from a domain registry, either directly or via the services of a > domain registrar. > >2.4.7 Abusive Users > > The administrative directory services of Internet registries are > often the target of practices by abusive users. Using information > obtained from Internet registries, abusive users undertake certain > activities that are counter to the acceptable use of the information > as intended by a registry, registrar, or registrant. Many times, > these practices violate law in the jurisdiction of the user, > registry, registrar, or registrant. One example is the use of > Internet registry information for the use of sending unsolicited bulk > or commercial email. > >2.5 Other Actors > > Requirements must also consider the positions and policies of other > actors on the use of Internet registry directory services. These > actors include governments, non-governmental policy-setting bodies, > and other non-governmental organizations. > > > > > > > > >Newton Expires August 25, 2003 [Page 9] >Internet-Draft crisp-requirements February 2003 > > >3. Functional Requirements > > Functional requirements describe an overall need or process for which > the directory service is used by an Internet registry to fulfill its > obligations to provide access to its respective customers, members, > or other constituents. This section describes requirements in the > manner specified in Section 1.3. > >3.1 Base Functions > > This section describes basic directory service protocol requirements > for domain name (Section 2.1) and other (Section 2.2) registries. > Additional requirements, specific to domain registries, are described > in Domain Specific Functions (Section 3.2). > >3.1.1 Mining Prevention > > In order to prevent the inappropriate acquisition of data from an > Internet registry's directory service, many servers will limit the > amount of data that may be returned in a fixed time period from a > server to a client. This will most likely be especially true for > anonymous access uses (see Section 3.1.4). > > 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. Support for varying service models in the > effort to limit data and prevent data mining may or may not have a > direct impact on the client-to-server protocol. > > Section 3.2.5 also contains protocol requirements which are relevant > to client/server interaction in certain domain registry service > models. > >3.1.2 Minimal Technical Reinvention > > The protocol MUST NOT employ unique technology solutions for all > aspects and layers above the network and transport layers and SHOULD > make use of existing technology standards where applicable. The > protocol MUST employ the use of network and transport layer standards > as defined by the Internet Engineering Task Force. The protocol MUST > define one or more transport mechanisms for mandatory implementation. > >3.1.3 Standard and Extensible Schemas > >3.1.3.1 Protocol Requirement > > The protocol MUST contain standard schemas for the exchange of data > needed to implement the functionality in this document. In addition, > > > >Newton Expires August 25, 2003 [Page 10] >Internet-Draft crisp-requirements February 2003 > > > 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 the meaning > of the identifying tags. > >3.1.3.2 Service Description > > The client-to-server protocol must define a standard set of data > structures or schemas to be used when exchanging information. It > must also poses the ability to allow for the use of newer data > structures that are currently nor foreseen by this specification. In > both cases, the description and specification of both types of data > structures or schemas must be done in the same way (i.e. the same > schema language). > > The schemas must also be capable of "tagging" data with a unique > identifier. This identifier can then be used to localize the name of > that type of data. For instance, a piece of data may have the value > "Bob" and its type identified with the number "5.1". Client software > could use this to display "Name: Bob" in an English locale or > "Nombre: Bob" in a Spanish locale. > >3.1.4 Level of Access > >3.1.4.1 Protocol Requirement > > The protocol MUST NOT prohibit an operator from granularly 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 > > > >Newton Expires August 25, 2003 [Page 11] >Internet-Draft crisp-requirements February 2003 > > > users > > The types of access allowed by a server will most likely vary from > one operator to the next. > >3.1.5 Client Processing > > The protocol MUST be capable of allowing machine parsable requests > and responses. > >3.1.6 Entity Referencing > > There MUST be a mechanism for an entity contained within a server to > be referenced uniquely by an entry in another server. > >3.1.7 Decentralization > >3.1.7.1 Protocol Requirement > > The protocol 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 must not require this. > >3.1.8 Query of Access Permission > >3.1.8.1 Protocol Requirement > > The protocol MUST provide a mechanism allowing a client to determine > if a query will be denied before the query is submitted according to > the appropriate policies of the operator. > >3.1.8.2 Service Description > > Because usage scenarios will differ depending on both policy and type > of service, some server operators may want to provide the ability for > a client to predetermine its ability to retrieve data from a query. > However, some operators will not allow this for security reasons, > policy restrictions, or other matters. > >3.1.9 Authentication Distribution > > > > >Newton Expires August 25, 2003 [Page 12] >Internet-Draft crisp-requirements February 2003 > > >3.1.9.1 Protocol Requirement > > The protocol MUST NOT require any Internet registry to participate in > any authentication system. The protocol MUST NOT prohibit the > participation by an Internet registry in federated, distributed > authentication systems. > >3.1.9.2 Service Description > > Some server operators may have a need to delegate authentication to > another party or participate in a system where authentication > information is distributed. However, the ability to operate a CRISP > compliant server must not require this. > >3.1.10 Base Error Responses > > The protocol MUST be capable of returning the following types of > non-result or error responses to all lookups and searches: > > o permission denied - a response indicating that the search or > lookup has failed due to insufficient authorization. > > o not found - the desired results do not exist. > > o insufficient resources - the search or lookup requires resources > that cannot be allocated. > > >3.1.11 Query Distribution > >3.1.11.1 Protocol Requirement > > The protocol MUST NOT prohibit a server from participating in a query > distribution system. > >3.1.11.2 Service Description > > For lookups and searches requiring distribution of queries, the > client must be allowed to distribute these queries among the > participants in an established mesh of server operators. It is not a > requirement that the protocol enable the discovery of servers, but > cooperating servers should be able to intelligently handle > distribution with its established mesh. Individual server operators > will respond to all queries received according to their policies for > authentication, privacy, and performance. > > However, the ability to operate a CRISP compliant server must not > require the participation in any query distribution system. > > > >Newton Expires August 25, 2003 [Page 13] >Internet-Draft crisp-requirements February 2003 > > >3.1.12 Protocol and Schema Versioning > >3.1.12.1 Protocol Requirements > > The protocol MUST provide a means by which the end-systems can either > identify or negotiate over the protocol version to be used for any > query or set of queries. > > All resource-specific schema MUST provide a version identifier > attribute which uniquely and unambiguously identifies the version of > the schema being returned in the answer set to a query. > >3.1.12.2 Service Description > > The service should allow end-systems using different protocol > versions to fallback to a mutually supported protocol version. If > this is not possible, the service must provide a meaningful error > which indicates that this is the specific case. > > The service must suggest negotiation and/or recovery mechanisms for > clients to use when an unknown schema version is received. > >3.1.13 Relay Bag > >3.1.13.1 Protocol Requirement > > When issuing a referral, the protocol MUST be capable of supplying a > relay bag from the server to the client, and the protocol MUST be > capable of allowing the client to submit this relay bag with a query > to the referred server. The use of the relay bag MUST be OPTIONAL. > The protocol MUST NOT make any assumptions regarding the contents of > the relay bag, but the relay bag MUST be described using the schema > language of the protocol. > >3.1.13.2 Service Description > > In some models where service coordination among participating server > operators is utilized, there might be needs to allow a referring > server to pass operator-to-operator coordination data along with the > referral to the referent server. Such needs might be auditing or > tracking. This feature requirement allows a server to pass to the > client a flexible container of unspecified data ("bag") that the > client should pass to the referent server. The bag has no meaning to > the client. > >3.2 Domain Specific Functions > > These functions describe requirements specifically needed by domain > > > >Newton Expires August 25, 2003 [Page 14] >Internet-Draft crisp-requirements February 2003 > > > registries (Section 2.1.1) and domain registrars (Section 2.1.2). > Requirements specific to other registries (Section 2.2) MUST be > specified separately. No compliant server operator is required to > support the functions required by every registry type. > >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-qualified domain name. > > See Section 3.2.3 for the requirements regarding the expected return > values. > >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 return part or > all of the information. See Section 3.2.3. > >3.2.2 Searches > >3.2.2.1 Protocol Requirement > > The protocol MUST contain the following search functions: > > 1. Domain name search given an exact match or reasonable subset of a > name. This search SHOULD allow for parameters and qualifiers > designed to allow better matching of internationalized domain > names and SHOULD allow for both exact and partial matching within > the limits of internationalized domain names. This search SHOULD > NOT require special transformations of internationalized domain > names to accommodate this search. This search MUST provide a > means to narrow the search by names delegated under a particular > TLD. > > 2. Domain registrant search by either exact name or partial name > > > >Newton Expires August 25, 2003 [Page 15] >Internet-Draft crisp-requirements February 2003 > > > match with the ability to narrow the search to registrants of a > particular TLD. > > 3. Domains hosted by a nameserver given the fully-qualified host > name or IP address of a nameserver. > > See Section 3.2.3 for the requirements regarding the expected return > values. > >3.2.2.2 Service Description > > Depending on the policy and need of an Internet registry, a server > operator may not allow all or any of these searches to return part or > all of the information. See Section 3.1.4. Access to information > resulting from these searches may also be limited, depending on > policy, by quantity. Section 3.2.5 describes these types of > restrictions. > > Some Internet registries may also be participating in a query > distribution system. See Section 3.1.11. > >3.2.3 Information Sets > >3.2.3.1 Protocol Requirements > > 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 > protocols. > > The schema MUST be capable of expressing the following information > for domains: > > o activation status > > o registrant > > o nameservers > > o technical, billing or other contacts > > o registry delegating the domain > > o registrar for the domain > > The data set for domains MUST be able to express arbitrary textual > information for extensions on an individual operator basis. Examples > of such information are license agreements, authorized use policies, > > > >Newton Expires August 25, 2003 [Page 16] >Internet-Draft crisp-requirements February 2003 > > > extended status notifications, marketing/for sale notices, and URI > references to other sources. > >3.2.3.2 Service Description > > It is not expected that every Internet registry supply all of the > information spelled out above, however the schemas employed by the > protocol must be capable of expressing this information should a > registry need to provide it. > > The following sections describe requirements relative to the use of > schemas with respect to individual registry need and policy: > > o Section 3.2.8 > > o Section 3.2.5 > > o Section 3.1.4 > > o Section 3.1.1 > > >3.2.4 Serialization Support > > The schemas used by the protocol SHOULD be capable of off-line > serialization > > Off-line serialization allows for implementation independent > operations such as backup and recovery, load-balancing, etc. This > MAY also make possible, in whole or in part, data escrow capabilities > and other usages, however such usages are out of the scope of this > document. > >3.2.5 Result Set Limits > >3.2.5.1 Protocol Requirement > > The protocol MUST contain a feature, used at the discretion of a > server operator, to allow a server to express to a client a limit on > the number of results from searches and lookups. When returning > result sets, the protocol MUST be able to make the following > distinctions: > > 1. an empty result set. > > 2. a result set truncated for the purpose of improving performance > bottlenecks. > > > > >Newton Expires August 25, 2003 [Page 17] >Internet-Draft crisp-requirements February 2003 > > > 3. a result set truncated to comply with Section 3.1.1 > > >3.2.5.2 Service Description > > Client software will operate more usefully if it can understand > reasons for the truncation of result sets. Of course, some Internet > registries may not be able to expose their policies for the limiting > of result sets, but, when it is possible, clients will have a better > operational view. This may eliminate re-queries and other repeated > actions that are not desirable. > >3.2.6 DNS Delegation Referencing > >3.2.6.1 Protocol Requirement > > The protocol MUST use the delegation authority model available in DNS > [1] as the primary means for determining the authoritative source for > information regarding domains or any other objects when applicable. > >3.2.6.2 Service Description > > The intent of this requirement is to have clients use the DNS > delegation model to find servers authoritative for resources instead > of using a master or central server containing pointer information. > In other words, when a resource is naturally mapped by DNS, the > desired behavior is to consult the DNS to find an authoritative > server containing information about that resource. Using > 'example.com', the authoritative server for information about > example.com according to the registrant of that domain may be found > by querying the DNS zone for example.com. To find the registry > information for example.com, the DNS zone for com should be queried. > > There are cases where resources will not naturally map into the DNS > delegation hierarchy. This requirement is not meant to force such a > mapping. > >3.2.7 Distribution for Domain Registry Types > >3.2.7.1 Protocol Requirement > > The protocol MUST NOT prohibit the distribution of data to exclude > any of the registry/registrar models stated in Section 2.1.1. The > protocol MUST be capable of expressing referrals and entity > references between the various models described in Section 2.1.1. > >3.2.7.2 Service Description > > > > >Newton Expires August 25, 2003 [Page 18] >Internet-Draft crisp-requirements February 2003 > > > Depending on the domain registry/registrar model in use, technical > data for a domain may only reside in one server while contact data > for the same domain may only reside in a server operated by a > separate entity. However, in many uses, this is not the situation. > Therefore, the service must accommodate for the various registration > distribution models of domain registry types described in Section > 2.1.1 while complying with Section 3.1.7. > >3.2.8 Data Omission > >3.2.8.1 Protocol Requirement > > When a value in an answer to a query cannot be given due to policy > constraints, 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 > > The protocol MAY define other values for this purpose, but MUST > define values defined above at a minimum. > >3.2.8.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 accommodate this need while > client software will be 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. > >3.2.9 Internationalization > > The schema defining domain related resources MUST conform to RFC 2277 > [2] regarding textual data. In particular, the schema MUST be able > to indicate the charset and language in use with unstructured textual > data. > > The protocol MUST be able to support multiple representations of > contact data, with these representations complying with the > requirements in Section 3.2.3. The protocol MUST be able to provide > contact data in UTF-8 and SHOULD be able to provide contact data in > > > >Newton Expires August 25, 2003 [Page 19] >Internet-Draft crisp-requirements February 2003 > > > US-ASCII, other character sets, and capable of specifying the > language of the data. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 20] >Internet-Draft crisp-requirements February 2003 > > >4. Feature Requirements > > Feature requirements describe the perceived need derived from the > functional requirements for specific technical criteria of the > directory service. This section describes requirements in the manner > specified in Section 1.3. > >4.1 Client Authentication > > Entities accessing the service (users) MUST be provided a mechanism > for passing credentials to a server for the purpose of > authentication. The protocol MUST provide a mechanism capable of > employing many authentication types and capable of extension for > future authentication types. > >4.2 Referrals > > To distribute queries for search continuations and to issue entity > references, the protocol MUST provide a referral mechanism. > >4.3 Common Referral Mechanism > > To distribute queries for search continuations and to issue entity > references, the protocol MUST define a common referral scheme and > syntax. > >4.4 Structured Queries and Responses > > To provide for machine consumption as well as human consumption, the > protocol MUST employ structured queries and responses. > >4.5 Existing Schema Language > > To provide structured queries and responses and allow for minimal > technological reinvention, the protocol MUST employ a pre-existing > schema language. > >4.6 Defined Schemas > > To provide for machine consumption as well as human consumption, the > protocol MUST define schemas for use by the structured queries and > responses. > > > > > > > > > >Newton Expires August 25, 2003 [Page 21] >Internet-Draft crisp-requirements February 2003 > > >5. Internationalization Considerations > > Requirements defined in this document MUST consider the best > practices spelled out in [2]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 22] >Internet-Draft crisp-requirements February 2003 > > >6. IANA Considerations > > IANA consideration for any service meeting these requirements will > depend upon the technologies chosen and MUST be specified by any > document describing such a service. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 23] >Internet-Draft crisp-requirements February 2003 > > >7. Security Considerations > > This document contains requirements for the validation of > authenticated entities and the access of authenticated entities > compared with the access of non-authenticated entities. This > document does not define the mechanism for validation of > authenticated entities. Requirements defined in this document MUST > allow for the implementation of this mechanism according best common > practices. > > The requirement in Section 3.1.4 must be weighed against other > requirements specifying search or lookup capabilities. > > This document contains requirements for referrals and entity > references. Client implementations based on these requirements > SHOULD take proper care in the safe-guarding of credential > information when resolving referrals or entity references according > to best common practices. > > This document contains requirements for the distribution of queries > among a mesh of participating service providers. Protocols proposed > to meet these requirements must be able to protect against the use of > that distribution system as a vector of distributed denial of service > attacks or unauthorized data mining. > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 24] >Internet-Draft crisp-requirements February 2003 > > >Normative References > > [1] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", > BCP 18, RFC 2277, January 1998. > > [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 25] >Internet-Draft crisp-requirements February 2003 > > >Informative References > > [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access > Protocol (v3)", RFC 2251, December 1997. > > [5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. > Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, > June 1997. > > [6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC > 954, October 1985. > > [7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., > Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing > Policy Specification Language (RPSL)", RFC 2622, June 1999. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 26] >Internet-Draft crisp-requirements February 2003 > > >URIs > > [8] > > [9] > > [10] Final-WhoIsPanel-Aug15-Resume.pdf> > > [11] min_database.html> > > [12] > > >Author's Address > > Andrew L. Newton > VeriSign, Inc. > 21355 Ridgetop Circle > Sterling, VA 20166 > USA > > Phone: +1 703 948 3382 > EMail: anewton@verisignlabs.com; anewton@ecotroph.net > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 27] >Internet-Draft crisp-requirements February 2003 > > >Appendix A. Glossary > > o TLD: Initials for "top level domain." Referes to domains in DNS > [1]that are hierarchically at the level just beneath the root. > > o ccTLD: Initials for "country code top level domain." TLD's which > use one of the two character country codes defined by ISO. > > o gTLD: Initials for "generic top level domain." TLD's that do not > use one of the two character country codes defined by ISO. > > o social data: Data containing names and contact information (i.e. > postal addresses, phone numbers, e-mail addresses) of humans or > legal entities. > > o operational data: Data necessary to the operation of networks and > network related services and items. > > o RIR: Initials for "regional Internet registry." > > o IRR: Initials for "Internet routing registry." > > o forward lookup: a DNS lookup where a domain name is resolved to an > IP address. > > o reverse lookup: a DNS lookup where an IP address is resolved to a > domain name. > > o mining: In the context of this document, this term is specific to > data mining. This is a methodical process to obtain the contents > of directory service, usually as much as possible, not relevant to > any immediate need. Data mining is often not a practice welcomed > by registry operators. > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 28] >Internet-Draft crisp-requirements February 2003 > > >Appendix B. Acknowledgements > >B.1 Forums > > The proceedings of the following public forums were used as input to > the scope and requirements for this document: > > o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego, > CA, USA > > o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, > England > > o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA > > o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, > USA > > o Third UWho Consultation; November 19, 2001; Washington, DC, USA > > o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic > > o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech > Republic > > o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA > > o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands > > o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The > Netherlands > > o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida > > o CENTR General Assembly, February 21-22, 2002; Rambouillet, France > > o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, > Minnesota, USA > > >B.2 Working Group > > This document is a work item of the Cross-Registry Internet Service > Protocol (CRISP) Working Group in the Applications Area of the IETF. > Discussions for this working group are held on the email list > ietf-not43@lists.verisignlabs.com. To subscribe to this email list, > send email to ietf-not43-request@lists.verisignlabs.com with a > subject line of "subscribe". Archives of this list may be found out > > > >Newton Expires August 25, 2003 [Page 29] >Internet-Draft crisp-requirements February 2003 > > > http://lists.verisignlabs.com/pipermail/ietf-not43/. > >B.3 Contributions > > Comments, suggestions, and feedback of significant substance have > been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, > Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric > Hall, Patrick Mevzek, Marcos Sanz, and Vittorio Bertola. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 30] >Internet-Draft crisp-requirements February 2003 > > >Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > >Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > >Newton Expires August 25, 2003 [Page 31] >Internet-Draft crisp-requirements February 2003 > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > >Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Newton Expires August 25, 2003 [Page 32] From leslie@thinkingcat.com Tue Feb 25 09:45:56 2003 From: leslie@thinkingcat.com (Leslie Daigle) Date: Tue, 25 Feb 2003 04:45:56 -0500 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt References: <5.1.0.14.2.20030224144511.00a7c528@mage.qualcomm.com> Message-ID: Hmmm.... I thought we'd reached agreement on some additional text re. relay bags: http://lists.verisignlabs.com/pipermail/ietf-not43/2003-February/000477.html which doesn't appear here. Leslie. Ted Hardie wrote: > Thanks to Andy and the other doc contributors for their work on this. > > This draft seems to have language to cover all of the issues raised either > at or after the last IETF meeting, so I'd like to start a working group > last call on it. Because the draft has not yet appeared in its official > form, the last day of the last call will actually be two weeks from > the draft's announcement and presence in the drafts directory. In > the mean time, please read it as a candidate for advancement > to Informational RFC and as the document by which the working group > will conduct the protocol selection. > > After reviewing the document, I'd appreciate it if working group members > sent > a note to the list indicating that they have completed their review and > their > statement on the document. I'd prefer it if those comments had a > subject line like "REVIEW: draft-ietf-crisp-requirement-04.txt"; they > can be short (even as short as "ship it"), but more complete reviews > are, of course, appreciated. This is not meant to be a ballot, but a way > to collect the technical review comments on the document so we > can assess where we are. > > regards, > Ted Hardie > > [snip] -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From ehall@ehsco.com Tue Feb 25 11:08:27 2003 From: ehall@ehsco.com (Eric A. Hall) Date: Tue, 25 Feb 2003 05:08:27 -0600 Subject: [Ietf-not43] draft-ietf-crisp-requirements-04.txt [REVIEW] In-Reply-To: <3E5A9CF0.2010403@ecotroph.net> References: <3E5A9CF0.2010403@ecotroph.net> Message-ID: <3E5B4EAB.7000702@ehsco.com> on 2/24/2003 4:30 PM Andrew Newton wrote: > I submitted this today This seems to cover everything pretty well and is flexible where it needs to be. Thanks for doing this. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton@ecotroph.net Tue Feb 25 13:28:20 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Tue, 25 Feb 2003 08:28:20 -0500 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt In-Reply-To: References: <5.1.0.14.2.20030224144511.00a7c528@mage.qualcomm.com> Message-ID: <3E5B6F74.0@ecotroph.net> #@!*%! (now hitting my head against a wall!) I think you are correct (I blame my cat). To be clear, this is the following text missing? > The protocol MUST provide different error messages to > indicate whether the bag is of unrecognized format > (permanent failure), if it contains unacceptable > data (permanent failure), or if it contains data > that means processing is refused at this time (transient > failure). Some text talking about: > I think it's also important to make it clear that there > will be no more than one bag per referral. If the referrant > server generates another referral itself, it must supply a new > bag (and it doesn't matter whether that's the same as > the old, cumulative, or entirely new). To be clear, let's decide on the wording: There MUST be only one bag per referral. If a referent server generates another referral, any bag accompanying that referral MUST be considered unrelated to the original bag. And: > The client MUST pass the bag as part of any query made to a referrant > server as a result of this referreral. While we're at it, perhaps a quick blurb at the top of the requirement defining "bag". So section should read as follows (note I merged the last MUST sentence at the end of the first requirement paragraph): 3.1.13 Relay Bag The term "bag" in this section refers to a flexible container of content. 3.1.13.1 Protocol Requirement When issuing a referral, the protocol MUST be capable of supplying a relay bag from the server to the client, and the protocol MUST be capable of allowing the client to submit this relay bag with a query to the referred server. The use of the relay bag MUST be OPTIONAL. The protocol MUST NOT make any assumptions regarding the contents of the relay bag, but the relay bag MUST be described using the schema language of the protocol. The client MUST pass the bag as part of any query made to a referent server as a result of a referral. The protocol MUST provide different error messages to indicate whether the bag is of unrecognized format (permanent failure), if it contains unacceptable data (permanent failure), or if it contains data that means processing is refused at this time (transient failure). There MUST be only one bag per referral. If a referent server generates another referral, any bag accompanying that referral MUST be considered unrelated to the original bag. 3.1.13.2 Service Description In some models where service coordination among participating server operators is utilized, there might be needs to allow a referring server to pass operator-to-operator coordination data along with the referral to the referent server. Such needs might be auditing or tracking. This feature requirement allows a server to pass to the client a flexible container of unspecified data ("bag") that the client should pass to the referent server. The bag has no meaning to the client. -andy Leslie Daigle wrote: > > Hmmm.... > > I thought we'd reached agreement on some additional text > re. relay bags: > > http://lists.verisignlabs.com/pipermail/ietf-not43/2003-February/000477.html > > > which doesn't appear here. > > Leslie. From leslie@thinkingcat.com Tue Feb 25 14:38:48 2003 From: leslie@thinkingcat.com (Leslie Daigle) Date: Tue, 25 Feb 2003 09:38:48 -0500 Subject: [Ietf-not43] WG Last call: draft-ietf-crisp-requirements-04.txt References: <5.1.0.14.2.20030224144511.00a7c528@mage.qualcomm.com> <3E5B6F74.0@ecotroph.net> Message-ID: Andrew Newton wrote: > I think you are correct (I blame my cat). To be clear, this is the I don't think you need to blame your cat for my being correct :-) > So section should read as follows (note I merged the last MUST sentence > at the end of the first requirement paragraph): [snip] Yep, that pretty much covers it. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From JimFleming@ameritech.net Tue Feb 25 14:44:42 2003 From: JimFleming@ameritech.net (Jim Fleming) Date: Tue, 25 Feb 2003 08:44:42 -0600 Subject: [Ietf-not43] "Reality:"....32-bit reality or 128-bit Reality ? References: <5.1.0.14.2.20030224144511.00a7c528@mage.qualcomm.com> <3E5B6F74.0@ecotroph.net> Message-ID: <0ac401c2dcdc$6f3dc470$8500a8c0@repligate> ----- Original Message ----- From: "Leslie Daigle" > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- "Reality:"....32-bit reality or 128-bit Reality ? ...or M$ and V$ reality ? http://IPv8.no-ip.com http://www.go-mono.com/ http://www.knoppix.com http://www.netfilter.org http://www.digium.com http://www.asterisk.org http://www.openss7.org http://www.zapatatelephony.org http://www.new.net http://IPv8.dyn.ee Jim Fleming Inter.C@T.Inter.NAT Consultant http://www.Unir.NET http://www.Unir.com http://www.Uni%ae.com http://www.Uni®.com From shollenbeck@verisign.com Thu Feb 27 21:19:54 2003 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Thu, 27 Feb 2003 16:19:54 -0500 Subject: [Ietf-not43] Result vs. Entity Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370745@vsvapostal3.prod.netsol.com> Someone just brought a possible requirements wording issue to my attention. In EPP, we allow an IP address to be associated with multiple server names/aliases. The CRISP requirements draft describes lookup responses like this: > 3.2.1 Lookups > > 3.2.1.1 Protocol Requirement > > The protocol MUST contain the following lookup functions: > > ... > > 2. Nameserver lookup given a fully-qualified host name or IP address > of a nameserver. > > ... > > 3.2.1.2 Service Description > > These lookups are all single index queries and should produce zero or > only one result. It's entirely possible that an IP address query might need to return multiple host names, so perhaps the word "result" is a bit misleading in the service description. Would it be possible to change "result" to a word like "entity" instead?: "...and should return zero or one entity." -Scott- From hardie@qualcomm.com Thu Feb 27 22:27:59 2003 From: hardie@qualcomm.com (Ted Hardie) Date: Thu, 27 Feb 2003 14:27:59 -0800 Subject: [Ietf-not43] Result vs. Entity In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370745@vsvapostal3.prod. netsol.com> Message-ID: <5.1.0.14.2.20030227140225.00aaeb18@mage.qualcomm.com> Scott, Thanks for your review of the document. May I ask for a pointer (or pointers) in the EPP document set that describes the associations you're concerned about? That may help me follow the problem here. My reading of the CRISP requirement is to handle the lookup equivalent to: "I want to know the administrative data about $FOO" where $FOO is a nameserver which might be referenced by an FQDN, an IPv4 address or and IPv6 address". If $FOO is referenced by an IPv4 or IPv6 address to which multiple names are bound, I would expect the protocol to return all of them in a single result. This doesn't mean it should elide data; it just means it treats it as a lookup rather than as a search. So, assume I believe that 216.168.254.21 is a nameserver and I use CRISP to look up the administrative data associated with it. I get back the admin data associated which is appropriate to my level of access: (Admin Contact, Geo Location, Name1, Name2, and Name3) or whatever the equivalent is in the chosen protocol. These might have to be separate records (especially, it strike me, in the presence of anycast nameservers), but they would still be returned as a single result of the lookup. Am I off base from others' understanding of this? regards, Ted At 04:19 PM 2/27/2003 -0500, Hollenbeck, Scott wrote: >Someone just brought a possible requirements wording issue to my attention. >In EPP, we allow an IP address to be associated with multiple server >names/aliases. The CRISP requirements draft describes lookup responses like >this: > > > 3.2.1 Lookups > > > > 3.2.1.1 Protocol Requirement > > > > The protocol MUST contain the following lookup functions: > > > > ... > > > > 2. Nameserver lookup given a fully-qualified host name or IP address > > of a nameserver. > > > > ... > > > > 3.2.1.2 Service Description > > > > These lookups are all single index queries and should produce zero or > > only one result. > >It's entirely possible that an IP address query might need to return >multiple host names, so perhaps the word "result" is a bit misleading in the >service description. Would it be possible to change "result" to a word like >"entity" instead?: > >"...and should return zero or one entity." > >-Scott- >_______________________________________________ >Ietf-not43 mailing list >Ietf-not43@lists.verisignlabs.com >http://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From anewton@ecotroph.net Thu Feb 27 22:51:41 2003 From: anewton@ecotroph.net (Andrew Newton) Date: Thu, 27 Feb 2003 17:51:41 -0500 Subject: [Ietf-not43] Result vs. Entity In-Reply-To: <5.1.0.14.2.20030227140225.00aaeb18@mage.qualcomm.com> References: <5.1.0.14.2.20030227140225.00aaeb18@mage.qualcomm.com> Message-ID: <3E5E967D.3040600@ecotroph.net> Ted Hardie wrote: > If $FOO is referenced by an IPv4 or IPv6 address > to which multiple names are bound, I would expect the protocol > to return all of them in a single result. This doesn't mean it > should elide data; it just means it treats it as a lookup rather than > as a search. This is how I always thought of it too. Perhaps it could be interpretted that each individual name is a separate result. If this is the confusion, perhaps some words to describing result would fix that. I'm find with "entity", too. -andy From shollenbeck@verisign.com Thu Feb 27 23:56:05 2003 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Thu, 27 Feb 2003 18:56:05 -0500 Subject: [Ietf-not43] Result vs. Entity Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370747@vsvapostal3.prod.netsol.com> > Thanks for your review of the document. May I ask for > a pointer (or pointers) in the EPP document set that > describes the associations > you're concerned about? That may help me follow the problem > here. RFC 3375, section 3.4.2-[3]: http://www.ietf.org/rfc/rfc3375.txt > My > reading of the CRISP requirement is to handle the lookup > equivalent to: > > "I want to know the administrative data about $FOO" where $FOO > is a nameserver which might be referenced by an FQDN, an IPv4 address > or and IPv6 address". If $FOO is referenced by an IPv4 or > IPv6 address > to which multiple names are bound, I would expect the protocol > to return all of them in a single result. This doesn't mean it > should elide data; it just means it treats it as a lookup rather than > as a search. So, assume I believe that 216.168.254.21 is a > nameserver and > I use CRISP to look up the administrative data associated > with it. I get > back the > admin data associated which is appropriate to my level of access: > (Admin Contact, Geo Location, Name1, Name2, and Name3) or whatever > the equivalent is in the chosen protocol. These might have to > be separate > records (especially, it strike me, in the presence of anycast > nameservers), > but they would still be returned as a single result of the lookup. If that's the intent, good! I'm just not sure that the term "one result" is clear enough to note that a result may have multiple elements. -Scott-