From ggm at apnic.net Tue Jul 1 12:41:36 2003 From: ggm at apnic.net (George Michaelson) Date: Mon Jun 30 21:41:49 2003 Subject: [Ietf-not43] Krispy Creme gets the fortune mag review In-Reply-To: References: <20030625100237.1c1fe3c2.ggm@apnic.net> Message-ID: <20030701114136.7adbbb72.ggm@apnic.net> [ I know, not very work related, but we did notice the 'morphic resonance' of this WG title in S.F. ... -ggm] http://www.fortune.com/fortune/print/0,15935,460119,00.html I think we need this on tee-shirts! "...Unless the fat police run riot across this land, Krispy Kreme is here to stay. It isn't some fly-by-night dot-com. There's 66 years of history here. ..." -George From Peter.Gietz at daasi.de Tue Jul 1 20:16:01 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Tue Jul 1 13:16:17 2003 Subject: [Ietf-not43] new requirements matrix In-Reply-To: References: Message-ID: <3F01C1D1.107@daasi.de> Today I wanted to start working on comparing the LDAP proposal with the matrix, as I promissed at the last meeting. Ok. I will also wait for the new matrix then ... Cheers, Peter Rick Wesson wrote: > interupt willing i'll have a new version of the matricks out by EOB > tuesday. > > -rick > > > On Wed, 18 Jun 2003, Andrew Newton wrote: > > >>I guess that would depend on Rick's timeframe. >> >>Rick? >> >>Edward Lewis wrote: >> >>>I'm waddling through the IRIS documents now, a bit delayed for various >>>reasons. Should I just print Scott's attached matrix or wait for Rick >>>to send one? >>> >>>At 13:27 -0400 6/17/03, Andrew Newton wrote: >>> >>> >>>>Long story short, it's probably best that Rick make the edits to the >>>>source, >>>>since he's the matrix maintainer, and regen the ASCII. >>> >>> > > -rick > > =================================================================================== > Ratio of National Debt of the United States to the age of the Universe in > years, 541 to 1. If I had one dollar for every year the universe existed and > used it to pay down the national debt, it wouldn't even be enough for the > minimum monthly payment. > > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From wessorh at ar.com Tue Jul 1 16:21:00 2003 From: wessorh at ar.com (Rick Wesson) Date: Tue Jul 1 18:21:20 2003 Subject: [Ietf-not43] new requirements matrix In-Reply-To: <3F01C1D1.107@daasi.de> Message-ID: the updated matrix is at http://wesson.us/crisp-matrix.html I believe I have several of scotts comments to incorporate but the analysis of IRIS has been incorporated. Once the document stableizes I'll post a text copy to the list. For nits please reference the section number in the requirements document not the integer sequence number in the text post of the requirements matrix -rick On Tue, 1 Jul 2003, Peter Gietz wrote: > Today I wanted to start working on comparing the LDAP proposal with the > matrix, as I promissed at the last meeting. > > Ok. I will also wait for the new matrix then ... > > Cheers, > > Peter > > Rick Wesson wrote: > > interupt willing i'll have a new version of the matricks out by EOB > > tuesday. > > > > -rick > > > > > > On Wed, 18 Jun 2003, Andrew Newton wrote: > > > > > >>I guess that would depend on Rick's timeframe. > >> > >>Rick? > >> > >>Edward Lewis wrote: > >> > >>>I'm waddling through the IRIS documents now, a bit delayed for various > >>>reasons. Should I just print Scott's attached matrix or wait for Rick > >>>to send one? > >>> > >>>At 13:27 -0400 6/17/03, Andrew Newton wrote: > >>> > >>> > >>>>Long story short, it's probably best that Rick make the edits to the > >>>>source, > >>>>since he's the matrix maintainer, and regen the ASCII. > >>> > >>> > > > > -rick > > > > =================================================================================== > > Ratio of National Debt of the United States to the age of the Universe in > > years, 541 to 1. If I had one dollar for every year the universe existed and > > used it to pay down the national debt, it wouldn't even be enough for the > > minimum monthly payment. > > > > > > _______________________________________________ > > Ietf-not43 mailing list > > Ietf-not43@lists.verisignlabs.com > > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > > -- > _______________________________________________________________________ > > Peter Gietz (CEO) > DAASI International GmbH phone: +49 7071 2970336 > Wilhelmstr. 106 Fax: +49 7071 295114 > D-72074 T?bingen email: peter.gietz@daasi.de > Germany Web: www.daasi.de > > Directory Applications for Advanced Security and Information Management > _______________________________________________________________________ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > -rick =================================================================================== Ratio of National Debt of the United States to the age of the Universe in years, 541 to 1. If I had one dollar for every year the universe existed and used it to pay down the national debt, it wouldn't even be enough for the minimum monthly payment. From wessorh at ar.com Tue Jul 1 22:02:20 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Jul 2 07:50:38 2003 Subject: [Ietf-not43] matrix in text Message-ID: and thanks to andy here is the matrix in text... the html version is available at http://wesson.us/crisp-matrix.html please refer to the section when suggesting a fix. -rick CRISP Technical Proposal Evaluation Matrix +------------------------------------------------------------------------+ | Requirement | IRIS | LW | Comment | |------------------------------------------------------------------------| | Sample | |------------------------------------------------------------------------| | The protocl MUST be capable of | NO | YES | IRIS only gives the | | walking and chewing gum at the | | | appearance of | | same time. | | | walking and chewing | | | | | gum simultaneously, | | | | | but it in fact | | | | | requires two | | | | | separate CPU clock | | | | | cycles. On the other | | | | | hand, LW does the | | | | | walking on the | | | | | rising edge of the | | | | | cycle and the gum | | | | | chewing on the | | | | | falling edge of the | | | | | cycle. | |------------------------------------------------------------------------| | Section 3.1.2 | |------------------------------------------------------------------------| | The protocol MUST NOT employ | YES | | | | 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 | YES | | | | of network and transport layer | | | | | standards as defined by the | | | | | Internet Engineering Task Force. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST define one or | | | [iris] needs | | more transport mechanisms for | | | additional text | | mandatory implementation. | | | | |------------------------------------------------------------------------| | Section 3.1.3.1 | |------------------------------------------------------------------------| | The protocol MUST contain standard | YES | | | | schemas for the exchange of data | | | | | needed to implement the | | | | | functionality in this document. | | | | |------------------------------------+------+-----+----------------------| | there MUST be a means to allow the | YES | | | | use of schemas not defined by the | | | | | needs of this document. | | | | |------------------------------------+------+-----+----------------------| | Both types of schemas MUST use the | YES | | | | same schema language. | | | | |------------------------------------+------+-----+----------------------| | The schemas MUST be able to | YES | | | | express data elements with | | | | | identifying tags for the purpose | | | | | of localization of the meaning of | | | | | the identifying tags. | | | | |------------------------------------------------------------------------| | Section 3.1.4.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit an | | | [iris] needs | | operator from granularly assigning | | | additional | | multiple types of access to data | | | definition | | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.5 | |------------------------------------------------------------------------| | The protocol MUST be capable of | YES | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.6 | |------------------------------------------------------------------------| | The protocol MUST be capable of | YES | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.7.1 | |------------------------------------------------------------------------| | The protocol MUST NOT require the | YES | | | | aggregation of data to a central | | | | | repository, server, or entity. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT require | YES | | | | aggregation of data indexes or | | | | | hints to a central repository, | | | | | server, or entity. | | | | |------------------------------------------------------------------------| | Section 3.1.8.1 | |------------------------------------------------------------------------| | The protocol MUST provide a | NO | | | | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.9.1 | |------------------------------------------------------------------------| | The protocol MUST NOT require any | YES | | | | Internet registry to participate | | | | | in any authentication system. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT prohibit the | YES | | | | participation by an Internet | | | | | registry in federated, distributed | | | | | authentication systems. | | | | |------------------------------------------------------------------------| | Section 3.1.10 | |------------------------------------------------------------------------| | The protocol MUST be capable of returning the following types of | | non-result or error responses to all lookups and searches: | |------------------------------------------------------------------------| | permission denied - a response | YES | | | | indicating that the search or | | | | | lookup has failed due to | | | | | insufficient authorization. | | | | |------------------------------------+------+-----+----------------------| | not found - the desired results do | YES | | | | not exist. | | | | |------------------------------------+------+-----+----------------------| | insufficient resources - the | | | | | search or lookup requires | | | | | resources that cannot be | | | | | allocated. | | | | |------------------------------------------------------------------------| | Section 3.1.11.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit a | YES | | | | server from participating in a | | | | | query distribution system. | | | | |------------------------------------+------+-----+----------------------| | Section 3.1.12.1 | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST provide a means | YES | | | | 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 | YES | | | | provide a version identifier | | | | | attribute which uniquely and | | | | | unambiguously identifies the | | | | | version of the schema being | | | | | returned in the answer set to a | | | | | query. | | | | |------------------------------------------------------------------------| | Section 3.1.13.1 | |------------------------------------------------------------------------| | When issuing a referral, the | YES | | | | protocol MUST be capable of | | | | | supplying a relay bag from the | | | | | server to the client, | | | | |------------------------------------+------+-----+----------------------| | and the protocol MUST be capable | YES | | | | of allowing the client to submit | | | | | this relay bag with a query to the | | | | | referred server. | | | | |------------------------------------+------+-----+----------------------| | The use of the relay bag MUST be | YES | | | | OPTIONAL. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT make any | YES | | | | assumptions regarding the contents | | | | | of the relay bag, | | | | |------------------------------------+------+-----+----------------------| | but the relay bag MUST be | YES | | | | described using the schema | | | | | language of the protocol. | | | | |------------------------------------------------------------------------| | Section 3.2.1.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following lookup functions: | |------------------------------------------------------------------------| | Contact lookup given a unique | YES | | | | reference to a contact of a | | | | | resource. | | | | |------------------------------------+------+-----+----------------------| | Nameserver lookup given a | YES | | | | fully-qualified host name or IP | | | | | address of a nameserver. | | | | |------------------------------------+------+-----+----------------------| | Domain lookup given a | YES | | | | fully-qualified domain name. | | | | |------------------------------------------------------------------------| | Section 3.2.2.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following search functions: | |------------------------------------------------------------------------| | Domain name search given an exact match or reasonable subset of a | | name. | |------------------------------------------------------------------------| | This search SHOULD allow for | YES | | | | parameters and qualifiers designed | | | | | to allow better matching of | | | | | internationalized domain names | | | | |------------------------------------+------+-----+----------------------| | and SHOULD allow for both exact | YES | | | | and partial matching within the | | | | | limits of internationalized domain | | | | | names. | | | | |------------------------------------+------+-----+----------------------| | This search SHOULD NOT require | YES | | | | special transformations of | | | | | internationalized domain names to | | | | | accommodate this search. | | | | |------------------------------------+------+-----+----------------------| | This search MUST provide a means | YES | | | | to narrow the search by names | | | | | delegated under a particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domain registrant search by either | YES | | | | exact name or partial name match | | | | | with the ability to narrow the | | | | | search to registrants of a | | | | | particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domains hosted by a nameserver | YES | | | | given the fully-qualified host | | | | | name or IP address of a | | | | | nameserver. | | | | |------------------------------------------------------------------------| | Section 3.2.3.1 | |------------------------------------------------------------------------| | The data sets for contacts, | YES | | | | 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: | |------------------------------------------------------------------------| | activation status | YES | | | |------------------------------------+------+-----+----------------------| | registrant | YES | | | |------------------------------------+------+-----+----------------------| | nameservers | YES | | | |------------------------------------+------+-----+----------------------| | technical, billing or other | YES | | | | contacts | | | | |------------------------------------+------+-----+----------------------| | registry delegating the domain | YES | | | |------------------------------------+------+-----+----------------------| | registrar for the domain | YES | | | |------------------------------------+------+-----+----------------------| | The data set for domains MUST be | YES | | | | able to express arbitrary textual | | | | | information for extensions on an | | | | | individual operator basis. | | | | |------------------------------------------------------------------------| | Section 3.2.4 | |------------------------------------------------------------------------| | The schemas used by the protocol | YES | | | | SHOULD be capable of off-line | | | | | serialization. | | | | |------------------------------------------------------------------------| | Section 3.2.5.1 | |------------------------------------------------------------------------| | The protocol MUST contain a | YES | | | | 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: | |------------------------------------------------------------------------| | an empty result set. | YES | | | |------------------------------------+------+-----+----------------------| | a result set truncated for the | YES | | | | purpose of improving performance | | | | | bottlenecks. | | | | |------------------------------------+------+-----+----------------------| | a result set truncated to comply | YES | | | | with Section 3.1.1 | | | | |------------------------------------------------------------------------| | Section 3.2.6.1 | |------------------------------------------------------------------------| | The protocol MUST use the | YES | | | | 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. | | | | |------------------------------------------------------------------------| | Section 3.2.7.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit the | YES | | | | distribution of data to exclude | | | | | any of the registry/registrar | | | | | models stated in Section 2.1.1. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be capable of | YES | | | | expressing referrals and entity | | | | | references between the various | | | | | models described in Section 2.1.1. | | | | |------------------------------------------------------------------------| | Section 3.2.8.1 | |------------------------------------------------------------------------| | 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: | |------------------------------------------------------------------------| | complete omission of the value | YES | | | | without explanation | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | YES | | | | cannot be given due to | | | | | insufficient authorization | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | YES | | | | cannot be given due to privacy | | | | | constraints regardless of | | | | | authorization status | | | | |------------------------------------+------+-----+----------------------| | The protocol MAY define other | YES | | | | values for this purpose, but MUST | | | | | define values defined above at a | | | | | minimum. | | | | |------------------------------------------------------------------------| | Section 3.2.9 | |------------------------------------------------------------------------| | The schema defining domain related | YES | | | | resources MUST conform to RFC 2277 | | | | | [2] regarding textual data. | | | | |------------------------------------+------+-----+----------------------| | In particular, the schema MUST be | YES | | | | able to indicate the charset and | | | | | language in use with unstructured | | | | | textual data. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be able to | YES | | | | support multiple representations | | | | | of contact data, with these | | | | | representations complying with the | | | | | requirements in Section 3.2.3. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be able to | YES | | | | provide contact data in UTF-8 | | | | |------------------------------------+------+-----+----------------------| | and SHOULD be able to provide | YES | | | | contact data in | | | | | | | | | | US-ASCII, other character sets, | | | | |------------------------------------+------+-----+----------------------| | and capable of specifying the | YES | | | | language of the data. | | | | |------------------------------------------------------------------------| | Section 4.1 | |------------------------------------------------------------------------| | Entities accessing the service | YES | | | | (users) MUST be provided a | | | | | mechanism for passing credentials | | | | | to a server for the purpose of | | | | | authentication. | | | | |------------------------------------------------------------------------| | Section 4.2 | |------------------------------------------------------------------------| | The protocol MUST provide a | YES | | | | mechanism capable of employing | | | | | many authentication types and | | | | | capable of extension for future | | | | | authentication types. | | | | |------------------------------------------------------------------------| | Section 4.3 | |------------------------------------------------------------------------| | To distribute queries for search | YES | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | provide a referral mechanism. | | | | |------------------------------------------------------------------------| | Section 4.4 | |------------------------------------------------------------------------| | To distribute queries for search | YES | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | define a common referral scheme | | | | | and syntax. | | | | |------------------------------------+------+-----+----------------------| | Section 4.5 | | | | |------------------------------------+------+-----+----------------------| | To provide structured queries and | YES | | | | responses and allow for minimal | | | | | technological reinvention, the | | | | | protocol MUST employ a | | | | | pre-existing schema language. | | | | |------------------------------------+------+-----+----------------------| | Section 4.6 | | | | |------------------------------------+------+-----+----------------------| | To provide for machine consumption | YES | | | | as well as human consumption, the | | | | | protocol MUST define schemas for | | | | | use by the structured queries and | | | | | responses. | | | | +------------------------------------------------------------------------+ -------------- next part -------------- CRISP Technical Proposal Evaluation Matrix +------------------------------------------------------------------------+ | Requirement | IRIS | LW | Comment | |------------------------------------------------------------------------| | Sample | |------------------------------------------------------------------------| | The protocl MUST be capable of | NO | YES | IRIS only gives the | | walking and chewing gum at the | | | appearance of | | same time. | | | walking and chewing | | | | | gum simultaneously, | | | | | but it in fact | | | | | requires two | | | | | separate CPU clock | | | | | cycles. On the other | | | | | hand, LW does the | | | | | walking on the | | | | | rising edge of the | | | | | cycle and the gum | | | | | chewing on the | | | | | falling edge of the | | | | | cycle. | |------------------------------------------------------------------------| | Section 3.1.2 | |------------------------------------------------------------------------| | The protocol MUST NOT employ | YES | | | | 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 | YES | | | | of network and transport layer | | | | | standards as defined by the | | | | | Internet Engineering Task Force. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST define one or | | | [iris] needs | | more transport mechanisms for | | | additional text | | mandatory implementation. | | | | |------------------------------------------------------------------------| | Section 3.1.3.1 | |------------------------------------------------------------------------| | The protocol MUST contain standard | YES | | | | schemas for the exchange of data | | | | | needed to implement the | | | | | functionality in this document. | | | | |------------------------------------+------+-----+----------------------| | there MUST be a means to allow the | YES | | | | use of schemas not defined by the | | | | | needs of this document. | | | | |------------------------------------+------+-----+----------------------| | Both types of schemas MUST use the | YES | | | | same schema language. | | | | |------------------------------------+------+-----+----------------------| | The schemas MUST be able to | YES | | | | express data elements with | | | | | identifying tags for the purpose | | | | | of localization of the meaning of | | | | | the identifying tags. | | | | |------------------------------------------------------------------------| | Section 3.1.4.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit an | | | [iris] needs | | operator from granularly assigning | | | additional | | multiple types of access to data | | | definition | | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.5 | |------------------------------------------------------------------------| | The protocol MUST be capable of | YES | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.6 | |------------------------------------------------------------------------| | The protocol MUST be capable of | YES | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.7.1 | |------------------------------------------------------------------------| | The protocol MUST NOT require the | YES | | | | aggregation of data to a central | | | | | repository, server, or entity. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT require | YES | | | | aggregation of data indexes or | | | | | hints to a central repository, | | | | | server, or entity. | | | | |------------------------------------------------------------------------| | Section 3.1.8.1 | |------------------------------------------------------------------------| | The protocol MUST provide a | NO | | | | 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. | | | | |------------------------------------------------------------------------| | Section 3.1.9.1 | |------------------------------------------------------------------------| | The protocol MUST NOT require any | YES | | | | Internet registry to participate | | | | | in any authentication system. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT prohibit the | YES | | | | participation by an Internet | | | | | registry in federated, distributed | | | | | authentication systems. | | | | |------------------------------------------------------------------------| | Section 3.1.10 | |------------------------------------------------------------------------| | The protocol MUST be capable of returning the following types of | | non-result or error responses to all lookups and searches: | |------------------------------------------------------------------------| | permission denied - a response | YES | | | | indicating that the search or | | | | | lookup has failed due to | | | | | insufficient authorization. | | | | |------------------------------------+------+-----+----------------------| | not found - the desired results do | YES | | | | not exist. | | | | |------------------------------------+------+-----+----------------------| | insufficient resources - the | | | | | search or lookup requires | | | | | resources that cannot be | | | | | allocated. | | | | |------------------------------------------------------------------------| | Section 3.1.11.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit a | YES | | | | server from participating in a | | | | | query distribution system. | | | | |------------------------------------+------+-----+----------------------| | Section 3.1.12.1 | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST provide a means | YES | | | | 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 | YES | | | | provide a version identifier | | | | | attribute which uniquely and | | | | | unambiguously identifies the | | | | | version of the schema being | | | | | returned in the answer set to a | | | | | query. | | | | |------------------------------------------------------------------------| | Section 3.1.13.1 | |------------------------------------------------------------------------| | When issuing a referral, the | YES | | | | protocol MUST be capable of | | | | | supplying a relay bag from the | | | | | server to the client, | | | | |------------------------------------+------+-----+----------------------| | and the protocol MUST be capable | YES | | | | of allowing the client to submit | | | | | this relay bag with a query to the | | | | | referred server. | | | | |------------------------------------+------+-----+----------------------| | The use of the relay bag MUST be | YES | | | | OPTIONAL. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT make any | YES | | | | assumptions regarding the contents | | | | | of the relay bag, | | | | |------------------------------------+------+-----+----------------------| | but the relay bag MUST be | YES | | | | described using the schema | | | | | language of the protocol. | | | | |------------------------------------------------------------------------| | Section 3.2.1.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following lookup functions: | |------------------------------------------------------------------------| | Contact lookup given a unique | YES | | | | reference to a contact of a | | | | | resource. | | | | |------------------------------------+------+-----+----------------------| | Nameserver lookup given a | YES | | | | fully-qualified host name or IP | | | | | address of a nameserver. | | | | |------------------------------------+------+-----+----------------------| | Domain lookup given a | YES | | | | fully-qualified domain name. | | | | |------------------------------------------------------------------------| | Section 3.2.2.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following search functions: | |------------------------------------------------------------------------| | Domain name search given an exact match or reasonable subset of a | | name. | |------------------------------------------------------------------------| | This search SHOULD allow for | YES | | | | parameters and qualifiers designed | | | | | to allow better matching of | | | | | internationalized domain names | | | | |------------------------------------+------+-----+----------------------| | and SHOULD allow for both exact | YES | | | | and partial matching within the | | | | | limits of internationalized domain | | | | | names. | | | | |------------------------------------+------+-----+----------------------| | This search SHOULD NOT require | YES | | | | special transformations of | | | | | internationalized domain names to | | | | | accommodate this search. | | | | |------------------------------------+------+-----+----------------------| | This search MUST provide a means | YES | | | | to narrow the search by names | | | | | delegated under a particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domain registrant search by either | YES | | | | exact name or partial name match | | | | | with the ability to narrow the | | | | | search to registrants of a | | | | | particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domains hosted by a nameserver | YES | | | | given the fully-qualified host | | | | | name or IP address of a | | | | | nameserver. | | | | |------------------------------------------------------------------------| | Section 3.2.3.1 | |------------------------------------------------------------------------| | The data sets for contacts, | YES | | | | 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: | |------------------------------------------------------------------------| | activation status | YES | | | |------------------------------------+------+-----+----------------------| | registrant | YES | | | |------------------------------------+------+-----+----------------------| | nameservers | YES | | | |------------------------------------+------+-----+----------------------| | technical, billing or other | YES | | | | contacts | | | | |------------------------------------+------+-----+----------------------| | registry delegating the domain | YES | | | |------------------------------------+------+-----+----------------------| | registrar for the domain | YES | | | |------------------------------------+------+-----+----------------------| | The data set for domains MUST be | YES | | | | able to express arbitrary textual | | | | | information for extensions on an | | | | | individual operator basis. | | | | |------------------------------------------------------------------------| | Section 3.2.4 | |------------------------------------------------------------------------| | The schemas used by the protocol | YES | | | | SHOULD be capable of off-line | | | | | serialization. | | | | |------------------------------------------------------------------------| | Section 3.2.5.1 | |------------------------------------------------------------------------| | The protocol MUST contain a | YES | | | | 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: | |------------------------------------------------------------------------| | an empty result set. | YES | | | |------------------------------------+------+-----+----------------------| | a result set truncated for the | YES | | | | purpose of improving performance | | | | | bottlenecks. | | | | |------------------------------------+------+-----+----------------------| | a result set truncated to comply | YES | | | | with Section 3.1.1 | | | | |------------------------------------------------------------------------| | Section 3.2.6.1 | |------------------------------------------------------------------------| | The protocol MUST use the | YES | | | | 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. | | | | |------------------------------------------------------------------------| | Section 3.2.7.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit the | YES | | | | distribution of data to exclude | | | | | any of the registry/registrar | | | | | models stated in Section 2.1.1. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be capable of | YES | | | | expressing referrals and entity | | | | | references between the various | | | | | models described in Section 2.1.1. | | | | |------------------------------------------------------------------------| | Section 3.2.8.1 | |------------------------------------------------------------------------| | 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: | |------------------------------------------------------------------------| | complete omission of the value | YES | | | | without explanation | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | YES | | | | cannot be given due to | | | | | insufficient authorization | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | YES | | | | cannot be given due to privacy | | | | | constraints regardless of | | | | | authorization status | | | | |------------------------------------+------+-----+----------------------| | The protocol MAY define other | YES | | | | values for this purpose, but MUST | | | | | define values defined above at a | | | | | minimum. | | | | |------------------------------------------------------------------------| | Section 3.2.9 | |------------------------------------------------------------------------| | The schema defining domain related | YES | | | | resources MUST conform to RFC 2277 | | | | | [2] regarding textual data. | | | | |------------------------------------+------+-----+----------------------| | In particular, the schema MUST be | YES | | | | able to indicate the charset and | | | | | language in use with unstructured | | | | | textual data. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be able to | YES | | | | support multiple representations | | | | | of contact data, with these | | | | | representations complying with the | | | | | requirements in Section 3.2.3. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be able to | YES | | | | provide contact data in UTF-8 | | | | |------------------------------------+------+-----+----------------------| | and SHOULD be able to provide | YES | | | | contact data in | | | | | | | | | | US-ASCII, other character sets, | | | | |------------------------------------+------+-----+----------------------| | and capable of specifying the | YES | | | | language of the data. | | | | |------------------------------------------------------------------------| | Section 4.1 | |------------------------------------------------------------------------| | Entities accessing the service | YES | | | | (users) MUST be provided a | | | | | mechanism for passing credentials | | | | | to a server for the purpose of | | | | | authentication. | | | | |------------------------------------------------------------------------| | Section 4.2 | |------------------------------------------------------------------------| | The protocol MUST provide a | YES | | | | mechanism capable of employing | | | | | many authentication types and | | | | | capable of extension for future | | | | | authentication types. | | | | |------------------------------------------------------------------------| | Section 4.3 | |------------------------------------------------------------------------| | To distribute queries for search | YES | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | provide a referral mechanism. | | | | |------------------------------------------------------------------------| | Section 4.4 | |------------------------------------------------------------------------| | To distribute queries for search | YES | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | define a common referral scheme | | | | | and syntax. | | | | |------------------------------------+------+-----+----------------------| | Section 4.5 | | | | |------------------------------------+------+-----+----------------------| | To provide structured queries and | YES | | | | responses and allow for minimal | | | | | technological reinvention, the | | | | | protocol MUST employ a | | | | | pre-existing schema language. | | | | |------------------------------------+------+-----+----------------------| | Section 4.6 | | | | |------------------------------------+------+-----+----------------------| | To provide for machine consumption | YES | | | | as well as human consumption, the | | | | | protocol MUST define schemas for | | | | | use by the structured queries and | | | | | responses. | | | | +------------------------------------------------------------------------+ From Internet-Drafts at ietf.org Wed Jul 2 17:14:56 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Jul 2 16:15:02 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-dreg-03.txt Message-ID: <200307022014.QAA10902@ietf.org> 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 : IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-dreg-03.txt Pages : 55 Date : 2003-7-2 This document describes an IRIS (draft-ietf-crisp-iris-core-00.txt ) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-dreg-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-iris-dreg-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-iris-dreg-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Jul 2 17:15:00 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Jul 2 16:15:09 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-areg-03.txt Message-ID: <200307022015.QAA10924@ietf.org> 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 : IRIS - An Address Registry (areg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-areg-03.txt Pages : 41 Date : 2003-7-2 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for IP address information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-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-iris-areg-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-iris-areg-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Jul 2 17:15:04 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Jul 2 16:15:15 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-core-03.txt Message-ID: <200307022015.QAA10942@ietf.org> 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 : IRIS - The Internet Registry Information Service (IRIS) Core Protocol Author(s) : A. Newton Filename : draft-ietf-crisp-iris-core-03.txt Pages : 58 Date : 2003-7-2 This document describes an application layer client-server protocol for a framework of representing the query and result operations of the information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-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-iris-core-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-iris-core-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Jul 2 17:15:09 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Jul 2 16:15:21 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-beep-03.txt Message-ID: <200307022015.QAA10959@ietf.org> 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 : IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) Author(s) : A. Newton Filename : draft-ietf-crisp-iris-beep-03.txt Pages : 19 Date : 2003-7-2 This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS) as described draft-ietf-crisp-iris-core-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-beep-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-iris-beep-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-iris-beep-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. -------------- next part -------------- Skipped content of type multipart/alternative From anewton at ecotroph.net Thu Jul 3 12:27:47 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Jul 3 11:06:45 2003 Subject: [Ietf-not43] IRIS requirements compliance Message-ID: <3F044B73.8050205@ecotroph.net> Scott, et al, I have submitted new drafts (-03) that should meet the compliance issues noted earlier. 1) Item #3: Transport Mapping draft-ietf-crisp-iris-beep-03.txt section 7.3 now addresses this issue. 2) Item #10: Anonymous Access draft-ietf-crisp-iris-beep-03.txt section 12 now has appended text to make this clearer. 3) Item #15: Query Permission Determination draft-ietf-crisp-iris-core-03.txt section 3.3.7 gives IRIS this capability. -andy From shollenbeck at verisign.com Mon Jul 7 09:38:32 2003 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Mon Jul 7 08:38:41 2003 Subject: [Ietf-not43] IRIS requirements compliance Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF82B4AB@vsvapostal8.vasrv.verisign.com> > I have submitted new drafts (-03) that should meet the > compliance issues > noted earlier. > > 1) Item #3: Transport Mapping > draft-ietf-crisp-iris-beep-03.txt section 7.3 now addresses > this issue. > > 2) Item #10: Anonymous Access > draft-ietf-crisp-iris-beep-03.txt section 12 now has appended text to > make this clearer. > > 3) Item #15: Query Permission Determination > draft-ietf-crisp-iris-core-03.txt section 3.3.7 gives IRIS > this capability. With these edits I believe IRIS meets all of the requirements described in the current requirements draft. -Scott- From Peter.Gietz at daasi.de Tue Jul 8 21:07:37 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Tue Jul 8 15:00:36 2003 Subject: [Ietf-not43] matrix in text In-Reply-To: References: Message-ID: <3F0B0869.80502@daasi.de> Hi, Please find the Evaluation Matrix filled out for FIRS. I hope to have gotten everything right, although it was not easy to differentiate between the possibilities of LDAP and the specifications of the firs documents. May be in some cases, e.g., in the use of the LDAP error codes, the firs documents should more precicely specify these errors to even better match the requirements. Another problem was to differentiate between LDAPv3 standard and LDAPv3 implementations, since some vital parts like access control and replication are still not standardized, but provided by the implementations (where my main focus is on OpenLDAP). Just to make sure that I didn't include own misconceptions I am Ccing this to Kurt, who may want to comment. Since the time untill Vienna is so short I didn't first communicate with him (sorry Kurt). I found a few bugs in the matrix in relation to the -05 requirements draft, which I corrected. These amendmends, that occure in sections 3.1.6. and in 4.1-4.4 are marked by underlined text. As you can see, I see FIRS as complying to the requirements with one exception: - Section 3.1.13.1 Relay bags are not directly supported in the current FIRS documents, which only hint to the possibility of specifying an LDAP extension for this feature. I agree that such is possible via defining an LDAP control that defines additional data to be sent. Such could be specified in a way to fulfill all respective requirements. I for one am voluntering to co-author a document that specifies such a controll, if Eric needs help in this. I don't want to miss the situtaion to congratulate Eric for his very thoughtfull and comprehensive suite of documents. I only found some minor typos etc. which I will communicate to Eric directly. If wanted, I could prepare a short presentation about this evaluation at thee meeting in Vienna. Cheers, Peter - Rick Wesson wrote: > and thanks to andy here is the matrix in text... the html version > is available at http://wesson.us/crisp-matrix.html > > please refer to the section when suggesting a fix. > > -rick > > [...] > +------------------------------------------------------------------------+ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20030708/c558987b/crisp-matrix-LDAP-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: crisp-matrix-LDAP.sxw Type: application/vnd.sun.xml.writer Size: 12394 bytes Desc: not available Url : http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20030708/c558987b/crisp-matrix-LDAP-0001.bin From ehall at ehsco.com Tue Jul 8 15:51:27 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Jul 8 15:51:34 2003 Subject: [Ietf-not43] matrix in text In-Reply-To: <3F0B0869.80502@daasi.de> References: <3F0B0869.80502@daasi.de> Message-ID: <3F0B20BF.9000904@ehsco.com> Thanks for doing this Peter on 7/8/2003 1:07 PM Peter Gietz wrote: > Please find the Evaluation Matrix filled out for FIRS. I hope to have > gotten everything right, although it was not easy to differentiate > between the possibilities of LDAP and the specifications of the firs > documents. May be in some cases, e.g., in the use of the LDAP error > codes, the firs documents should more precicely specify these errors to > even better match the requirements. I considered that but decided it was duplication of the core specs which was unnecessary and risky. I'll gladly add these if the group asks tho. > - Section 3.1.13.1 > Relay bags are not directly supported in the current FIRS documents, > which only hint to the possibility of specifying an LDAP extension for > this feature. I agree that such is possible via defining an LDAP control > that defines additional data to be sent. Such could be specified in a > way to fulfill all respective requirements. I for one am voluntering to > co-author a document that specifies such a controll, if Eric needs help > in this. You can be the sole author when the time comes. :P -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Wed Jul 16 10:43:27 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Jul 16 09:43:37 2003 Subject: [Ietf-not43] requirement for IESG privacy discussion item Message-ID: <3F15567F.6020608@ecotroph.net> As mentioned in the meeting, here is the wording: 3.1.X.1 Protocol Requirement When a value in an answer to a query is given, the protocol MUST be capable of tagging the value with the following labels: 1. do not redistribute 2. special access granted The protocol MAY define other values for this purpose, but MUST define values defined above at a minimum. The protocol MUST be capable of attaching these labels concurrently. 3.1.X.2 Service Description Internet registries will have varying policies regarding the access to their data. Some registries may grant certain classes of users with access to data that would not normally be given to most users. In these cases, registries may want to tag the values in these entries with labels specifying the responsibilities accompanying these special user rights. -andy From edlewis at arin.net Thu Jul 17 16:07:15 2003 From: edlewis at arin.net (Edward Lewis) Date: Thu Jul 17 09:07:16 2003 Subject: [Ietf-not43] extensibility Message-ID: I had a dramatically worded intro to this, but, I decided to spare y'all the theater and cut to the chase... The current specification of FIRS and IRIS are cut to meet the "problems" seen by Domain registries. It's conceivable that other kinds of registries might want to be accommodated in the CRISP protocol. By other kinds I mean Address registries and Routing registries. One observation I've been refining is that when you look at Domain registries, DNS is the most important protocol. In the Address registry realm, routing is the most important protocol. For Domains, routing, and for Address, DNS, are "optional" protocols. DNS has a natural hierarchy, routing doesn't. This difference make me question the FIRS definition of its name space as a basic tenet of that approach. The message subject is "extensibility." I chose that because I was thinking that the more extensible of IRIS and FIRS would be more promising. Sure both LDAP and XML are expressive representations, but there is more to extensibility - like, what if the range of use of the protocol is extended? That's behind my comment in the previous paragraph. PS - I haven't had time to really think though how this plays for Routing registries. If anyone can contribute thoughts on this, I'd appreciate it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From Michael.Dillon at radianz.com Thu Jul 17 15:32:09 2003 From: Michael.Dillon at radianz.com (Michael.Dillon@radianz.com) Date: Thu Jul 17 09:32:54 2003 Subject: [Ietf-not43] extensibility Message-ID: >One observation I've been refining is that when you look at Domain >registries, DNS is the most important protocol. In the Address >registry realm, routing is the most important protocol. For Domains, >routing, and for Address, DNS, are "optional" protocols. Seemingly symmetrical but not really. The relationship between DNS (Domain Name System) and Domain Name Registries is inherent. But The relationship between routing and address registries is not. The address registries are not involved in routing and routing can be done and is being done without involving address registries. >DNS has a natural hierarchy, routing doesn't. This difference make >me question the FIRS definition of its name space as a basic tenet of >that approach. IP Addressing has a natural hierarchy too, namely the allocation hierarchy. The entire IP address space (either IPv4 or IPv6) is cut up into large address ranges (begin,end pairs). These ranges are delegated to various authorities who then cut them up into smaller ranges. These smaller ranges are delegated to network operators and large companies. In turn they cut up their ranges into smaller ranges. Some, but not all, of these ranges end up as route table entries. Some of them end up as entries in an ACL (Access Control List) or in various other types of tables (NAT pools) in various types of network devices. Frequently, the begin and end pair that marks out a range also corresponds to a bit boundary in the binary form of the address. But not always. For eaxmple, my company has many address ranges registered with ARIN, and two of them are not proper CIDR blocks. Try a whois search on NET-65-62-0-0-1 or NET-192-199-128-0-1 at http://www.arin.net to see what I mean. So there is hierarchy, but it is found in the allocation hierarchy where ranges are split into several smaller ranges, and it is also found in the delegation hierarchy, where ranges are delegated to another organization who is then responsible for sub-allocating and perhaps sub-delegating. Not all allocations are necessarily delegated, i.e. it is possible to split a range into smaller ranges for use within a single organization. There are analogies to the DNS here. The .com domain can delegate example.com to another organization. That organization can allocate warehouse.example.com for its own use and it can delegate kids.example.com to another organization. If you don't believe me about the "kids" example, then look at what these folks http://www.centralnic.com/ are doing with uk.com, de.com, ru.com etc. >PS - I haven't had time to really think though how this plays for >Routing registries. If anyone can contribute thoughts on this, I'd >appreciate it. It's worth mentioning, for those who may not be familiar with the ISP business, that there are things called routing registries which are entirely separate from address registries. These routing registries allow a network operator to publish details on the BGP announcements that they might make. Because IP routing is a dynamic activity that is intended to represent the true state of the network topology, it is entirely possible for a network to announce different sets of routes at different times, for instance when a circuit goes down. The routing registry, allows a recipient of route announcements to validate any particular announcement with the intention of protecting the routing system against flaws in routing software, human error, or malicious interference with route announcements. There are routing registries operated by several address registries, some non-profit organizations and some network operators. None of them are complete and many network operators don't use any route registry at all. That may be due partially to the fact that the route registries use poorly documented software that was only created for this one arcane purpose and therefore few people know anything about it other than the frontline network engineers working for network operators. Something standard like LDAP or XML could help here. --Michael Dillon From richard at shockey.us Thu Jul 17 10:58:30 2003 From: richard at shockey.us (Richard Shockey) Date: Thu Jul 17 09:57:26 2003 Subject: [Ietf-not43] extensibility In-Reply-To: Message-ID: <5.2.0.9.2.20030717093955.0505b770@shockey.us> At 03:07 PM 7/17/2003 +0200, Edward Lewis wrote: >I had a dramatically worded intro to this, but, I decided to spare y'all >the theater and cut to the chase... > >The current specification of FIRS and IRIS are cut to meet the "problems" >seen by Domain registries. It's conceivable that other kinds of >registries might want to be accommodated in the CRISP protocol. By other >kinds I mean Address registries and Routing registries. We're looking at this in ENUM as well ... >The message subject is "extensibility." I chose that because I was >thinking that the more extensible of IRIS and FIRS would be more >promising. Sure both LDAP and XML are expressive representations, but >there is more to extensibility - like, what if the range of use of the >protocol is extended? That's behind my comment in the previous paragraph. > >PS - I haven't had time to really think though how this plays for Routing >registries. If anyone can contribute thoughts on this, I'd appreciate it. I'm reasonably convinced of the extensibility arguments since it seems quite clear that the transport of XML objects for the purposes of look up, provisioning or commerce are well established in all sorts of protocols . Beyond that I'm pro IRIS since we now have in the domain/RIR space EPP. Developed in PROVREG it follows the same basic protocol logic we have in IRIS ( move the XML blobs please). IRIS specifies BEEP/TCP but it could easily be adapted to other transport layers etc ( yea SOAP) and I , for one, would like to maintain a consistent business infrastructure. In fact _some of you_ might remember NeuStar supported EPP over BEEP/TCP. Well that argument was lost ..but its still possible if the demand was there and that IMHO is the very definition of extensibility. What I think people were thinking but could not express yesterday is that the real issue is not the applicability of one protocol or another to satisfy the requirements, lets face it both IRIS and FIRS will work ..its that there are serious business issues here. And irrespective of the technical religious views of IRIS vs FIRS , the logical business choice, from my perspective , is IRIS. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From ehall at ehsco.com Thu Jul 17 10:37:42 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Jul 17 10:37:48 2003 Subject: [Ietf-not43] jabber log Message-ID: <3F16B4B6.8060404@ehsco.com> For the folks who weren't there, there is a jabber log of the meeting at http://ietf.jabber.at/logs/crisp@ietf.jabber.at/2003-07-16.html Thanks very much George for transcribing this. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Thu Jul 17 11:13:52 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Jul 17 11:14:00 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: Message-ID: <3F16BD30.8010901@ehsco.com> on 7/17/2003 8:07 AM Edward Lewis wrote: > DNS has a natural hierarchy, routing doesn't. This difference make > me question the FIRS definition of its name space as a basic tenet of > that approach. I think you're looking at too high of a layer. That all of the proposed resource-types use DNS is a coincidence of convenience at lower layers, and is not a universal technical requirement. The WG expended a fair amount of effort on this subject a while back. The basic truth is that the WG has shunned building its own delegation system, and that existing delegation systems have to be reused where they are available, and that new delegations have to be created in the external systems where they do not exist. Specifically, the value of using an external existing delegation system is that the registered operator of the resource will be able to control where queries for their resource are directed, while the value of avoiding duplicate delegation systems is that this information doesn't have to be maintained twice, that ownership integrity checks don't have to be managed twice, and so forth. Any existing external delegation system can be used for this, but as a practical matter, there is only one delegation system which satisfies these concerns, which is DNS. In particular, things like common-syntax URIs are only going to work with DNS, common-syntax service lookup (via SRV) is only going to work with DNS, and so forth. Without checking, I think the requirements still allow other delegation systems, but in the end I am pretty sure that you'll come to the same conclusion. FWIW, both IRIS and FIRS should be able to use whatever delegation system you choose. The existing proposals use DNS as a practical result of the practical considerations described above, but if there is some other locator technology that you would prefer and which is available to clients, then both systems are malleable and can probably use it. The FIRS namespace is more visible and thus more transparent in its linkage, but both technologies have the same basic dependancies, BTW. > PS - I haven't had time to really think though how this plays for > Routing registries. If anyone can contribute thoughts on this, I'd > appreciate it. You need to separate the concept of resources and service-providers. If you want information about a global resource, ask the global (default) namespace for information about that particular resource. If you want to query a specific provider for information (including information about a resource they manage), then you need to query for that provider. There are multiple routing registries; there would in theory also be multiple registry client applications, or a single client that is capable of querying the multiple unique registries. Essentially, the FIRS model would allow the client to construct the locator queries according to the needs of each registry, but (in its existing form) would use DNS to locate the servers for each of those registries. EG, an IRR could establish a service under my-irr.net, and the client application would have to know this, and would have to know to use queries for the dc=my-irr,dc=net partition, rather than using the generic namespace. All of that is separate from trying to find generic global delegation information about a particular resource, such as a netblock or an ASN. The global information for those global resources would still need to be served through the global delegation system, which is currently DNS (see the discussion at the top), meaning queries for in-addr.arpa or asn.arpa in this case. IRIS and FIRS are both heavily virtualized and are capable of handling a significant range of usage scenarios, including different global resource types, private service providers (using private partitions instead of the default namespace), and alternative delegation mechanisms. These heavily virtualized approaches can be difficult to get your head around. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Thu Jul 17 11:22:47 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Jul 17 11:22:53 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <5.2.0.9.2.20030717093955.0505b770@shockey.us> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> Message-ID: <3F16BF47.3010301@ehsco.com> on 7/17/2003 8:58 AM Richard Shockey wrote: > What I think people were thinking but could not express yesterday is > that the real issue is not the applicability of one protocol or another > to satisfy the requirements, lets face it both IRIS and FIRS will work > ..its that there are serious business issues here. > > And irrespective of the technical religious views of IRIS vs FIRS , the > logical business choice, from my perspective , is IRIS. I agree that operational convenience and potential (albeit probably somewhat minor) cost savings through reuse are important factors, but they aren't going to be the most important aspects for the Internet community as a whole. We really don't want to make decisions based on the desires of the operator community in particular. Otherwise, we'd just stick with WHOIS since doing nothing is the cheapest and easiest by far. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Fri Jul 18 08:48:08 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 18 08:48:15 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: Message-ID: <3F17EC88.4070600@ehsco.com> on 7/17/2003 8:07 AM Edward Lewis wrote: > PS - I haven't had time to really think though how this plays for > Routing registries. If anyone can contribute thoughts on this, I'd > appreciate it. I thought up a good analogy this morning -- the use of multiple IRR servers with [crisp] is very similar to the use of blacklists in DNS, where each blacklist essentially acts as an application-specific private partition, with the clients of those private applications using those private partitions (where 'using' means knowing about their existence and sending queries to those servers, versus using the public delegation hierarchy). IRR servers (and other application-specific uses) would probably operate in the same basic way in [crisp], with clients being aware of the partition they need to use (the dc= hierarchy, in LDAP) and also having to know which data-types to request, how the query should be formed, and so forth. We should also expect (and hope) that there would be lots more variations on this theme, since we would not be limited to [name|type|class] queries like DNS. Some applications will want to create their own partitions, but others could reuse the public namespace and simply layer on their own objectclass definitions at the public leaf nodes, too. Hopefully that's clearer. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From edlewis at arin.net Wed Jul 23 17:34:12 2003 From: edlewis at arin.net (Edward Lewis) Date: Wed Jul 23 16:33:51 2003 Subject: [Ietf-not43] an exercise in using the archives Message-ID: I'm still mystified by 3.1.8.1. in the requirements. So I decided to try to read the archives on this. I found that at one time 3.1.8.1 was !3.1.8.1 - requiring that the protocol not do this, fearing that someone might abuse the feature. The frustrating thing is that the only way I could find anything was to use the full archives as a flat file and search for a string. "denied before" seemed like a good choice and it picked up some instances - like RWR's comments on this. What's missing are the rationale of why !3.1.8.1 was there in the first place, and then how it was flipped to 3.1.8.1. If there's a fear that clients might get charged for asking a question and you want to make sure the protocol guarantees a fee-free means for finding out what it costs to ask a question - then shouldn't that be the requirement? Ie., there MUST be a fee-free means to ask how much a transaction would cost, whether asked anonymously or authenticated as a server-known client? If there is a discussion I haven't found that I should read, I'd appreciate a pointer - or if anyone has any phrases that might key word it... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From anewton at ecotroph.net Wed Jul 23 19:16:49 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Jul 23 17:53:13 2003 Subject: [Ietf-not43] an exercise in using the archives In-Reply-To: References: Message-ID: <3F1F0951.2080702@ecotroph.net> Edward Lewis wrote: > > What's missing are the rationale of why !3.1.8.1 was there in the first > place, and then how it was flipped to 3.1.8.1. It was probably in the -00 version based on feedback from the various forums listed in the back of the document (pre-wg input). The minutes from Yokahama show rejection of it (as my memory serves, mostly from one individual since not seen on the list nor in meetings). However, based on mailing list comments that this should be a "policy" decision, repurposed text was proposed without dissent. I think it is worth noting that this is a "protocol requirement". If particular operators find this feature to be useless or worse, they may turn it off. As suggested in 3.1.8.2: > 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. -andy From shane at ripe.net Thu Jul 24 11:48:28 2003 From: shane at ripe.net (Shane Kerr) Date: Thu Jul 24 04:48:35 2003 Subject: [Ietf-not43] an exercise in using the archives In-Reply-To: References: Message-ID: <3F1F9D5C.10800@ripe.net> Edward Lewis wrote: > I'm still mystified by 3.1.8.1. in the requirements. So I decided to > try to read the archives on this. > If there is a discussion I haven't found that I should read, I'd > appreciate a pointer - or if anyone has any phrases that might key word > it... While I don't have that, I did think of a potential use for this feature (while I was explaining how pointless it was to someone, no less). :) Assume you have a nice clicky-gui CRISP client, and it comes pre-configured with a set of servers. When it starts, it could issue a "can I query" to each server, and present either only a list of available servers, or grey-out the unavailable servers. This allows the user to send queries to a server that will accept it. True, it's not strictly necessary, but it can make for a nicer end-user experience. -- Shane Kerr RIPE NCC From Internet-Drafts at ietf.org Fri Jul 25 16:26:00 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:08 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-asn-02.txt Message-ID: <200307251926.PAA17229@ietf.org> 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 : Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-asn-02.txt Pages : 12 Date : 2003-7-25 This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-asn-02.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-firs-asn-02.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-firs-asn-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:04 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:14 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-contact-02.txt Message-ID: <200307251926.PAA17246@ietf.org> 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 : Defining and Locating Contact Information in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-contact-02.txt Pages : 12 Date : 2003-7-25 This document defines LDAP schema and searching rules for contact persons, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-contact-02.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-firs-contact-02.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-firs-contact-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:09 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:21 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dns-02.txt Message-ID: <200307251926.PAA17266@ietf.org> 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 : Defining and Locating DNS Domains in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dns-02.txt Pages : 16 Date : 2003-7-25 This document defines LDAP schema and searching rules for DNS domain names, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dns-02.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-firs-dns-02.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-firs-dns-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:13 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:28 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dnsrr-02.txt Message-ID: <200307251926.PAA17282@ietf.org> 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 : Defining and Locating DNS Resource Records in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dnsrr-02.txt Pages : 9 Date : 2003-7-25 This document defines LDAP schema and searching rules for DNS resource records, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dnsrr-02.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-firs-dnsrr-02.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-firs-dnsrr-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:20 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:36 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv4-02.txt Message-ID: <200307251926.PAA17299@ietf.org> 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 : Defining and Locating IPv4 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv4-02.txt Pages : 15 Date : 2003-7-25 This document defines LDAP schema and searching rules for IPv4 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv4-02.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-firs-ipv4-02.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-firs-ipv4-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:27 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:41 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv6-02.txt Message-ID: <200307251926.PAA17315@ietf.org> 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 : Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv6-02.txt Pages : 15 Date : 2003-7-25 This document defines LDAP schema and searching rules for IPv6 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv6-02.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-firs-ipv6-02.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-firs-ipv6-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:32 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:49 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-core-02.txt Message-ID: <200307251926.PAA17351@ietf.org> 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 : The Federated Internet Registry Service: Core Elements Author(s) : E. Hall Filename : draft-ietf-crisp-firs-core-02.txt Pages : 41 Date : 2003-7-25 This document describes the core technical elements of the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-02.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-firs-core-02.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-firs-core-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Fri Jul 25 16:26:37 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Jul 25 15:26:54 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-arch-02.txt Message-ID: <200307251926.PAA17418@ietf.org> 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 : The Federated Internet Registry Service:Architecture and Implementation Guide Author(s) : E. Hall Filename : draft-ietf-crisp-firs-arch-02.txt Pages : 31 Date : 2003-7-25 This document describes the architectural framework for the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-arch-02.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-firs-arch-02.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-firs-arch-02.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. -------------- next part -------------- Skipped content of type multipart/alternative From edlewis at arin.net Fri Jul 25 17:01:54 2003 From: edlewis at arin.net (Edward Lewis) Date: Fri Jul 25 16:01:54 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: Message-ID: At 14:32 +0100 7/17/03, Michael.Dillon@radianz.com wrote: >>One observation I've been refining is that when you look at Domain >>registries, DNS is the most important protocol. In the Address >>registry realm, routing is the most important protocol. For Domains, >>routing, and for Address, DNS, are "optional" protocols. > >Seemingly symmetrical but not really. The relationship between DNS >(Domain Name System) and Domain Name Registries is inherent. But >The relationship between routing and address registries is not. The >address registries are not involved in routing and routing can be done >and is being done without involving address registries. My point wasn't clear enough evidently. It's not that domain name registries are involved in DNS and that address registries are not, it's that the usefulness of what's being registered in each case depends on different protocols. Domain names are meaningful if they are in DNS, addresses are meaningful if they are in route tables. Meaningful to the general Internet community, that is. >IP Addressing has a natural hierarchy too, namely the allocation >hierarchy. That's an artifact of how the space is divided up, not how it has to be used. Waxing theoretic for a moment, a domain name isn't an identifier so much as a path - a path through a database. A domain name's labels direct the seeker to the location in the space where the desired data is. On the other hand, an IP address is an address, just a location. The difference is that a domain name tells you how to get to it no matter your starting point (step 1, go to the root, step 2, go to the TLD, ...). An IP address only tells you where you want to end up, it's up to you to know how to get from where you are to that point. It's up to the routing tables to direct you - and you're view of them is specific to your location, not the desired address. >So there is hierarchy, but it is found in the allocation hierarchy where >ranges are split into several smaller ranges, Perhaps there is a point here - that we are talking about locating the registry who would have the information. In this case it isn't the address-aspect of the IP address that is important but finding an authority to speak to its allocation/assignment. But: What has raised my hackles is the thought that "reversing the flow" (I mean finding the 'not whois' data for something from the bottom up) is not the same between domain names and IP addresses. Given a domain name, since the name is actually a path, I can see it's registration heritage. I.e., placing SRV records at a specific location relative to the domain name is a pretty reasonable convention for finding where the right authority of registration information might lie. This isn't so true with IP address ranges. A limitation of DNS gives us essentially a choice of /16 and /24 sized zones, with the RFC 2137 process to help a bit in un-CIDRizing this, meaning that for an arbitrary range, it's not so clear cut where to put the SRV-like pointers. (They may need to be replicated 127 times for a /17.) That, and, because there's some question as to the value of the reverse map, esp. in IPv6, there's no guarantee that there is even a place to put the SRV-like things. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From davidb at verisignlabs.com Fri Jul 25 17:41:25 2003 From: davidb at verisignlabs.com (David Blacka) Date: Fri Jul 25 16:44:18 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: Message-ID: <200307251641.25626.davidb@verisignlabs.com> On Friday 25 July 2003 04:01 pm, Edward Lewis wrote: > What has raised my hackles is the thought that "reversing the flow" > (I mean finding the 'not whois' data for something from the bottom > up) is not the same between domain names and IP addresses. > > Given a domain name, since the name is actually a path, I can see > it's registration heritage. I.e., placing SRV records at a specific > location relative to the domain name is a pretty reasonable > convention for finding where the right authority of registration > information might lie. > > This isn't so true with IP address ranges. A limitation of DNS gives > us essentially a choice of /16 and /24 sized zones, with the RFC 2137 > process to help a bit in un-CIDRizing this, meaning that for an > arbitrary range, it's not so clear cut where to put the SRV-like > pointers. (They may need to be replicated 127 times for a /17.) > That, and, because there's some question as to the value of the > reverse map, esp. in IPv6, there's no guarantee that there is even a > place to put the SRV-like things. Let me try to restate this: you are saying that because address allocation information, unlike domain allocation information, does not need DNS to function, and so the reverse tree is broken, clumsy or nonexistent. Thus, using the reverse tree to find CRISP servers is problematic. Did I get that right? Assuming I did, and it seems like a reasonable conclusion to me, do you have a better suggestion? do you think that all address searches should start from the top (i.e., just don't do SRV lookups)? -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Fri Jul 25 16:46:07 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 25 16:46:17 2003 Subject: [Ietf-not43] FIRS demonstration Message-ID: <3F21970E.7050704@ehsco.com> I've scratched up a very rough v0.01 FIRS demonstration system which illustrates how it can work (not necessarily how it will work). This includes a text-based Perl client and an LDAP database, both of which are running on the test system. To use the system, point a line-mode client (eg, WHOIS) to goose.ehsco.com port 43 and give it the resource name of "example.com". The resulting entries will return other domain names, IP addresses, etc as attribute values, and any of those can also be queried (take a look at ex?mple.com to see how internationalization is handled, for example). There are less than 10 resources stored in the system, so don't expect too much. You can give it the command-line switch of "--help" for info. There is an undocumented switch of "--source" which will return the perl source code. There are a lot of limitations to what I could build in a week, given the limited availability (nice way of saying zero) of FIRS servers. Most noticably, the system does not do any bottom-up or top-down queries (no servers to query) but instead only does targeted queries to the (default) partition of ntrg.com. If you create your own FIRS-compliant LDAP database, you can give the app a "--part=your.domain" switch and it will work; it *does* do the SRV lookups and everything necessary, just there aren't any other servers out there, so it's hard-wired to default to my server. Also, this is a very basic LDAP server that does not support extended syntaxes or filters, so none of the fancy LDAP stuff is there (this includes ASN.1 attributes, unfortunately). Secondary limitations include a lack of support for IPv6 objects and referrals. Otherwise, it works as a real-world system would work. It's not all a suck though, and there are some interesting features. For one, the client will emulate the matching filters if it sees that the server doesn't support them (this is a new feature in the firs-*-02 I-Ds that were just published, btw). This means you can give it an IPv4 address of (eg) 192.168.12.209 and it will find all of the parent delegations (just like the specs say that servers should do), and it will find the two matching parents that are in the database now. View the source to see how this is done. The purpose of this demonstration is to show that implementation is pretty simple. I used off-the-shelf perl modules and an LDAP server bundled with my mail server to implement this, and it took less than a week. I'm trying to get somebody to help write the matching filters and syntaxes code for openldap so that a more complete demonstration system can be put together. Once I get another open of time, I'll also put together a web front-end that will let people add/delete/modify entries in the back-end. I'll advise if/when we get there. disclaimer--This is very rough, slow, undebugged, all of that. I haven't done any serious programming in over 10 years and my knuckles are rusty. Please be gentle. :p -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From edlewis at arin.net Fri Jul 25 18:00:50 2003 From: edlewis at arin.net (Edward Lewis) Date: Fri Jul 25 17:04:09 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F16BF47.3010301@ehsco.com> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> Message-ID: At 10:22 -0500 7/17/03, Eric A. Hall wrote: >as a whole. We really don't want to make decisions based on the desires of >the operator community in particular. Otherwise, we'd just stick with >WHOIS since doing nothing is the cheapest and easiest by far. I think that's an oversimplification. "Sticking" is cheap and easy, but WhoIs lacks some crucial features. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From edlewis at arin.net Fri Jul 25 18:04:30 2003 From: edlewis at arin.net (Edward Lewis) Date: Fri Jul 25 17:04:15 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F17EC88.4070600@ehsco.com> References: <3F17EC88.4070600@ehsco.com> Message-ID: At 7:48 -0500 7/18/03, Eric A. Hall wrote: >on 7/17/2003 8:07 AM Edward Lewis wrote: > >> PS - I haven't had time to really think though how this plays for >> Routing registries. If anyone can contribute thoughts on this, I'd >> appreciate it. > >I thought up a good analogy this morning -- the use of multiple IRR >servers with [crisp] is very similar to the use of blacklists in DNS, I'm not sure what you mean by a blacklist. Do you mean a list of servers that a client relies upon for answers or a list of clients that a server will ignore? >like DNS. Some applications will want to create their own partitions, but >others could reuse the public namespace and simply layer on their own >objectclass definitions at the public leaf nodes, too. I'm not sure what you mean my partitions wrt DNS. Like "class" or "type" or splitting the names in some way? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From edlewis at arin.net Fri Jul 25 17:58:35 2003 From: edlewis at arin.net (Edward Lewis) Date: Fri Jul 25 17:04:21 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F16BD30.8010901@ehsco.com> References: <3F16BD30.8010901@ehsco.com> Message-ID: At 10:13 -0500 7/17/03, Eric A. Hall wrote: >Any existing external delegation system can be used for this, but as a >practical matter, there is only one delegation system which satisfies >these concerns, which is DNS. Speaking mostly from the perspective of a chair of the provreg group, one thing I notice is that often times IETF WG's take on the bias of the participants. Although this sounds like I am leading to an indictment of the process, I don't mean for it to be so. I'm leading with this because I can see how domain name registration folks can see DNS as being the natural fit. Ergo, I'm not going to argue with that the WG has found to date and how it got to that point. I also should point out that I'm far from having a real, precise reason to disagree, I'm asking in a discovery mode. I have yet to be convinced that DNS is the end-all for the purpose here (thinking of the domainComponents). E.g., in some private communications (and at the end of my reply to Michael Dillon) I mentioned that, for example, as DNS zones are not necessary for address space to be useful, DNS isn't a reliable convention for finding the appropriate directory server when you are starting a query. I might be running my own "CRISP" server and exchanging routes with others but not running DNS. (It could happen.) It's over this uncertainty that I am raising the question of extensibility and whether it's a factor in FIRS' name space definition. >These heavily >virtualized approaches can be difficult to get your head around. That's exactly what should be apparent from the WG's output - starting with a discussion in an archive and then followed up in a perpetuating document. ;) That being said - my entire reply here is an aside to give my rationale for asking the question in the first place. What I will need to do is to see just how a hierarchical name space helps, hinders, or neither the application space I'm considering. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From edlewis at arin.net Fri Jul 25 18:11:25 2003 From: edlewis at arin.net (Edward Lewis) Date: Fri Jul 25 17:11:05 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <200307251641.25626.davidb@verisignlabs.com> References: <200307251641.25626.davidb@verisignlabs.com> Message-ID: At 16:41 -0400 7/25/03, David Blacka wrote: >Let me try to restate this: you are saying that because address allocation >information, unlike domain allocation information, does not need DNS to >function, and so the reverse tree is broken, clumsy or nonexistent. Thus, >using the reverse tree to find CRISP servers is problematic. > >Did I get that right? Dang close. s/reverse tree is/reverse tree could be and in some cases is/ >Assuming I did, and it seems like a reasonable conclusion to me, do you >have a better suggestion? do you think that all address searches should >start from the top (i.e., just don't do SRV lookups)? I don't have a suggestion at this point, I'm still new to the problem and my belief/theory that there's a significant difference lurking here. I wish I had a suggestion. Perhaps yes to the latter question. It's fairly clear to go to the source of the authority and ask "who did you give it to" and chase the chain of custody than reverse the path. One reason - you can't rely on there being a reverse DNS for the space. Another reason is with the way addresses can be reassigned and used, it's not easy to reverse the path. E.g., I (as a registry) may allocate to you (as operator) 5 IP prefixes and 5 AS numbers, but I can't tell how you mix and match them. (I'd need to look into the route tables to see.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From ehall at ehsco.com Fri Jul 25 17:12:04 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 25 17:12:15 2003 Subject: [Ietf-not43] [Fwd: I-D ACTION:draft-hall-firs-svc-00.txt] Message-ID: <3F219D24.2060704@ehsco.com> FYI, this is a service-discovery mechanism that I've been thinking about for a while, that would be layered on top of a FIRS data-substrate. The combination of rich data and ACLs (in addition to known-anonymous) solves a bunch of scope-specific service-location needs. [...] "this model would allow a client to query for the service-specific data which was associated with a known user, but if that data was not available (either because it did not exist, or because the client did not have permission to read the entry), then the client could query for the service-specific data which was associated with the user's domain." This isn't directly related to FIRS work, but its an example of what becomes feasible with a rich substrate, and the kind of layered services that would become available. The relevance of this will become clearer when I finish assembling my argument case. BTW, there are a couple of errors in the I-D that I should have caught before it went out. No need to pay close attention to anything in here. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -------------- next part -------------- An embedded message was scrubbed... From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-firs-svc-00.txt Date: Wed, 23 Jul 2003 15:14:21 -0400 Size: 3632 Url: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20030725/f75c2f6e/draft-hall-firs-svc-00-0001.eml From ehall at ehsco.com Fri Jul 25 17:15:13 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 25 17:15:19 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> Message-ID: <3F219DE1.2090306@ehsco.com> on 7/25/2003 4:00 PM Edward Lewis wrote: > At 10:22 -0500 7/17/03, Eric A. Hall wrote: > >>as a whole. We really don't want to make decisions based on the desires of >>the operator community in particular. Otherwise, we'd just stick with >>WHOIS since doing nothing is the cheapest and easiest by far. > > I think that's an oversimplification. "Sticking" is cheap and easy, > but WhoIs lacks some crucial features. The ratio of users to service providers is probably close to about 10,000,000:1 give or take a million. Making a decision based on the convenience of ~300 whois providers is wrong, imo. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Fri Jul 25 17:39:19 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 25 17:39:12 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: <200307251641.25626.davidb@verisignlabs.com> Message-ID: <3F21A387.1080907@ehsco.com> on 7/25/2003 4:11 PM Edward Lewis wrote: > Perhaps yes to the latter question. It's fairly clear to go to the > source of the authority and ask "who did you give it to" and chase > the chain of custody than reverse the path. One reason - you can't > rely on there being a reverse DNS for the space. This is how FIRS works with ASNs and IP addresses. Find the LDAP server for asn.arpa, in-addr.arpa, etc., and follow the in-band referrals down. DNS isn't being used everywhere, just for bootstrapping the query. But having said that, DNS is still being used as the delegation *authority* for the query, since the DNS information has control. Separately, if this is trustworthy and reliable for finding the ~default servers, then there's no reason not to use the same approach for finding other partitions (eg, private route servers, or whatever). > Another reason is > with the way addresses can be reassigned and used, it's not easy to > reverse the path. The only time you'd WANT to ask a specific server for its view of a piece of data is because you have an application that knows it can benefit from that data. As such, that application (which may just be your own personal habit rather than a piece of code) would have to be wired to know "go ask this partition for information about the resource". All of that is only going to work if the delegation entries exist and are functional. If the delegation entries don't work, you can't ask that server for anything anyway. Working delegations are only needed if you plan to offer a service at the partition that is linked to the domain name in question. The other 99% of the delegations don't even have to exist, much less be functional. If nobody ever asks them for anything, who cares. Now then, once there is a broad base of data ~out there, then I expect that there will be more user-to-user applications, and those WOULD require working delegations to function. It may be that using something like a route server would make more sense than using DNS, but I'd want to discuss this in the context of specific applications. In the general case, a delegation is a delegation is a delegation. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Fri Jul 25 19:45:00 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 25 19:44:54 2003 Subject: [Ietf-not43] FIRS demonstration In-Reply-To: <3F21970E.7050704@ehsco.com> References: <3F21970E.7050704@ehsco.com> Message-ID: <3F21C0FC.4000103@ehsco.com> on 7/25/2003 3:46 PM Eric A. Hall wrote: > I've scratched up a very rough v0.01 FIRS demonstration system which > illustrates how it can work (not necessarily how it will work). This > includes a text-based Perl client and an LDAP database, both of which > are running on the test system. Just in case this isn't clear, the client part is indeed separate from the server part. You can download the client (using the "--source" switch) and run it from your local workstation without modification; it will go find the server and issue the queries, just like the hosted version is currently doing. The demonstration just has the client on tcp/43 on that particular server for ease-of-demonstration purposes, and there's nothing about tcp/43 or that particular client that requires such. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From edlewis at arin.net Fri Jul 25 21:01:22 2003 From: edlewis at arin.net (Edward Lewis) Date: Fri Jul 25 20:15:44 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F219DE1.2090306@ehsco.com> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> Message-ID: At 16:15 -0500 7/25/03, Eric A. Hall wrote: >> I think that's an oversimplification. "Sticking" is cheap and easy, >> but WhoIs lacks some crucial features. > >The ratio of users to service providers is probably close to about >10,000,000:1 give or take a million. Making a decision based on the >convenience of ~300 whois providers is wrong, imo. Your point is valid, but I don't think it is what Richard's (and my) comment centered on. Just to try and clarify at least where I'm coming from... There's a difference between the service offered and how it is implemented. Given two implementations that that offer the required service and the desire to pick one, there has to be other differentiations made. (This is the state the WG is in. Both FIRS and IRIS are built to what we decided are the rules of the game. It's a tie according to this, but we can't have a tie.) It's not a matter of what's best for the user vs. what's best for the provider. Between FIRS and IRIS, well, let's assume they both provide the same service. In that case I'd say it is valid for the providers to lean to the one that offers it more cheaply. Because the cheaper one is chosen, in the long run every one wins. Alternatively, if both provide the required service, and one does the job better than the other, then picking the more functional one is a logical choice - clearly so if they both cost the same to implement. But what if both meet the requirements, but one alternative does a 10% better job for 10% more cost? 15% more cost? What Richard and I said was that for the provider, it seems that IRIS has an edge in adoption given other work being done in registries. Perhaps there are advantages down the FIRS road he and I are missing. And perhaps FIRS is more suited to what the consumers demand. The latter two points need to be made. This is why I raised the question about the name space and extensibility. Is it just that I don't see the advantage of domainComponents? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From ehall at ehsco.com Fri Jul 25 21:42:43 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Jul 25 21:42:37 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> Message-ID: <3F21DC93.2080003@ehsco.com> on 7/25/2003 7:01 PM Edward Lewis wrote: > It's not a matter of what's best for the user vs. what's best for the > provider. Between FIRS and IRIS, well, let's assume they both > provide the same service. In that case I'd say it is valid for the > providers to lean to the one that offers it more cheaply. Because > the cheaper one is chosen, in the long run every one wins. I disagree with both the premise and the conclusion. Given that user-to-user applications can be expected to be deployed that reuse the chosen transport, namespace, messaging, etc., the unavoidable conclusion is that what's best for the user *IS* going to be the most important. What is easy for them to deploy and manage, what offers the most integration into other services, these are the criteria we should be focusing on, since those will ultimately determine whether this is actually a successful broadly-deployed service or if its just a more expensive version of whois that is once again limited to being offered by a handful of delegation bodies. Furthermore, as far as the expense argument goes, I think that a critical analysis on that point would actually favor FIRS. It may be cheaper for delegation operators to reuse the provreg stuff (although I'm not even convinced of that; just that it's more convenient), but for the average user the initial cost won't have already been underwritten. I mean, LDAP gives them a pre-networked database that is tightly integrated with a transport service already, provides integrated authentication and authorization services, has broad support from the vendor and support communities, etc. I can't even find a BEEP module on CPAN, and remember we're expecting the community to stitch together unspecified databases and XML together and security and all of that everytime they want a new application in the service space. Cheaper? LDAP definitely. Then we get into the real meaty stuff, like the number of RFCs that have gone into LDAP, and how long do you expect it would take to replicate all of that in databaseX-beep-xml. Or, which do you suppose the PKIX community would prefer, starting over with databaseX-beep-xml or LDAP. And numerous other similar arguments. Really what the favoritism towards IRIS boils down to is a preference for convenience. Now we've got a hammer, let's go find some nails. That might even be okay -- I'm certainly favoring LDAP because of convenience reasons too -- except that provreg is a closed-community service. By that I mean, the providers are the consumers and vice-versa, and supporting millions of application agents probably wasn't much of a design consideration, while that really has to be this WG's focus entirely (even if no user-to-user applications are ever developed, we'll be looking at that scale from programmatic lookups alone anyway). > This is why I raised the question about the name space and > extensibility. Is it just that I don't see the advantage of > domainComponents? I don't see what domainComponent has to do with any of this. So the linkage to a universal, managed namespace is transparent, so what? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leifj at it.su.se Sat Jul 26 11:11:49 2003 From: leifj at it.su.se (Leif Johansson) Date: Sat Jul 26 04:15:01 2003 Subject: [Ietf-not43] FIRS demonstration In-Reply-To: <3F21970E.7050704@ehsco.com> References: <3F21970E.7050704@ehsco.com> Message-ID: <3F2237C5.6040202@it.su.se> Eric A. Hall wrote: >I've scratched up a very rough v0.01 FIRS demonstration system which >illustrates how it can work (not necessarily how it will work). This >includes a text-based Perl client and an LDAP database, both of which are >running on the test system. > > A couple of comments on the code ... You should add version=>3 to your Net::LDAP->new - as it is you are using LDAPv2 which is doesn't support controls so you will never receive a control as the result of your bind from a typical ldap servers. Now I haven't read the FIRS draft (yet) so I am only guessing that FIRS is supposed to return a control on bind. However (apart from the fact that this requires LDAPv3) the usual way to look for a supported control is to lookup the root-DSE entry and look for the oid in the supportedControl attribute. I am not sure if this is a critique of the code or of the draft though :-) sub isFIRSServer() { my $ldap = shift; my $res = $ldap->search(base=>'',filter=>'objectClass=*',scope=>'base',attrs=>'+'); $res->code && die $res->error; my $e = $res->pop_entry(); die "No root-DSE" unless $e; grep /^1.3.6.1.4.1.7161.1.0.0$/,$e->get_value('supportedControl'); } Cheers Leif From ehall at ehsco.com Sat Jul 26 11:33:19 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sat Jul 26 11:33:13 2003 Subject: [Ietf-not43] FIRS demonstration In-Reply-To: <3F2237C5.6040202@it.su.se> References: <3F21970E.7050704@ehsco.com> <3F2237C5.6040202@it.su.se> Message-ID: <3F229F3F.3040007@ehsco.com> on 7/26/2003 3:11 AM Leif Johansson wrote: > You should add version=>3 to your Net::LDAP->new - as it is you are doh! fixed > Now I haven't read the FIRS draft (yet) so I am only guessing that FIRS > is supposed to return a control on bind. However (apart from the fact > that this requires LDAPv3) the usual way to look for a supported > control is to lookup the root-DSE entry and look for the oid in the > supportedControl attribute. I am not sure if this is a critique of the > code or of the draft though :-) Yes, the server is supposed to return the firsVersion control on bind. This is more-or-less modelled on the password-about-to-expire control, which is an unsolicited server control that tells the client to change the password immediately. The control and the usage behavior are described in section 5.3.1 of draft-ietf-crisp-firs-core-02 with supporting text in some of the resource-specific documents. Essentially, the control lists the object classes for the resource-types that the server fully supports. This provides an easier way to do schema versioning, but it also enables some distributed processing, in that the client can choose to implement the necessary logic locally (emulate the matching filter, as in firs.pl) or skip to the next server in the connection list. I specifically want to avoid the extra round-trip time needed for an explicit control query. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Sat Jul 26 12:03:11 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sat Jul 26 12:03:01 2003 Subject: [Ietf-not43] FIRS demonstration In-Reply-To: <3F229F3F.3040007@ehsco.com> References: <3F21970E.7050704@ehsco.com> <3F2237C5.6040202@it.su.se> <3F229F3F.3040007@ehsco.com> Message-ID: <3F22A63F.2020200@ehsco.com> on 7/26/2003 10:33 AM Eric A. Hall wrote: > I specifically want to avoid the extra round-trip time needed for an > explicit control query. Actually, an extra round-trip isn't too bad as a first-step recovery effort. I've added some text to the draft so that if the server doesn't automatically provide the control, have the client explicitly request it just to double-check the server's capabilities before proceeding with other recovery efforts. I'll add the code to firs.pl in the next window. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leifj at it.su.se Sat Jul 26 20:50:28 2003 From: leifj at it.su.se (Leif Johansson) Date: Sat Jul 26 13:53:39 2003 Subject: [Ietf-not43] FIRS demonstration In-Reply-To: <3F22A63F.2020200@ehsco.com> References: <3F21970E.7050704@ehsco.com> <3F2237C5.6040202@it.su.se> <3F229F3F.3040007@ehsco.com> <3F22A63F.2020200@ehsco.com> Message-ID: <3F22BF64.4020704@it.su.se> Eric A. Hall wrote: >on 7/26/2003 10:33 AM Eric A. Hall wrote: > > > >>I specifically want to avoid the extra round-trip time needed for an >>explicit control query. >> >> > >Actually, an extra round-trip isn't too bad as a first-step recovery >effort. I've added some text to the draft so that if the server doesn't >automatically provide the control, have the client explicitly request it >just to double-check the server's capabilities before proceeding with >other recovery efforts. I'll add the code to firs.pl in the next window. > > > I was just about to say the same. You should get the AD to arrange for a review of the draft by the LDAP Directorate - imo it is good to have firs aligned with common practice in the ldap community. MVH leifj From anewton at ecotroph.net Mon Jul 28 02:04:03 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Jul 28 01:04:09 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F21DC93.2080003@ehsco.com> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <3F21DC93.2080003@ehsco.com> Message-ID: <3F24AEC3.6050607@ecotroph.net> Eric A. Hall wrote: > on 7/25/2003 7:01 PM Edward Lewis wrote: > > >>It's not a matter of what's best for the user vs. what's best for the >>provider. Between FIRS and IRIS, well, let's assume they both >>provide the same service. In that case I'd say it is valid for the >>providers to lean to the one that offers it more cheaply. Because >>the cheaper one is chosen, in the long run every one wins. > > > ...[snip]... > > Really what the favoritism towards IRIS boils down to is a preference for > convenience. Now we've got a hammer, let's go find some nails. > > ...[snip]... I take great exception to this mis-charactarization of providers. Many of us have spent and are spending a considerable amount of resources to get this right. We have a pretty good idea about being on the business end of a tech support phone call when things go wrong. -andy From Michael.Dillon at radianz.com Mon Jul 28 11:08:40 2003 From: Michael.Dillon at radianz.com (Michael.Dillon@radianz.com) Date: Mon Jul 28 05:09:23 2003 Subject: [Ietf-not43] extensibility Message-ID: >This isn't so true with IP address ranges. A limitation of DNS gives >us essentially a choice of /16 and /24 sized zones, with the RFC 2137 >process to help a bit in un-CIDRizing this, meaning that for an >arbitrary range, it's not so clear cut where to put the SRV-like >pointers. (They may need to be replicated 127 times for a /17.) >That, and, because there's some question as to the value of the >reverse map, esp. in IPv6, there's no guarantee that there is even a >place to put the SRV-like things. If we need a place within DNS to put SRV-like pointers for the IP address allocation hierarchy, then we can make one. For instance we could set up crisp.arpa and use it for this purpose. If you want to find the FIRS server for 192.0.0.7 then look up the SRV record for 7.0.0.1.9.2.crisp.arpa. Or perhaps some other naming scheme. The fact is that the RIRs will have to implement FIRS servers in order to root the allocation hierarchies so asking them to maintain and delegate a new DNS zone is not too much to ask. It could be done using a special version of DNS server software (nsd, djbdns, BIND) that can generate synthetic DNS replies based on knowledge of the RIR's database so that you don't have to generate huge zone files for every /32. In fact, there is more than one LDAP-based DNS server where the DNS frontend answers queries based on a zone database in an LDAP backend. --Michael Dillon From Michael.Dillon at radianz.com Mon Jul 28 11:22:24 2003 From: Michael.Dillon at radianz.com (Michael.Dillon@radianz.com) Date: Mon Jul 28 05:23:06 2003 Subject: [Ietf-not43] extensibility Message-ID: >I also should point out that I'm far from having a real, precise >reason to disagree, I'm asking in a discovery mode. I have yet to be >convinced that DNS is the end-all for the purpose here (thinking of >the domainComponents). I agree that other mechanisms are possible, not just DNS. I think that the characteristics of DNS that lead one to think of it first are its scalability, notably the ability for caching servers to act as intermediaries and cache replies, and also its referral capability. Now, both of these things could technically be done with LDAP instead of DNS. In other words, to find the FIRS server with information for a given IP address such as 192.0.0.7 you would: 1. Query your local FIRS server. If it didn't have the answer it would 2. Query the IANA FIRS server on your behalf. This server would return a referral to one of the RIR servers such as ARIN 3. Your FIRS server would then query the ARIN server. ARIN's server would return a referral to an ISP's FIRS server 4. Your FIRS server would then query the ISP's server and receive an authoritative reply. 5. All of this information would be cached by your FIRS server and the authoritative reply would be passed on to you. A short time later, another user who shares the same local FIRS server would do a query on 192.0.0.8 and your local FIRS server would go directly to the correct ISP's FIRS server because it has cached the IANA and RIR lookup info. In this context, there is no such thing as a reverse map, just an allocation hierarchy that you can walk and cache. The major difference is that this scenario assumes that FIRS clients prefer to talk to a local FIRS resolver rather than walk the hierarchy themselves. --Michael Dillon From ehall at ehsco.com Mon Jul 28 08:43:48 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 08:43:55 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F24AEC3.6050607@ecotroph.net> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <3F21DC93.2080003@ehsco.com> <3F24AEC3.6050607@ecotroph.net> Message-ID: <3F251A84.2090706@ehsco.com> on 7/28/2003 12:04 AM Andrew Newton wrote: > Eric A. Hall wrote: >> Really what the favoritism towards IRIS boils down to is a preference >> for convenience. Now we've got a hammer, let's go find some nails. > I take great exception to this mis-charactarization of providers. on 7/25/2003 7:01 PM Edward Lewis also wrote: > What Richard and I said was that for the provider, it seems that IRIS > has an edge in adoption given other work being done in registries. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From richard at shockey.us Mon Jul 28 11:37:56 2003 From: richard at shockey.us (Richard Shockey) Date: Mon Jul 28 10:44:42 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> Message-ID: <5.2.0.9.2.20030728102213.03642a60@shockey.us> >> >>The ratio of users to service providers is probably close to about >>10,000,000:1 give or take a million. Making a decision based on the >>convenience of ~300 whois providers is wrong, imo. > >Your point is valid, but I don't think it is what Richard's (and my) >comment centered on. Just to try and clarify at least where I'm coming from... > >There's a difference between the service offered and how it is >implemented. Given two implementations that that offer the required >service and the desire to pick one, there has to be other differentiations >made. (This is the state the WG is in. Both FIRS and IRIS are built to >what we decided are the rules of the game. It's a tie according to this, >but we can't have a tie.) Thanks Ed .. the issue again see is is that all things being equal in terms of protocol and service requirements it boils down to Layer 8 (economic issues) and on that basis the advantages of IRIS at the margin tilt the balance. There is nothing wrong with the expedience in a choice where all other factors are roughly equal. >It's not a matter of what's best for the user vs. what's best for the >provider. Between FIRS and IRIS, well, let's assume they both provide the >same service. In that case I'd say it is valid for the providers to lean >to the one that offers it more cheaply. Because the cheaper one is >chosen, in the long run every one wins. > Exactly IRIS provides a simplified overall business process architecture for,IMHO, the domain name industry based on what we have to do. I cant speak to the business process issues among the RIR's. And lets face it the TLD operators, including my distinguished colleagues/competitors from Verisign really don't want to do anything if they don't have to since the economics of the business are not very pleasant these days even for a major Generic or CC tld. One way or another implementing these protocols will cost money and my analysis concludes that IRIS will be simpler and less expensive. >What Richard and I said was that for the provider, it seems that IRIS has >an edge in adoption given other work being done in registries. Perhaps >there are advantages down the FIRS road he and I are missing. And perhaps >FIRS is more suited to what the consumers demand. The latter two points >need to be made. If there are advantages of FIRS for consumers I'd certainly like to see that list. But realistically I take John Klensin's comments to heart that the sooner we make a decision the better. There are Layer 9 issues here (political aka ICANN) we have to deal with. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From ehall at ehsco.com Mon Jul 28 10:48:49 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 10:48:57 2003 Subject: [Ietf-not43] dns mapping Message-ID: <3F2537D1.5090302@ehsco.com> This message is an attempt to address Ed's concern that everything has to be mapped to DNS, or that DNS is the only allowable mapping service. First, let me talk about the requirements, then I'll address the issue of implementation considerations. Section 3.2.6 of the -05 requirements seems to specifically require mapping to DNS delegations, but the last sentence in 3.2.6.2 clarifies that it isn't required in all cases: | 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. Reviewing the mail between Andy, Marcos and myself, we wanted to enforce the point that some kind of external delegation system had to be used in all cases (that a crisp-specific, centralized database could not be used) but that DNS had to be used as the external delegation system for domain name resources in particular. So the requirements more-or-less say that any delegation system *can* be used for any resource other than domain names. If the requirements imply otherwise, then that's what they are supposed to say anyway. As far as FIRS goes, there are generally two places where domain name appear, but only of those instances are related to the above. The two instances are (1) mapping inputs to an LDAP partition according to the resource-specific behavioral rules, and (2) specifying the name of the target partition in the resulting query. I think that these are being viewed as one-and-the-same, even though they are actually separate. Mapping a resource name to an LDAP partition is a client operation, with the client examining the input and then determining the appropriate partition to use for the initial query. For example, the FIRS specification for ASNs currently says that clients must use the LDAP servers associated with the asn.arpa zone by default, while the IPv4 specification says that FIRS clients must use the LDAP servers associated with the in-addr.arpa zone by default, while the IPv6 specification says to use ip6.arpa by default. In all three of these cases, the data in the LDAP servers will be used to answer the queries and generate referrals, so the data in those servers (wherever that information is sourced from) is the authoritative delegation data, and any DNS information that may be used is limited to specifying the target partition by name (eg, locating the top-level partitions and/or any referral targets). So as far as that goes, the only real requirement with FIRS is that resource specifications must specify a way for clients to locate an LDAP server associated with that resource (which may include using a master domain name, as in the cases above), and the resulting server must be identifiable with a series of domainComponent labels (so that the servers associated with that partition can be located), but the only real DNS requirement is in the latter lookups, and not in the resource-mapping. If the ~RIR community wants to use some other kind of mapping algorithm that relies upon some other targetting mechanism (eg, using routing entries) then they are free to do so, with the only requirement being that the resulting partition(s) must be identifiable with domain names so that the associated LDAP servers can be located. Separately, the FIRS specifications (globally and at the resource level) also allow clients to override the default top-down mapping algorithm by mapping resources to resource-specific partitions, such as mapping a fully-qualified domain name to a particular partition (rather than asking the servers associated with the ~.com zone), or by mapping an IP address to a particular partition (rather than asking the in-addr.arpa zone). The exception here is ASNs, which do not have a mapping in DNS, so there is not any way to perform this kind of mappiing with those resources. All of this is a *secondary* benefit to using DNS for the primary mapping service, but it is not a requirement (and as seen with the current ASN approach, it won't necessarily be an option). I would encourage the RIR community to provide these kinds of secondary mapping algorithms, since they provide certain benefits which are important. Specifically, the ability to bypass the delegation hierarchy allows for shorter lookup times, and avoids problems with potentially incomplete entries at top-level mappings (eg, missing referral data). Hopefully that clarifies the situation somewhat. Any client-side mapping algorithm may be specified (the current placeholder specs use LDAP by default, and use DNS for secondary low-level mappings), but regardless of the mapping algorithm that gets used, the target for the query must be an LDAP partition and must be identifiable by DNS lookups for SRV RRs. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Mon Jul 28 11:54:30 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Jul 28 10:54:37 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F251A84.2090706@ehsco.com> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <3F21DC93.2080003@ehsco.com> <3F24AEC3.6050607@ecotroph.net> <3F251A84.2090706@ehsco.com> Message-ID: <3F253926.1060306@ecotroph.net> Eric A. Hall wrote: > on 7/28/2003 12:04 AM Andrew Newton wrote: > > >>Eric A. Hall wrote: > > >>>Really what the favoritism towards IRIS boils down to is a preference >>>for convenience. Now we've got a hammer, let's go find some nails. > > >>I take great exception to this mis-charactarization of providers. > > > on 7/25/2003 7:01 PM Edward Lewis also wrote: > > >>What Richard and I said was that for the provider, it seems that IRIS >>has an edge in adoption given other work being done in registries. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Richard's comment (in the meeting) was not exclusive to EPP. It was more of a general comment about the world moving towards XML and related technologies (e.g. witness what is going on in netconf and idmef). -andy From ehall at ehsco.com Mon Jul 28 11:04:37 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 11:04:45 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <5.2.0.9.2.20030728102213.03642a60@shockey.us> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> Message-ID: <3F253B85.2040805@ehsco.com> on 7/28/2003 9:37 AM Richard Shockey wrote: > There is nothing wrong with the expedience in a choice where all other > factors are roughly equal. I agree with this but let's be accurate about what we're advocating. The requirements list numerous "actors" (and omits just as many), not all of whom will benefit from this particular factor. The question I'm trying to raise is whether or not this one factor warrants ignoring or overriding all of the other actors' criteria, and as should be clear I don't think it does. > One way or another implementing these protocols will cost money and my > analysis concludes that IRIS will be simpler and less expensive. I would like to review the criteria behind this analysis. For FIRS, the requirement is (1) generate an LDIF file on a daily basis, (2) upload it to the server, and (3) use a server that supports the FIRS extensions. That is pretty cheap. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Mon Jul 28 12:12:22 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Jul 28 11:12:28 2003 Subject: [Ietf-not43] dns mapping In-Reply-To: <3F2537D1.5090302@ehsco.com> References: <3F2537D1.5090302@ehsco.com> Message-ID: <3F253D56.7020104@ecotroph.net> Eric A. Hall wrote: > This message is an attempt to address Ed's concern that everything has to > be mapped to DNS, or that DNS is the only allowable mapping service. > > First, let me talk about the requirements, then I'll address the issue of > implementation considerations. > > Section 3.2.6 of the -05 requirements seems to specifically require > mapping to DNS delegations, but the last sentence in 3.2.6.2 clarifies > that it isn't required in all cases: Section 3.2 is specific to domain name registries. Quoting it in the context of the RIR's is out of scope. > ...[snip]... > with the only requirement being that the > resulting partition(s) must be identifiable with domain names so that the > associated LDAP servers can be located. > ...[snip]... This may be the heart of the conflict. My two cents: 1) The IRIS drafts (and I had assumed the FIRS drafts) for address registries are really just place holders. They demonstrate some interesting ideas of what might be. 2) However, if the RIR community says there is a better method, we should strongly prefer it. -andy From Michael.Dillon at radianz.com Mon Jul 28 17:16:49 2003 From: Michael.Dillon at radianz.com (Michael.Dillon@radianz.com) Date: Mon Jul 28 11:17:33 2003 Subject: [Ietf-not43] dns mapping Message-ID: >For example, the FIRS >specification for ASNs currently says that clients must use the LDAP >servers associated with the asn.arpa zone by default, while the IPv4 >specification says that FIRS clients must use the LDAP servers associated >with the in-addr.arpa zone by default, while the IPv6 specification says >to use ip6.arpa by default. This doesn't make sense. If you are using FIRS to look-up information about the IP address block owner, then the mapping in in-addr.arpa or ip6.arpa is useless because it refers to the domain name of the device currently USING the address, not the owner of the address block. In a block of 256 IPv4 addresses owned by one entity there could be 256 different user domains. You cannot use the DNS reverse map to map the delegation hierarchy of IP address blocks. For one thing, the DNS reverse map has no way to identify IP address ranges or blocks. It was intended to deal with reverse mapping of hosts or individual IPv4 addresses. Let's work through an example. I am the owner of 192.0.2/24 which is an IP address range from 192.0.2.0 to 192.0.2.255. Rather conveniently this IP address range also corresponds to a CIDR block but that is not always the case. Now I have a customer, example.com, who want to run a web server in my data center so I set up a PTR record in my 2.0.192.in-addr.arpa zone that reads: 67 IN PTR www.example.com Now my customer has registered the domain name example.com elsewhere and made his own separate arrangements for DNS so he will be putting the following in his example.com zone: www IN A 192.0.2.67 You want to use FIRS to find out something about 192.0.2.67 so you start by checking the reverse map for 67.2.0.192.in-addr.arpa but all that I have there is a PTR record referring you to example.com. And since example.com doesn't have their own IP address range, they have no SRV records for FIRS in their DNS server. Are you suggesting that I should have 67 IN PTR www.example.com IN SRV _firs._tcp.mydomain.com in my in-addr.arpa zone? Because this would case the size of the in-addr.arpa zone to double with mostly redundant data which is not a good thing. Remember, the IP address allocation hierarchy is orthogonal to the domain name delegation hierachy. It is also orthogonal to the AS Number allocations. A single entity can have multiple ASNs and multiple IP address ranges but does not have to identify an address range with a specific ASN. There are also address ranges that are allocated to entities who have no ASN at all. As far as route registries go, there is a reason why the RIRs operate their route registry separate from their IP address registry. That is because they are orthogonal. There are many IP address ranges that do not have an associated route. There can be many routes associated with a given IP address range. The routing protocols are charged with choosing the best route which clearly implies that there is more than one. The specific routes associated with an IP address change dynamically with the network topology and are not in the route registry. What the route registry does do is to identify the set of possible IP address ranges that an ASN holder might choose to announce to their peers. The intent is that the peers can filter out rogue announcements by double-checking the dynamic unauthenticated routing protocols against a less dynamic better authenticated route registry. If FIRS ever does become suitable to replace the RPSL used in route registries it would only be after FIRS is used in practice for the simpler job of running an IP address registry. --Michael Dillon From ehall at ehsco.com Mon Jul 28 11:24:22 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 11:24:29 2003 Subject: [Ietf-not43] dns mapping In-Reply-To: References: Message-ID: <3F254026.6020900@ehsco.com> on 7/28/2003 10:16 AM Michael.Dillon@radianz.com wrote: >> For example, the FIRS specification for ASNs currently says that >> clients must use the LDAP servers associated with the asn.arpa zone >> by default, while the IPv4 specification says that FIRS clients must >> use the LDAP servers associated with the in-addr.arpa zone by >> default, while the IPv6 specification says to use ip6.arpa by >> default. > > This doesn't make sense. If you are using FIRS to look-up information > about the IP address block owner, then the mapping in in-addr.arpa or > ip6.arpa is useless because it refers to the domain name of the device > currently USING the address, not the owner of the address block. In a > block of 256 IPv4 addresses owned by one entity there could be 256 > different user domains. You misread it. The default mapping is a top-level mapping. EG, if a user enters *ANY* IPv4 address, the client says "oh this is an IPv4 address" and issues lookups for _ldap._tcp.in-addr.arpa. The default is to go ask the LDAP servers associated with the entire IPv4 address space, not the servers associated with a specific address. Separately, the model allows a user to override the default behavior and ask for the servers associated with a particular address, but that's only provided as a feature, as a way to circumnavigate the delegation servers in those situations where this would be handy (EG, if there is a ~route service definition, where user-to-user queries would be useful, and where the entities are providing the service). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Jul 28 11:29:09 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 11:29:16 2003 Subject: [Ietf-not43] dns mapping In-Reply-To: <3F254026.6020900@ehsco.com> References: <3F254026.6020900@ehsco.com> Message-ID: <3F254145.3070608@ehsco.com> on 7/28/2003 10:24 AM Eric A. Hall wrote: > EG, if a user enters *ANY* IPv4 address, the client says "oh this is an > IPv4 address" and issues lookups for _ldap._tcp.in-addr.arpa. The default > is to go ask the LDAP servers associated with the entire IPv4 address > space, not the servers associated with a specific address. And like Andy said, this is just placeholder/experimental stuff, until the RIR community comes up with a mapping algorithm that it wants to use. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Mon Jul 28 19:50:25 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Jul 28 12:50:40 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <5.2.0.9.2.20030728102213.03642a60@shockey.us> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> Message-ID: <3F255451.6050204@daasi.de> Richard Shockey wrote: [...] > Thanks Ed .. the issue again see is is that all things being equal in > terms of protocol and service requirements it boils down to Layer 8 > (economic issues) and on that basis the advantages of IRIS at the margin > tilt the balance. > > There is nothing wrong with the expedience in a choice where all other > factors are roughly equal. As to layer 8, I agree with Richard here. > > >> It's not a matter of what's best for the user vs. what's best for the >> provider. Between FIRS and IRIS, well, let's assume they both provide >> the same service. In that case I'd say it is valid for the providers >> to lean to the one that offers it more cheaply. Because the cheaper >> one is chosen, in the long run every one wins. >> > > Exactly IRIS provides a simplified overall business process architecture > for,IMHO, the domain name industry based on what we have to do. I cant > speak to the business process issues among the RIR's. > > And lets face it the TLD operators, including my distinguished > colleagues/competitors from Verisign really don't want to do anything if > they don't have to since the economics of the business are not very > pleasant these days even for a major Generic or CC tld. > > One way or another implementing these protocols will cost money and my > analysis concludes that IRIS will be simpler and less expensive. Is this really so? What makes you think so that a complete new implementation will be cheaper than using existing technology and do some tweaks to make it CRISP compliant? Alone the fact that Eric could perl a FIRS client in one week prooves ho cheap it can be to deploy FIRS. I know it is a long way from proof of concept to production service, but what makes you think this path is shorter with XML? Are there existing XML data base technologiers that are as performant, scalable and secure as are LDAP implementations? Only because things like Web services are being deployed in the commercial realm, does this make IRIS deployment really cheaper? > > >> What Richard and I said was that for the provider, it seems that IRIS >> has an edge in adoption given other work being done in registries. >> Perhaps there are advantages down the FIRS road he and I are missing. >> And perhaps FIRS is more suited to what the consumers demand. The >> latter two points need to be made. > > > If there are advantages of FIRS for consumers I'd certainly like to see > that list. One might be that FIRS client will be easy to write and client authors will find lots of goodies and features to the liking of the user. But I think the main advantages are more for the FIRS providers, since data management, replication scenarios, backup mechanisms, and above all distribution of data in a server mesh just are there and easily handable. > > But realistically I take John Klensin's comments to heart that the > sooner we make a decision the better. There are Layer 9 issues here > (political aka ICANN) we have to deal with. Yup. Layer 9 is quite unpredictable for a technician like me. But don't the political decisions more influence Layer 8 instead of the technical layers? Just my 2 cent. Cheers, Peter > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From anewton at ecotroph.net Mon Jul 28 14:29:15 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Jul 28 13:29:31 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F253B85.2040805@ehsco.com> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F253B85.2040805@ehsco.com> Message-ID: <3F255D6B.9000102@ecotroph.net> Eric A. Hall wrote: > > I would like to review the criteria behind this analysis. For FIRS, the > requirement is (1) generate an LDIF file on a daily basis, (2) upload it > to the server, and (3) use a server that supports the FIRS extensions. > That is pretty cheap. > This makes implementation and operational assumptions that are simplifications of how registries operate. It also makes assumptions about the data models which I know are not true for domain registries and I suspect are even less true for address registries. At some point I will try to put it all together in one place, but for now I can only point to the snippets: > http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt and appendix C of > http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-03.txt -andy From anewton at ecotroph.net Mon Jul 28 14:39:43 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Jul 28 13:39:50 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F255451.6050204@daasi.de> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F255451.6050204@daasi.de> Message-ID: <3F255FDF.5040102@ecotroph.net> Peter Gietz wrote: > > Alone the fact that Eric could perl a FIRS client in one week prooves ho > cheap it can be to deploy FIRS. I know it is a long way from proof of > concept to production service, but what makes you think this path is > shorter with XML? > Speaking as somebody who has put together both types of systems (Pimmit - IRIS -00 and draft-newton-ldap-whois-03.txt*), I can tell you that LDAP offered no speed of implementation or ease of deployment advantages. * draft-newton-ldap-whois-03 is not as far reaching as FIRS. -andy From ehall at ehsco.com Mon Jul 28 14:02:50 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 14:02:56 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F255D6B.9000102@ecotroph.net> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F253B85.2040805@ehsco.com> <3F255D6B.9000102@ecotroph.net> Message-ID: <3F25654A.3020205@ehsco.com> on 7/28/2003 12:29 PM Andrew Newton wrote: > Eric A. Hall wrote: > >>I would like to review the criteria behind this analysis. For FIRS, the >>requirement is (1) generate an LDIF file on a daily basis, (2) upload it >>to the server, and (3) use a server that supports the FIRS extensions. >>That is pretty cheap. > > This makes implementation and operational assumptions that are > simplifications of how registries operate. It also makes assumptions > about the data models which I know are not true for domain registries > and I suspect are even less true for address registries. I should have said 'minimal requirements', which is true. It is entirely possible to go beyond that (voluntarily), but it is not necessary. For example, the requirements document does not mandate a read-write system, but only allows for it, and the minimal requirements support a read-only service as mandated. One step beyond the minimal requirements might be to generate LDIF changelogs every 15 minutes or so, with the adds, updates and deletes being applied more frequently. A far-edge usage could be made which put LDAP at the center of the registration system (generating ~XML as output, instead of using another database and generating LDIF as output). These are all beyond the minimal requirements however. >>http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt This is an example of a voluntary system which goes further than the minimal requirements, imo. > and appendix C of > >>http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-03.txt This seems to discuss some specific needs of large-scale operators, which I think were included in the "uses FIRS extensions" sub-claim (which is not just limited to search filters, but also includes things like query limiters). Granted, there are going to be some deployment issues for some registry operators, but nothing beyond the kind of issues that LDAP servers already deal with frequently (eg, clustering and replication can take care of most stuff, and isn't technically a full step beyond the minimum requirements listed earlier). As far as that goes, doing this work for LDAP is going to be cheaper than doing this same necessary work in addition to all of the other glue necessary for IRIS. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From richard at shockey.us Mon Jul 28 14:59:01 2003 From: richard at shockey.us (Richard Shockey) Date: Mon Jul 28 14:03:10 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F255451.6050204@daasi.de> References: <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> Message-ID: <5.2.0.9.2.20030728133230.03a39f90@shockey.us> >> >>>It's not a matter of what's best for the user vs. what's best for the >>>provider. Between FIRS and IRIS, well, let's assume they both provide >>>the same service. In that case I'd say it is valid for the providers to >>>lean to the one that offers it more cheaply. Because the cheaper one is >>>chosen, in the long run every one wins. >>Exactly IRIS provides a simplified overall business process architecture >>for,IMHO, the domain name industry based on what we have to do. I cant >>speak to the business process issues among the RIR's. >>And lets face it the TLD operators, including my distinguished >>colleagues/competitors from Verisign really don't want to do anything if >>they don't have to since the economics of the business are not very >>pleasant these days even for a major Generic or CC tld. >>One way or another implementing these protocols will cost money and my >>analysis concludes that IRIS will be simpler and less expensive. > >Is this really so? What makes you think so that a complete new >implementation will be cheaper than using existing technology and do some >tweaks to make it CRISP compliant? Well as Andrew pointed out correctly, it seems obvious that a truly stunning number of , dare I say it, "e-business" practices are moving to a XML based architecture transported on FOO. The classic being SOAP may of us have lots of experience with SOAP.... that PROVREG is going to such a design that many TLD's will be contractually obligated ( Layer 9 again) to implement means that I have to build a service platform to support it ..If I can reuse that platform to implement CRISP, that is economically a "good thing" >Alone the fact that Eric could perl a FIRS client in one week prooves ho >cheap it can be to deploy FIRS. I know it is a long way from proof of >concept to production service, but what makes you think this path is >shorter with XML? I have no doubt it would be simple to implement FIRS ..is just that I dont want to .. that means 2 platforms I have to support and the registration data from PROVREG has to be converted...that is more work. When I have to propose capital budgets for platforms that do this and that the question is always raised ..." Well cant we reuse this box and development time for that?" >Are there existing XML data base technologiers that are as performant, >scalable and secure as are LDAP implementations? Yep... look at the APACHE SOAP stuff.. the bindings and transport are easily adaptable. We in the IETF are generally opposed to the use of HTTP/S transport for everything under the sun which is why BEEP was developed. In fact the IESG has a directive specifically prohibiting the further use of HTTP as a transport layer in IETF application protocols. If the IETF weren't so opposed to SOAP on religious grounds we'd probably be using that. And if I had to choose I'd prefer SOAP but I'm realistic enough to know that is not going to happen. >Only because things like Web services are being deployed in the >commercial realm, does this make IRIS deployment really cheaper? IMHO yes. Nails are cheep, Hammers are expensive :-) >>>What Richard and I said was that for the provider, it seems that IRIS >>>has an edge in adoption given other work being done in registries. >>>Perhaps there are advantages down the FIRS road he and I are missing. >>>And perhaps FIRS is more suited to what the consumers demand. The >>>latter two points need to be made. >> >>If there are advantages of FIRS for consumers I'd certainly like to see >>that list. > >One might be that FIRS client will be easy to write and client authors >will find lots of goodies and features to the liking of the user. But I >think the main advantages are more for the FIRS providers, since data >management, replication scenarios, backup mechanisms, and above all >distribution of data in a server mesh just are there and easily handable. maybe ... I remain unconvinced. >>But realistically I take John Klensin's comments to heart that the sooner >>we make a decision the better. There are Layer 9 issues here (political >>aka ICANN) we have to deal with. > >Yup. Layer 9 is quite unpredictable for a technician like me. But don't >the political decisions more influence Layer 8 instead of the technical layers? alas yes .... but in this situation they cannot be ignored especially when the choice between IRIS and FIRS on purely protocol and service requirements are virtually indistinguishable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From ehall at ehsco.com Mon Jul 28 14:11:59 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Jul 28 14:12:05 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F255FDF.5040102@ecotroph.net> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F255451.6050204@daasi.de> <3F255FDF.5040102@ecotroph.net> Message-ID: <3F25676F.5060800@ehsco.com> You mean that implementing a fully-scoped read-write system had the same basic results in both cases. I'm sticking to the story that the minimum requirements are lower for FIRS. on 7/28/2003 12:39 PM Andrew Newton wrote: > Peter Gietz wrote: > >>Alone the fact that Eric could perl a FIRS client in one week prooves ho >>cheap it can be to deploy FIRS. I know it is a long way from proof of >>concept to production service, but what makes you think this path is >>shorter with XML? >> > > > Speaking as somebody who has put together both types of systems (Pimmit > - IRIS -00 and draft-newton-ldap-whois-03.txt*), I can tell you that > LDAP offered no speed of implementation or ease of deployment advantages. > > * draft-newton-ldap-whois-03 is not as far reaching as FIRS. > > -andy > > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From hardie at qualcomm.com Mon Jul 28 12:31:37 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Mon Jul 28 14:31:55 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F25654A.3020205@ehsco.com> References: <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F253B85.2040805@ehsco.com> <3F255D6B.9000102@ecotroph.net> <3F25654A.3020205@ehsco.com> Message-ID: During the meeting in Vienna, we discussed a set of next steps for the protocol evaluation, and the first of these was the development of a document that described the "relay bag" work that would need to be done for LDAP to enable FIRS. Peter Gietz and Eric Hall have the pen(s) on that document. I believe having that document is a necessary step along the way to assessing which of the two proposals will go forward as it speaks to complexity on the FIRS side. Having that work as early as possible will help all of us, and I'd like to encourage the authors along those lines. If people would like to discuss the extensibility of FIRS and IRIS in advance of that document, the list is certainly open for that. In general, though, I'd appreciate folks being careful in tone--the group has had a collegial approach to this problem space which has been very much appreciated. Keeping that approach will help us achieve consensus; please resist using terms and arguments which are derogatory to others. I also believe that we have already achieved consensus that neither approach allows us to use unmodified existing clients or servers. In the IRIS case, it is clear that the protocol is a new creation and will require appropriate development of clients and servers (albeit using tools which are readily available). In the FIRS case, it is clear that we are getting the heritage of LDAP as a protocol (both for good and ill), but that development of modified clients and servers (or schemas) appropriate to FIRS will also be required. Arguing this point does not seem to advance us along the road to resolution, since it has already been agreed. Thanks to all of you for your work and professionalism, regards, Ted Hardie From edlewis at arin.net Wed Jul 30 23:15:35 2003 From: edlewis at arin.net (Edward Lewis) Date: Wed Jul 30 22:28:27 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F21DC93.2080003@ehsco.com> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <3F21DC93.2080003@ehsco.com> Message-ID: Regarding Ted's note - I do feel a bit guilty about making this thread seem antagonistic. My intent is to fill in a huge blind spot (LDAP) in my knowledge. Frankly I (and this is just my history) haven't seen anything come of LDAP in the many years I have know of it's existence. (That would date back to at least 1995.) This message is in the context of my being ignorant about LDAP's deployment. I'm not saying the LDAP is garbage, I'm saying that I am unaware of it's advances. Given that background I have a question and a comment to this. At 20:42 -0500 7/25/03, Eric A. Hall wrote: >It may be cheaper for >delegation operators to reuse the provreg stuff ..., but for the average >user the initial cost won't have already been underwritten. I'm asking out of my pure ignorance. Why would a client-side user want to integrate the responses from the CRISP protocol in a something that's built on LDAP? I apologize that this may seem like an indictment, but I'm asking in the spirit of "I really can't imagine how/why." (I'm not discounting that LDAP can do this, I just don't see why.) >Then we get into the real meaty stuff, like the number of RFCs that have >gone into LDAP, I coming from a long term relationship with DNSSEC. (;() There are quite a few RFCs on that subject, but to date it is not useable. I don't think that the number of RFCs is a measure of anything quite frankly. My point is that a lot of work has gone into LDAP and I know of the work, but I am ignorant of where LDAP is applied in spite of all the work. (Much to the same extent of PKIX work - a lot of energy and still a lot of frustration in seeing it adopted.) >Really what the favoritism towards IRIS boils down to is a preference for >convenience. Granted - but the "favoritism" is the bias expressed by *A FEW* folks that are on the registry side of the game. Perhaps I was a bit too definitive in making *my* statement in favor of IRIS (at this time, I should add), but I wanted to make it clear. I anticipated one of two outcomes - either the FIRS proponents would lay down their pens and grant the title to IRIS (YES, I AM JOKING!) or FIRS proponents would let me know what I am missing about the FIRS advantages. I have been known to be someone who switches sides in arguments of this (IRIS v FIRS) nature based on what I learn. Right now I see advantages favoring IRIS but this may only be because I am stupid about FIRS or LDAP. So, to this end I would appreciate hearing how FIRS is more extensible for the client (and/or server) side - not just that it is because of the LDAP legacy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... From ehall at ehsco.com Thu Jul 31 00:58:46 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Jul 31 00:58:54 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <3F21DC93.2080003@ehsco.com> Message-ID: <3F28A206.5090700@ehsco.com> on 7/30/2003 9:15 PM Edward Lewis wrote: > Regarding Ted's note - I do feel a bit guilty about making this > thread seem antagonistic. It isn't antagonistic; it's adversarial, as it should be. Let's not be afraid to question each other's assumptions. For the record, FIRS would not be on the table without the support and effort of Andy Newton and Mark Kosters in particular. > I'm asking out of my pure ignorance. Why would a client-side user > want to integrate the responses from the CRISP protocol in a > something that's built on LDAP? I'm actually thinking about more than that, where users would not limit themselves to reusing the data but would want to provide their own CRISP servers, services and data. I'll get back to this in a moment, but let me diverge first. CRISP is about providing a directory service, by definition and by operational character. It's a read-mostly distributed database service, providing lookup-by-name and search-by-value functions, structured answer sets, and so forth. WHOIS was intended as a directory, the IRIS specs use the term freely, and LDAP is what it is, so by every interpretation we're building a directory service of Internet resources, regardless of how comfortable anybody actually is with that. We've avoided focusing on this point and that was a good thing, imo, since we've also avoided a lot of undesirable participants, but we're at the point where we need to realize what it means and deal with it. The central issue is scope. Do we just want it to be a WHOIS replacement for the same providers, or do we want to want to encourage broad and deep usage within the Internet community. In my opinion, the latter is unavoidable in the absence of purposeful design limitations being architected into the system, which is something we probably aren't going to do. This leads to the conclusion that failing to encourage the inevitable is a fundamental error, since we're only going to be guaranteeing eventual frustration. As proof of this point -- and to answer your question -- look at how WHOIS data is already being used today, for starters. Anti-spam tools, network management tools, logfile analyzers, and a slew of other products are already tapping into WHOIS data even in it's brutal current form. We can guarantee that this same level of usage willl be picked up for the new system, at the very least. What's even more likely is that the technology will get pulled into a bunch more products, either along similar lines or by extending other tools. I mean, it's not that hard to imagine that traceroute programs are going to start using the baseline data, or that (God help us) automated complaint generators are going to use it, etc. What will follow is also fairly predictable, since it also happened with WHOIS, which is that people will want to start building layered services on top of the baseline data. We saw this not only with the long-ago expansion into data for non-human resources, but also with the more-recent expansion into RPSL. It seems obvious to me that once people discover a federated namespace with ACLs, structured queries and answers, and all, that this expansion will accelerate, with people wanting to provide all kinds of resources. For an idea of the kinds of data that I'm talking about, think about the types of data that have been proposed for DNS but which are rejected due to incompatibilies or concerns with DNS. Certificate stores, public keys for applications and services, whitelists, email filters, personal contact data, etc. There is already a demonstrated desire for this stuff but nowhere to put it, and what we are providing is indistinguishable from a perfect place to put it (unless it is designed not to, as mentioned). For years we've been telling people "use something else" and by golly, this *is* that something else. The fact that the initial database will be populated with the most useful resources -- domains, IP addressing blocks, and contacts -- is going to be bacon on the bait. This is why I'm saying that the registry data is just a part of the big picture. It's arguably the most important part of the picture, but in the end I don't think it will represent the majority of the data in the total system. And since I think this balance is unavoidable, I think we should be focusing on making sure it goes well. > I coming from a long term relationship with DNSSEC. (;() There are > quite a few RFCs on that subject, but to date it is not useable. I > don't think that the number of RFCs is a measure of anything quite > frankly. My point is that a lot of work has gone into LDAP and I > know of the work, but I am ignorant of where LDAP is applied in spite > of all the work. I agree with this indictment, but I don't think there is much in the LDAP RFC series that equates with that. Most of the specifications are schema definitions and protocol extensions, and is used to illustrate the point that this same level of crack-filling will also be necessary. > (Much to the same extent of PKIX work - a lot of energy and still a > lot of frustration in seeing it adopted.) Nowhere to put it. Yet. What's been missing is the mesh of servers. Once the domain and IP addressing delegation data goes into CRISP, these problems will at least be partially resolved (depending on the degree that the providers recognize that they are already in the directory business and begin offering the layered data as a value-add to their customers, or if it gets left to third-party providers to plug in as layered services). > I have been known to be someone who switches sides in arguments of > this (IRIS v FIRS) nature based on what I learn. Right now I see > advantages favoring IRIS but this may only be because I am stupid > about FIRS or LDAP. So, to this end I would appreciate hearing how > FIRS is more extensible for the client (and/or server) side - not > just that it is because of the LDAP legacy. The candidates are relatively equal as far as the technology parts go, Andy and I already privately agreed to that. The advantage to FIRS is in time-to-deployment, especially as you get towards the edge of the service. LDAP servers are bundled into Win2k, Solaris, Linux, NetWare, and several other common operating systems. LDAP clients are already provided with authentication systems, email clients, web engines (eg, PHP and ColdFusion), and bundled as libraries for most development languages. The LDAP technology already provides integated database, protocol, authentication, and ACL technologies. The service is understood and supported by a large number of vendors, and is provent to be extremely scalable. Simply put, if I want to write a client agent that does CRISP lookups (or does some layered service lookup) then FIRS is easier. Likewise, if I want to provide a new layered service as a leaf-node in the Internet directory, then FIRS is easier there too, and has the known properties of scalability, reliability and support. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Thu Jul 31 18:25:32 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Jul 31 17:00:56 2003 Subject: [Ietf-not43] test Message-ID: <3F29894C.5090307@ecotroph.net> please do not respond. From Michael.Dillon at radianz.com Thu Jul 31 17:33:20 2003 From: Michael.Dillon at radianz.com (Michael.Dillon@radianz.com) Date: Thu Jul 31 17:06:37 2003 Subject: [Ietf-not43] extensibility Message-ID: >This message is in the context of my being ignorant about LDAP's >deployment. I'm not saying the LDAP is garbage, I'm saying that I am >unaware of it's advances. Given that background ... Well, let's get that background up to date. First some universities that have replaced their internal whois directory with LDAP directories. Read through the entire pages because there is a lot of useful background that is mentioned here. http://www.uwo.ca/its/projects/ldap_phaseI.html http://www.stanford.edu/group/dcg/pdd/projects/dirlookup/dir_require.htm Next, naming. A lot of LDAP directories and directory tools have different names so you won't know that they are based on LDAP until you dig deeper. For instance, Microsoft calls their version Active Directory and Novell calls theirs Novell Directory Service. On Solaris it's the Sun ONE Directory Server. If you browse through some books on these topics in the bookstore you'll see that they are all just LDAP with some specific schemas and architecture. Also, since the early LDAP standards didn't include things like replication, these directory services all built their own extras. Note that it is possible to take something like OpenLDAP and make it work in a SunONE or Microsoft AD environment with the right schemas http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-GILSchemaExtension.html Or maybe you'd prefer to have a calendaring system integrated with LDAP? http://www.steltor.com/notes/corptime-server/5_1/refmanual/refappe.htm#1046875 Or maybe you just want to use it to manage DNS zone files? http://ldap2dns.tiscover.com/ Because LDAP is part of the plumbing of a directory service, it sometimes gets bundled together with other stuff that looks like a directory service, for instance JNDI is the Java Naming and Directory Interface. This allows a Java developer to use things like LDAP, DNS or NIS without needing to know the details of the individual protocols. LDAP is used as a fundamental component of the worldwide datagrid used for their Monitoring and Discovery Service. This is the system that allows researchers to ship data to computers around the world and solve problems as if they have a gigantic supercomputer array of their own. They use a patched version of OpenLDAP. They've also published some benchmarks to show how scalable LDAP is. http://www.globus.org/testing/dmark_results.html LDAP is also part of the core "best practices" that the NSF is promoting to its audience of research institutes and universities. Again, they don't say "LDAP" because it's just part of the middleware plumbing. http://www.nsf-middleware.org/ Much of this comes out of the Internet2 middleware initiative. http://middleware.internet2.edu/ http://www.georgetown.edu/giia/internet2/ldap-recipe/ Wait a minute, isn't middleware just another term for those Message Queuing systems like MQSeries, MSMQ and TIB/Rendezvous? Yep, right you are. And LDAP is being used here as well http://support.sas.com/rnd/itech/doc/messageq/common/index.html This is the Enterprise version of gluing apps together... So, the conclusion is that LDAP is widely used in industry and academia, is available in many implementations and is widely documented in books and on the web. There are also lots and lots of IT professionals who have LDAP-related skills (either programming or running servers) so that companies can actually hire people with experience to build anything they need for CRISP's LDAP directory. Oops, I forgot, we gave LDAP a new name too. I meant to say FIRS. Admittedly, XML has many of the same advantages, however the halo of activity around XML is related to things other than building and running directory services. Since CRISP is fundamentally a directory service, it will be easier to implement if people use FIRS because then they get to leverage the halo of activity around LDAP. BTW, if someone finds a need to use an XML-RPC or a SOAP interface to get at the FIRS service, I'm sure that it would be a trivial programming exercise to make a FIRS client that is an XML-RPC or SOAP service. I suspect that the IRIS work will be more useful if it is refocused into providing a SOAP interface to an underlying FIRS service. --Michael Dillon From April.Marine at nominum.com Thu Jul 31 16:07:26 2003 From: April.Marine at nominum.com (April Marine) Date: Thu Jul 31 18:07:30 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <3F28A206.5090700@ehsco.com> References: <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <3F21DC93.2080003@ehsco.com> <3F28A206.5090700@ehsco.com> Message-ID: <20030731145342.H22502@shell-ng.nominum.com> Hello, On Wed, 30 Jul 2003, Eric A. Hall wrote: > ... > The central issue is scope. Do we just want it to be a WHOIS replacement > ... The possible potential use of the protocol chosen by CRISP is an interesting topic, but not one that determines which protocol the group chooses. The requirements for the protocol and the usage scenarios which it is required to address are documented and these form the bounds of how we proceed. So I agree with you that scope is an issue, but think we have to limit ourselves to the scope of the WG's charter, which was deliberately focused. As Ted said in his last msg: > During the meeting in Vienna, we discussed a set of next steps for the > protocol evaluation, and the first of these was the development of a > document that described the "relay bag" work that would need to be done > for LDAP to enable FIRS. Peter Gietz and Eric Hall have the pen(s) on > that document. I believe having that document is a necessary step > along the way to assessing which of the two proposals will go forward > as it speaks to complexity on the FIRS side. Having that work as early > as possible will help all of us, and I'd like to encourage the authors > along those lines. So let me be the stern co-chair and encourage us to get the possibly mundane but necessary work done so that we can come to closure in good time. thanks, April From Peter.Gietz at daasi.de Thu Jul 31 19:07:02 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Thu Jul 31 18:17:37 2003 Subject: [Ietf-not43] extensibility In-Reply-To: <5.2.0.9.2.20030728133230.03a39f90@shockey.us> References: <5.2.0.9.2.20030728102213.03642a60@shockey.us> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030717093955.0505b770@shockey.us> <3F16BF47.3010301@ehsco.com> <3F219DE1.2090306@ehsco.com> <5.2.0.9.2.20030728102213.03642a60@shockey.us> <5.2.0.9.2.20030728133230.03a39f90@shockey.us> Message-ID: <3F293EA6.8050705@daasi.de> Richard, some comments to your comments: Richard Shockey wrote: [...] >>> One way or another implementing these protocols will cost money and >>> my analysis concludes that IRIS will be simpler and less expensive. >> >> >> Is this really so? What makes you think so that a complete new >> implementation will be cheaper than using existing technology and do >> some tweaks to make it CRISP compliant? > > > Well as Andrew pointed out correctly, it seems obvious that a truly > stunning number of , dare I say it, "e-business" practices are moving to > a XML based architecture transported on FOO. The classic being SOAP may > of us have lots of experience with SOAP.... that PROVREG is going to > such a design that many TLD's will be contractually obligated ( Layer 9 > again) to implement means that I have to build a service platform to > support it ..If I can reuse that platform to implement CRISP, that is > economically a "good thing" Well I can see a point here. It made me think of an LDAP based implementation of it with an XML-interface. This would be possible, but would only make a proof that LDAP could have been used for provreg as well. It is far too late for such work now. > > >> Alone the fact that Eric could perl a FIRS client in one week prooves >> ho cheap it can be to deploy FIRS. I know it is a long way from proof >> of concept to production service, but what makes you think this path >> is shorter with XML? > > > I have no doubt it would be simple to implement FIRS ..is just that I > dont want to .. that means 2 platforms I have to support and the > registration data from PROVREG has to be converted...that is more work. > When I have to propose capital budgets for platforms that do this and > that the question is always raised ..." Well cant we reuse this box and > development time for that?" > BTW: CRISP and Provreg do differ in many respects. I am not too sure that much reuse is possible. > >> Are there existing XML data base technologiers that are as performant, >> scalable and secure as are LDAP implementations? > > > Yep... look at the APACHE SOAP stuff.. the bindings and transport are > easily adaptable. We in the IETF are generally opposed to the use of HTTP/S > transport for everything under the sun which is why BEEP was developed. > In fact the IESG has a directive specifically prohibiting the further > use of HTTP as a transport layer in IETF application protocols. If the > IETF weren't so opposed to SOAP on religious grounds we'd probably be > using that. And if I had to choose I'd prefer SOAP but I'm realistic > enough to know that is not going to happen. I think there are more than religious grounds to dislike SOAP, the major being that tunneling everything through port 80 just makes firewalls useless. Anyway IMO SOAP is a good thing (an old concept called RPC transformed into the new XML world), the usecases of it (Web Services) is just no IETF realm. BEEP is nice as well, but I haven't seen that really hit the market yet. Anyway, SOAP will not be it in IETF and the XML DB implementation in Apache Xindice is not comparable in its features with LDAP implementation. If you, e.g., look at XML:DB XUpdate, the protocol for making changes into the database you will find nothing about authentication, authorization, access control, etc. and neither do you find that in the Apache implementation. As to performance, I myself haven't made any XMLDB tests. I am aware of some XMLDB/LDAPDB performance testings done in the frame Grid computing by the globus toolkit team. That showed how slow XML databases are these days, which nevertheless didn't prevent them going the Web Services path (OGSA). The motivation might be: If the whole market is going this way, there will be fast implementations some day. Anyway, there are good arguments for XML just as there are for LDAP. For the present, I would say that the latter can fulfill its promisses now, while most of needed features in XML are rather vapor ware than existing in implementations. Cheers, Peter > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From hardie at qualcomm.com Thu Jul 31 16:52:28 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Thu Jul 31 18:52:37 2003 Subject: [Ietf-not43] extensibility In-Reply-To: References: Message-ID: Michael, This is a very interesting set of resources. Reading through them and matching them to my own experience (working through issues in LDAPBIS and LCUP), one of things that strikes me is the extent to which LDAP has become a substrate rather than an application-level protocol. LDAP is, as you note, the substrate for a very large number of directory service protocols. But these are not interoperating parts of a single directory service; they are independent services that do not share schema, often do not share encodings, comparators, or fundamental assumptions about how the pieces of LDAP work (viz. the recent discussion in LDAPBIS on whether a minimum supported attribute name length could be required at the protocol level or had to be schema-by-schema). Putting that in another way, no one currently expects the calendaring service client to talk to the GRID resource allocation service, despite the fact both applications may be built on the same substrate; it would be a bit like expecting them to interoperate just because both were built on IP. Where we cannot directly evaluate the differences between the proposed applications, the working group has to match the application specific needs of CRISP to the protocol substrate being used in the proposal. For that purpose we need to ask ourselves things like: how well does the data model match the data structures native to the substrate? how well do the needed comparators and functions match those native to the substrate? how well do the needed access control mechanisms match those native to the substrate? how well do the scaling characteristics match those needed? how well will referral mechanisms needed match those native the substrate? There are also two other, more delicate design questions in here. One is how to balance the baggage the substrate brings with the benefits it brings; that's a very tough one to approach rationally (and I've been impressed by the group on this point so far). LDAP as a protocol has loads of aspects that wouldn't be used by FIRS (data update mechanisms, for example, since this is a read-only service); XML as a substrate has expenses in bloat that may make it difficult to use over low-capability links. Those have to be considered without descending into religious wars, and that's not easy. The other tricky one is how to balance the needs of those providing the service with those consuming the service. That's tricky indeed, especially as we are presuming that new clients and new schema will be needed for either. But we have to consider it to do our job well. Thanks again for thinking on this and putting together the resources. regards, Ted Hardie > >Well, let's get that background up to date. > >First some universities that have replaced their internal whois directory >with LDAP directories. Read through the entire pages because there is a >lot of useful background that is mentioned here. > >http://www.uwo.ca/its/projects/ldap_phaseI.html >http://www.stanford.edu/group/dcg/pdd/projects/dirlookup/dir_require.htm > >Next, naming. A lot of LDAP directories and directory tools have different >names so you won't know that they are based on LDAP until you dig deeper. >For instance, Microsoft calls their version Active Directory and Novell >calls theirs Novell Directory Service. On Solaris it's the Sun ONE >Directory Server. If you browse through some books on these topics in the >bookstore you'll see that they are all just LDAP with some specific >schemas and architecture. Also, since the early LDAP standards didn't >include things like replication, these directory services all built their >own extras. > >Note that it is possible to take something like OpenLDAP and make it work >in a SunONE or Microsoft AD environment with the right schemas >http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-GILSchemaExtension.html >Or maybe you'd prefer to have a calendaring system integrated with LDAP? >http://www.steltor.com/notes/corptime-server/5_1/refmanual/refappe.htm#1046875 >Or maybe you just want to use it to manage DNS zone files? >http://ldap2dns.tiscover.com/ > >Because LDAP is part of the plumbing of a directory service, it sometimes >gets bundled together with other stuff that looks like a directory >service, for instance JNDI is the Java Naming and Directory Interface. >This allows a Java developer to use things like LDAP, DNS or NIS without >needing to know the details of the individual protocols. > >LDAP is used as a fundamental component of the worldwide datagrid used for >their Monitoring and Discovery Service. This is the system that allows >researchers to ship data to computers around the world and solve problems >as if they have a gigantic supercomputer array of their own. They use a >patched version of OpenLDAP. They've also published some benchmarks to >show how scalable LDAP is. >http://www.globus.org/testing/dmark_results.html > >LDAP is also part of the core "best practices" that the NSF is promoting >to its audience of research institutes and universities. Again, they don't >say "LDAP" because it's just part of the middleware plumbing. >http://www.nsf-middleware.org/ >Much of this comes out of the Internet2 middleware initiative. >http://middleware.internet2.edu/ >http://www.georgetown.edu/giia/internet2/ldap-recipe/ > >Wait a minute, isn't middleware just another term for those Message >Queuing systems like MQSeries, MSMQ and TIB/Rendezvous? Yep, right you >are. And LDAP is being used here as well >http://support.sas.com/rnd/itech/doc/messageq/common/index.html >This is the Enterprise version of gluing apps together... > >So, the conclusion is that LDAP is widely used in industry and academia, >is available in many implementations and is widely documented in books and >on the web. There are also lots and lots of IT professionals who have >LDAP-related skills (either programming or running servers) so that >companies can actually hire people with experience to build anything they >need for CRISP's LDAP directory. Oops, I forgot, we gave LDAP a new name >too. I meant to say FIRS. > >Admittedly, XML has many of the same advantages, however the halo of >activity around XML is related to things other than building and running >directory services. Since CRISP is fundamentally a directory service, it >will be easier to implement if people use FIRS because then they get to >leverage the halo of activity around LDAP. > >BTW, if someone finds a need to use an XML-RPC or a SOAP interface to get >at the FIRS service, I'm sure that it would be a trivial programming >exercise to make a FIRS client that is an XML-RPC or SOAP service. I >suspect that the IRIS work will be more useful if it is refocused into >providing a SOAP interface to an underlying FIRS service. > >--Michael Dillon > > > >_______________________________________________ >Ietf-not43 mailing list >Ietf-not43@lists.verisignlabs.com >https://lists.verisignlabs.com/mailman/listinfo/ietf-not43