Subject: [Ietf-not43] call for consensus

From: April.Marine at nominum.com (April Marine)
Date: Mon Sep 8 16:31:56 2003

Howdy,

During the last CRISP face-to-face meeting, we discussed the urgency
of making a decision regarding the technical direction of the working
group. We agreed then and after to adhere to a time limit for
discussion of the current proposals after publication of the relay bag
mechanisms developed for FIRS. We have now passed the time limit, and
we, as chairs, are ready to present a call for consensus.

We wish to be clear about two things:

       1) silence will not be considered as supporting any
          case--explicit statements are required;

       2) the consensus call is specific to the application of the
          proposed protocols to the stated use case.

Based on these two points and the discussion and indications to date, the
chairs now ask all working group participants to provide a specific
response to the following question:

  "Shall IRIS or FIRS be the basis of further working group
  development of a query-response protocol for administrative
  data related to Internet infrastructure?"

The chairs will assess the responses received before September 16, 5 p.m.
PDT, and will declare consensus or indicate the next step to achieve
working group closure on this point by 5 p.m., September 19th, 2003.

regards,
April and Ted, Chairs

---

From: richard at shockey.us (Richard Shockey)
Date: Mon Sep 8 17:08:22 2003

>   data related to Internet infrastructure?"

IRIS.... for the reasons I previously posted. I have not changed my 
position one whit nor have I seen any arguments over the past few weeks to 
that weaken my convictions here.

It is increasingly clear that the direction the IESG has taken with domain 
name industry protocols is based on a non port 80 <sigh> XML query response 
mechanisms.  PROVREG being the other case in point.

I'm sufficiently satisfied that a client IRIS implementation meets A. the 
WG documented requirements B. whatever the domain name industry(s), and I 
might add the emerging Global ENUM system may need in the future.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: wessorh at ar.com (Rick Wesson)
Date: Mon Sep 8 20:33:27 2003

I'm for IRIS. I prefer XML and believe the potential for successful
development and deployment by other icann dns registrars is much higher
with IRIS than FIRS because registrars have been successful with XML and
the tools to develop implementations of IRIS seem capable.

While LDAP would have been nice it seems it will require large hammers to
make the square FIRS peg fit the round LDAP hole. Though registrars may
often attempt such endeavors they have had little success using their
hammers at all.

best,

-rick

On Mon, 8 Sep 2003, April Marine wrote:

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
>

---

From: pawal at blipp.com (Patrik Wallstrom)
Date: Tue Sep 9 03:42:39 2003

On Mon, 08 Sep 2003, April Marine wrote:

[...]
>   data related to Internet infrastructure?"

IRIS.

/speaking for the swedish DNS registry

-- 
patrik_wallstrom->foodfight->[email-masked]>+46-733173956
                `-> http://www.gnuheter.com/

---

From: fneves at registro.br (Frederico A C Neves)
Date: Tue Sep 9 07:31:10 2003

On Mon, Sep 08, 2003 at 01:31:52PM -0700, April Marine wrote:
...
>   data related to Internet infrastructure?"

IRIS

---

From: sanz at denic.de (Marcos Sanz/Denic)
Date: Tue Sep 9 08:47:08 2003

> data related to Internet infrastructure?"

I second Richard's and Rick's words and vote for IRIS.

Regards,
Marcos Sanz

---

From: ginny at arin.net (Ginny Listman)
Date: Tue Sep 9 11:35:22 2003

IRIS.

Ginny Listman
Director of Engineering
ARIN

---

From: kent at songbird.com ([email-masked])
Date: Tue Sep 9 12:55:50 2003

> >   data related to Internet infrastructure?"

Speaking for nobody but myself, I prefer IRIS

Kent

-- 
Kent Crispin                               "Be good, and you will be
[email-masked],[email-masked]         lonesome."
p: +1 310 823 9358  f: +1 310 823 8649               -- Mark Twain

---

From: william at completewhois.com (William Leibzon)
Date: Tue Sep 9 14:42:16 2003

>   data related to Internet infrastructure?"

Speaking only for myself - FIRS

Reasons: better search capabilities, based on existing well supported 
	 protocol - software is available and quicker adaption, proper 
	 hierchical data support, etc

I also think that in case we choose IRIS (XML seems to be everybody's 
favorite these days...) many may still choose to store their internal
whois data on LDAP servers (the data is almost entirely accessed for 
reading and structure of ldap servers is well suited for storing such
data). In that case exist FIRS drafts would be helpfull for software
developers creating their whois server software, it would also be 
usefull to have easy mapping from FIRS to IRIS.

On the other I also recognize that IRIS maybe more flexible when 
working with different database structures and especially when
data has to be built "on the fly" (for some of my own projects in 
fact it would be the case).

---
William Leibzon
Elan Networks,
Completewhois Project

---

From: wessorh at ar.com (Rick Wesson)
Date: Tue Sep 9 15:11:16 2003

> usefull to have easy mapping from FIRS to IRIS.

though i have installed some of icann registrar whois servers, i've never
used ldap for a production whois service backend. thought about it, yes,
and even tested out the ideas. to the best of my knowlege i do not know of
one LDAP backened whois service in production; this isn't to say one does
not exist -- but that the industry has not accepted the idea.

most of the new backend systems for servicing the :43 and :80 whois
requests are built on SQL and OORDBMS database systems.

-rick

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Sep 9 15:18:07 2003

on 9/9/2003 2:11 PM Rick Wesson wrote:

> i do not know of one LDAP backened whois service in production; this
> isn't to say one does not exist -- but that the industry has not
> accepted the idea.

The "industry" would accept a dead cat as long as it had been sprinkled
with XML pixie-dust.

> requests are built on SQL and OORDBMS database systems.

Interesting. General-purpose DB technology is optimized for writes, not
for reads. Another convenience pay-off I guess.

BTW, the schema attached to this message is all that's needed for FIRS.
This drops into any LDAP server, and as long as the naming and aliasing
mechanisms defined in the -04 drafts (still working) are used, the v3
firs.pl client will work immediately.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
-------------- next part --------------
#
# inetResources attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.1.2
	NAME 'inetLocalIdentifier'
	DESC 'Provider-specific identifier for this resource.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.1.3
	NAME 'inetResourceComments'
	DESC 'General comments about this entry.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.1.4
	NAME 'inetGeneralDisclaimer'
	DESC 'General disclaimer text regarding this data.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.1.5
	NAME 'inetGeneralContacts'
	DESC 'Contacts for general administrative issues.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.1.6
	NAME 'inetAbuseContacts'
	DESC 'Contacts for reporting abusive behavior or acceptable-use
	 policy violations.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.1.7
	NAME 'inetSecurityContacts'
	DESC 'Contacts for general security issues.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.1.8
	NAME 'inetTechContacts'
	DESC 'Contacts for general technical issues.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.1.1
	NAME 'inetResources'
	DESC 'The inetResources container for the FIRS service.'
	SUP top
	STRUCTURAL
	MAY ( cn $ inetLocalIdentifier $ o $ ou $ description $
	 inetResourceComments $ businessCategory $ telephoneNumber $
	 facsimileTelephoneNumber $ labeledURI $
	 preferredDeliveryMethod $ physicalDeliveryOfficeName $
	 postOfficeBox $ postalAddress $ postalCode $ street $ l $
	 st $ c $ inetAbuseContacts $ inetGeneralContacts $
	 inetSecurityContacts $ inetTechContacts $
	 inetGeneralDisclaimer ) )

#
# inetAssociatedResources attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.2.2
	NAME 'inetAssociatedAsNumbers'
	DESC 'Autonomous system numbers associated with this resource.'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

attributeType ( 1.3.6.1.4.1.7161.1.2.3
	NAME 'inetAssociatedContacts'
	DESC 'Other contacts associated with this Internet resource.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.2.4
	NAME 'inetAssociatedDnsDomains'
	DESC 'DNS domains associated with this Internet resource.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.2.5
	NAME 'inetAssociatedIpv4Networks'
	DESC 'IPv4 networks associated with this Internet resource.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.2.6
	NAME 'inetAssociatedIpv6Networks'
	DESC 'IPv6 networks associated with this entry.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.2.1
	NAME 'inetAssociatedResources'
	DESC 'Internet resources associated with this resource.'
	SUP top
	AUXILIARY
	MAY ( inetAssociatedContacts $ inetAssociatedDnsDomains $
	 inetAssociatedIpv4Networks $ inetAssociatedIpv6Networks $
	 inetAssociatedAsNumbers ) )

#
# inetAsNumber attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.7.2
	NAME ('iAsn' 'inetAsNumber')
	DESC 'An autonomous system.'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.7.3
	NAME 'inetAsnDelegationDate'
	DESC 'Date this AS number was delegated.'
	EQUALITY generalizedTimeMatch
	ORDERING generalizedTimeOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.7.4
	NAME 'inetAsnDelegationStatus'
	DESC 'Delegation status for this autonomous system number.'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2}
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.7.5
	NAME 'inetAsnRegistrar'
	DESC 'Registrar who delegated this autonomous system number.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.7.6
	NAME 'inetAsnRegistry'
	DESC 'Registry where this autonomous system number is managed.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.7.7
	NAME 'inetAsnContacts'
	DESC 'Contacts for general issues concerning this autonomous system.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.7.8
	NAME 'inetAsnRoutingContacts'
	DESC 'Contacts for routing-related issues with this autonomous
	 system.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.7.1
	NAME 'inetAsNumber'
	DESC 'Autonomous system attributes.'
	SUP inetResources
	STRUCTURAL
	MUST ( iAsn )
	MAY ( inetAsnDelegationStatus $ inetAsnDelegationDate $
	 inetAsnRegistrar $ inetAsnRegistry $ inetAsnContacts $
	 inetAsnRoutingContacts ) )

#
# inetDnsDomain attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.3.2
	NAME ('iDom' 'inetDnsDomain')
	DESC 'A DNS domain name.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.3.3
	NAME 'inetDnsDelegationDate'
	DESC 'Date this DNS domain name was delegated.'
	EQUALITY generalizedTimeMatch
	ORDERING generalizedTimeOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.3.4
	NAME 'inetDnsDelegationStatus'
	DESC 'Delegation status of this domain name.'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2}
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.3.5
	NAME 'inetDnsRegistrar'
	DESC 'Registrar who delegated this domain name.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.3.6
	NAME 'inetDnsRegistry'
	DESC 'Registry where this domain name is managed.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.3.7
	NAME 'inetDnsAuthServers'
	DESC 'Authoritative DNS servers for this domain name.'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

attributeType ( 1.3.6.1.4.1.7161.1.3.8
	NAME 'inetDnsContacts'
	DESC 'Contacts for general issues concerning this domain name.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.3.1
	NAME 'inetDnsDomain'
	DESC 'DNS domain attributes.'
	SUP inetResources
	STRUCTURAL
	MUST ( iDom )
	MAY ( inetDnsDelegationStatus $ inetDnsDelegationDate $
	 inetDnsRegistrar $ inetDnsRegistry $ inetDnsAuthServers $
	 inetDnsContacts ) )

#
# inetDnsAuthDomainsHost attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.3.102
	NAME 'inetDnsAuthDomains'
	DESC 'DNS domains that this host is authorized to serve.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.3.101
	NAME 'inetDnsAuthDomainsHost'
	DESC 'DNS domains that this host is authorized to serve.'
	SUP top
	AUXILIARY
	MAY ( inetDnsAuthDomains ) )

#
# inetIpv4Network attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.5.2
	NAME ('ipv4' 'inetIpv4Network')
	DESC 'An IPv4 address block.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.5.3
	NAME 'inetIpv4DelegationDate'
	DESC 'Date this IPv4 address block was delegated.'
	EQUALITY generalizedTimeMatch
	ORDERING generalizedTimeOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.5.4
	NAME 'inetIpv4DelegationStatus'
	DESC 'Delegation status of this IPv4 address block.'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2}
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.5.5
	NAME 'inetIpv4Registrar'
	DESC 'Registrar who delegated this IPv4 address block.'
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.5.6
	NAME 'inetIpv4Registry'
	DESC 'Registry where this IPv4 address block is managed.'
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.5.7 
	NAME 'inetIpv4ParentNetworks' 
	DESC 'Parent networks of this address block.' 
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
      
attributeType ( 1.3.6.1.4.1.7161.1.5.8 
	NAME 'inetIpv4SiblingNetworks' 
	DESC 'Sibling networks to this address block.'
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
      
attributeType ( 1.3.6.1.4.1.7161.1.5.9 
	NAME 'inetIpv4ChildNetworks' 
	DESC 'Child networks under this address block.'
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.5.10
	NAME 'inetIpv4Contacts'
	DESC 'Contacts for general issues concerning this address block.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.5.11
	NAME 'inetIpv4RoutingContacts'
	DESC 'Contacts for routing-related issues with this address block.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.5.1
	NAME 'inetIpv4Network'
	DESC 'IPv4 network attributes.'
	SUP inetResources
	STRUCTURAL
	MUST ( ipv4 )
	MAY ( inetIpv4DelegationStatus $ inetIpv4DelegationDate $
	 inetIpv4Registrar $ inetIpv4Registry $ inetIpv4Contacts $
	 inetIpv4RoutingContacts $ inetIpv4ParentNetworks $ 
	 inetIpv4SiblingNetworks $ inetIpv4ChildNetworks ) )

#
# inetIpv6Network attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.6.2
	NAME ('ipv6' 'inetIpv6Network')
	DESC 'An IPv6 address block.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.6.3
	NAME 'inetIpv6DelegationDate'
	DESC 'Date this IPv6 address block was delegated.'
	EQUALITY generalizedTimeMatch
	ORDERING generalizedTimeOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.6.4
	NAME 'inetIpv6DelegationStatus'
	DESC 'Delegation status of this address block.'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2}
	SINGLE-VALUE )

attributeType ( 1.3.6.1.4.1.7161.1.6.5
	NAME 'inetIpv6Registrar'
	DESC 'Registrar who delegated this address block.'
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.6.6
	NAME 'inetIpv6Registry'
	DESC 'Registry where this address block is managed.'
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.6.7 
	NAME 'inetIpv6ParentNetworks' 
	DESC 'Parent networks of this address block.' 
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
      
attributeType ( 1.3.6.1.4.1.7161.1.6.8 
	NAME 'inetIpv6SiblingNetworks' 
	DESC 'Sibling networks to this address block.' 
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
      
attributeType ( 1.3.6.1.4.1.7161.1.6.9 
	NAME 'inetIpv6ChildNetworks' 
	DESC 'Child networks under this address block.' 
	EQUALITY caseIgnoreMatch 
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.6.10
	NAME 'inetIpv6Contacts'
	DESC 'Contacts for general issues concerning this address block.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributeType ( 1.3.6.1.4.1.7161.1.6.11
	NAME 'inetIpv6RoutingContacts'
	DESC 'Contacts for routing-related issues with this address block.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectClass ( 1.3.6.1.4.1.7161.1.6.1
	NAME 'inetIpv6Network'
	DESC 'IPv6 network attributes.'
	SUP inetResources
	STRUCTURAL
	MUST ( ipv6 )
	MAY ( inetIpv6DelegationStatus $ inetIpv6DelegationDate $
	 inetIpv6Registrar $ inetIpv6Registry $ inetIpv6Contacts $
	 inetIpv6RoutingContacts $ inetIpv6ParentNetworks $
	 inetIpv6SiblingNetworks $ inetIpv6ChildNetworks ) )

#
# inetPersonContact attributes and object class
#

attributeType ( 1.3.6.1.4.1.7161.1.4.2
	NAME ('iPer' 'inetPersonContact')
	DESC 'A person or role contact.'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

objectClass ( 1.3.6.1.4.1.7161.1.4.1
	NAME 'inetPersonContact'
	DESC 'Contact attributes.'
	SUP inetOrgPerson
	STRUCTURAL
	MUST ( iPer )
	MAY ( c ) )

---

From: hardie at qualcomm.com ([email-masked])
Date: Tue Sep 9 16:51:52 2003

>The "industry" would accept a dead cat as long as it had been sprinkled

I'd like to remind the working group that we are evaluating specific
proposals for a specific purpose.  Digressions into the generic
preferences for specific types of pixie dust are not in scope.  Discussions
of the use of specific back end services for other, related work
_may_ be in scope for the working group's evaluation, but
they should relate those discussions to specific proposals in a
concrete way.  I would appreciate them being discussed in a separate thread,
in any case, as this call for consensus is taking place after the
expiration of the time limit set for those discussions.
			regards,
				Ted Hardie

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Wed Sep 10 08:01:27 2003

[...]

>   data related to Internet infrastructure?"

Although I don't want to deny the merrits of the XML solution, I vote 
for FIRS for following reasons:

- Implementation of most of the FIRS specs is possible with standard 
LDAP-Servers, as Eric has shown in one of his last postings. Erics FIRS 
client implementation shows, how easy and with how little effort such is 
possible. This holds true not only for Perl, but for many other 
programking languages with LDAP libraries, such as C/C++, Java, PHP, 
Python,  JNDI, Java-Script. You can even access LDAP data via ODBC and ADSI.

- All features needed for a reliable and secure information service, 
such as distribution, replication, authentication (client and server), 
secure sockets, etc. are already there in the LDAP implementations.

- New CRISP specific features required in the future can very flexible 
be added to FIRS via LDAP inbuilt extension mechanisms. The draft on the 
relay bag feature may hold as an example for this flexibility.

- Having a dedicated LDAP port number, Integration of FIRS services into 
firewall protected networks will not open unwanted security holes.

- Via existing LDAP2Web gateways it is very easy to create nice and 
intuitive web based user interfaces.

- Via possible other Gateways you will be able to integrate the FIRS 
solution into other - non-LDAP worlds. Examples include XML based 
interfaces like DSML, XED (see draft-legg-xed-roadmap-01.txt) and even 
IRIS itself.

- A lot of data related to CRISP, like domain data and contact data have 
allready been successfully stored in LDAP based information systems. 
Even non-FIRS LDAP clients could make some use of a FIRS based crisp.

- The feature of read prioritization is ideal for information retrieval 
systems like crisp.

- besides criticism already rased against IRIS, I see another problem in 
the authentication mechanisms defined or better not defined. 
Authentication is delegated to the BEEP transport layer and there is 
only one authentication method specified, a default server 
authentication via TLS. AFAICS there is no client authentication 
specified at all. As to server authentication the specification will 
lead to interoperability problems, when it says in 6.1.:

> If a registry type does not explicitly define a server authentication
>    method, the default method is used (see Section 6.2.

This will most probably lead to a number of non standardized mechanisms 
that will not interoperate.

In LDAP there are a number of mandatory to implement authentication 
mechanisms besides the extensibility for SASL based methods.

- A more general remark on XML databases: It will take years untill 
native XML databases have reached the stability, performance and feature 
richness of LDAP server implementations.

Cheers,

Peter

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 T?bingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: richard at shockey.us (Richard Shockey)
Date: Wed Sep 10 09:58:49 2003

At 02:01 PM 9/10/2003 +0200, Peter Gietz wrote:

>- A more general remark on XML databases: It will take years untill native 
>XML databases have reached the stability, performance and feature richness 
>of LDAP server implementations.

Well Peter ... I'm not sure of that last item but let me point out 
something which Is tangential to the decision on consensus but I still 
submit is vitally important.

If you notice those folks who have, so far, expressed positive support for 
IRIS represent a reasonable cross section of the domain name/ TLD operator 
/ and RIR community...in other words we are the dogs that are going to have 
to eat the dog food here and our collective opinion should have some weight 
in the decision on what is and what is not consensus.

"Science Diet ..you try it!!"  sorry folks that's a US dog owner joke..

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 10 10:16:30 2003

on 9/10/2003 8:57 AM Richard Shockey wrote:

> If you notice those folks who have, so far, expressed positive support
> for IRIS represent a reasonable cross section of the domain name/ TLD
> operator / and RIR community...in other words we are the dogs that are
> going to have to eat the dog food here and our collective opinion
> should have some weight in the decision on what is and what is not
> consensus.

Eh, careful with the filters. To wit, the IETF does protocols, not
business cases, and I haven't heard anybody support IRIS on protocol
grounds yet (for that matter, the business cases have also been proven
false or highly questionable anyway).

Finish this sentence for me: "The lack of generalized query capabilities
in IRIS is superior to FIRS's combination of named and generalized query
syntaxes because..."  That's a filter you won't like.

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Wed Sep 10 10:29:43 2003

"...because generalized search services do not get deployed
with successful global interopration."

To wit, DNS is ragingly successful, LDAP whitepages directory is not.

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
     Yours to discover."
                                -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: edlewis at arin.net (Edward Lewis)
Date: Wed Sep 10 10:31:46 2003

>   data related to Internet infrastructure?"

I'd already responded privately to the chairs, but I may as well join 
in the public record:

IRIS.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Wed Sep 10 10:39:44 2003

> To wit, DNS is ragingly successful, LDAP whitepages directory is not.

This might hold true for a single world wide white pages information 
system envisioned in the X.500 days. But as a matter of fact LDAP is 
being deployed for, e.g. corporate white pages directories a lot and 
increasingly for user management and authentication services. It weren't 
technical reasons that the world wide service didn't hit the ground, 
rather organizational and reasons connected with privacy legislations.

Cheers,

Peter

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 10 10:46:04 2003

> To wit, DNS is ragingly successful, LDAP whitepages directory is not.

LDAP deployment has suffered from numerous problems, but the generalized
syntax is not one of them. The biggest problems have been with the
namespace, which is exactly why FIRS puts so much emphasis there. I would
also note the irony that IRIS puts little emphasis on namespaces.

If you want examples of successful generalized search syntaxes, look at
SQL, IMAP, and Google for that matter.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Wed Sep 10 10:52:23 2003

Richard Shockey wrote:

>> This will most probably lead to a number of non standardized 
>> mechanisms that will not interoperate.
>>
>> native XML databases have reached the stability, performance and 
>> feature richness of LDAP server implementations.
> 
> 
> 
> Well Peter ... I'm not sure of that last item 

Does this mean that you are fine with the 9 other items I put forward?

> but let me point out 
> going to have to eat the dog food here and our collective opinion should 
> have some weight in the decision on what is and what is not consensus.
> 

Since there are other advocators of FIRS, you cannot blame me of 
blocking concensus. I tried to summarize my arguments for LDAP  on 
technical grounds. As Eric stated already the arguments for IRIS are 
mostly on other levels than technical ones. The basic message I hear is 
"market trend is to use XML protocols so I want it inn crisp as well".

I don't think such arguments should not be the major base for an IETF 
consensus.

BTW: LDAP is a food, I am eating on a day to day basis and I still feel 
healthy and fine. :-)

Cheers,

Peter

Peter Gietz (CEO)

---

From: richard at shockey.us (Richard Shockey)
Date: Wed Sep 10 11:22:19 2003

At 04:51 PM 9/10/2003 +0200, Peter Gietz wrote:

>>but let me point out something which Is tangential to the decision on 
>>consensus but I still submit is vitally important.
>Since there are other advocators of FIRS, you cannot blame me of blocking 
>concensus.

In the TLD / domain name / RIR industry?  Who?

>I tried to summarize my arguments for LDAP  on technical grounds. As Eric 
>stated already the arguments for IRIS are mostly on other levels than 
>technical ones. The basic message I hear is "market trend is to use XML 
>protocols so I want it inn crisp as well".

well that is one of a number of useful arguments that I have used in making 
up my own mind... you seem to have ignored the other practical technical 
arguments against FIRS from Mr. Blacka among others.

>I don't think such arguments should not be the major base for an IETF 

Wrong,  you are speaking to someone that has to implement this and in a 
case as this such as this where, admittedly, both solutions in general meet 
the WG requirements many of us are forced into more subjective criterion in 
making our final judgements. That is a perfectly logical basis for seeking 
WG consensus.

I submit you and Eric are blocking consensus here ... and its time for the 
WG to move on and complete work on IRIS which IMHO has consensus support.

I've said my peace here..

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Wed Sep 10 11:46:06 2003

>>    method, the default method is used (see Section 6.2.

This is not correct.  Section 12 (security considerations) of the same 
document talks about the other SASL mechanisms.  In general, your 
description of the problem is an inaccurate representation of how BEEP 
works.  It supports the same SASL mechanisms that LDAP does.  Any 
criticism of them is equally transferable to LDAP.

So there is client authentication with SASL/OTP, SASL/PLAIN, 
SASL/DIGEST-MD5, etc....  As for specifying client authentication with 
TLS, I do not think that is proper for IRIS to specify as this will be 
up to the policy of each server.  And if LDAP does, then this is a 
serious problem with it.

> richness of LDAP server implementations.

This is, at best, speculation.  And it also ignores the major arguments 
of the people on this list that will be running these servers.

First, most of the "providers" that have been chastised on this list 
already have their own databases and set of business practices around 
these databases.  To insist they change to accomodate the LDAP protocol 
seems wrong.

Second, LDAP is a protocol and the LDAP implementations of it have no 
special sauce that make them uniquely better at storing data on a disk. 
  They simply reuse existing database technologies.  Many of the more 
popular LDAP servers simply use ldbm or some variant, like gdbm or 
sleepycat.  OpenLDAP prefers SleepyCat... but look, SleepyCat now does 
XML.  So that same robust, stable, and mature LDAP datastore is now 
available to IRIS (or anything else).  The point: it is a fallacy to say 
that a database is more stable, mature, etc... because it has LDAP in 
front of it.

Finally, the timeline for mature products can probably best be judged by 
mindshare.  There is no true scientific way to judge current mindshare, 
but I like to use the Amazon.com method: 'LDAP' (33), 'XML DATABASE' 
(48), and 'XML' (559).  With 10+ years of LDAP, you'd think there'd be 
more written about it, but there isn't.

-andy

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Wed Sep 10 11:57:32 2003

Eric A. Hall wrote:
> I would

Also, not true!  Just because its use of namespaces doesn't force a 
tree-view model of the data doesn't mean it doesn't use namespaces.

-andy

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Wed Sep 10 12:12:40 2003

Andrew Newton wrote:

> Peter Gietz wrote:
> 
>>
>> - besides criticism already rased against IRIS, I see another problem 
>> in the authentication mechanisms defined or better not defined. 

Apologies. I simply overread section 12 in my browser :-(

I take back this whole item.

> up to the policy of each server.  And if LDAP does, then this is a 

Well LDAP does describe a TLS based client authentication but not as 
mandatory to implement.

> that a database is more stable, mature, etc... because it has LDAP in 

There is a misunderstanding of my point. I am not so much concerned with 
the data base backend but with the features that are included in the net 
protocol.

On the LDAP side we have besides search, add, modify, etc. also inbuilt 
authentication (e.g. bind), distribution (e.g. referrals) and some 
implemented mechanisms for replication (e.g. Slurpd replication daemon 
that replicates via LDAP).

On the XML database side, we don't have it, since XML itself is just a 
data format and no protocol. On the XML query language side we have a 
number of candidates. And authentication is on the transport protocol side.

Here I think the distinction between several layers in IRIS is a con if 
the client authentication works on a completely different layer than the 
XML application. In LDAP it is IMO a nice feature that you can 
authenticate by binding to a node in the data tree.

But I concede these arguments are getting more and more aesthetical.

> more written about it, but there isn't.

This seems to me again the argument "let us do what is trendy". The use 
cases for XML is far greater than for LDAP so you cannot really compare 
these figures.

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 10 12:12:53 2003

> tree-view model of the data doesn't mean it doesn't use namespaces.

I didn't say that it didn't use a namespace -- the URI syntax is the
namespace, which is a separate complaint.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 10 12:16:43 2003

on 9/10/2003 10:22 AM Richard Shockey wrote:

> you seem to have ignored the other practical technical

This kind of conflation is not helpful. Mr. Blacka's comments regarding
his experience with LDAP were in reference to his design, not to FIRS.

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Wed Sep 10 12:33:41 2003

1/  Both sets of cited examples are about islands or standalone
    services -- not globally interoperable services.

2/  Yes, the whitepages problem was bitterly struck by privacy
    concerns -- note that they exist here, as well.  
    Note also that the whitepages effort was significantly
    hampered by failure to come to closure on a global
    "person object" (inetOrgPerson came after 5 years and
    a lot of attrition), and local servers providing their
    own variants of "person object" and related data -- supported
    (indeed, encouraged) by the flexibility inherent in the protocol.

Leslie.

--

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Wed Sep 10 12:35:54 2003

> that replicates via LDAP).

Adds and modifies are outside the scope of the work.  In fact, the 
organizations running these servers already have methods for 
provisioning of the data.  To be more to the point, if LDAP's add/modify 
verbs were part of the equation, some people on this list have already 
stated they would not use it because of that.  The simple fact of the 
matter is that public-facing Internet resource registries have different 
requirements than sub-network level/enterprise services... one of the 
big distinctions being the provisioning of data.

As for replication... if I already have a database, the chances are 
pretty good I already have methods for doing the replication.  Forcing a 
change to that is another negative.  BTW: many relational databases, 
etc... come with database level replication methods that are far faster 
than LDAP.

>> Finally, the timeline for mature products can probably best be judged 
>> by mindshare.  There is no true scientific way to judge current 
>> mindshare, but I like to use the Amazon.com method: 'LDAP' (33), 'XML 
>> DATABASE' (48), and 'XML' (559).  With 10+ years of LDAP, you'd think 
>> there'd be more written about it, but there isn't.
> 
> 

I agree that this is a "trendy" argument.  However, trendy does 
translate into real-world development and deployment when it comes time 
to find a programmer or sys admin, etc...

Additionally, perhaps the whole reason LDAP is being pushed is because 
it is trendy for enterprise-level directory services.  In 10+ years of 
LDAP, there has not been a successful Internet-wide deployment of it as 
a unified service (such as white-pages, the thing it was suppose to do). 
  Why force it on us now?  Why should we be the ones providing the 
"bacon" to get this 10 year old dream off the ground?

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 10 12:38:33 2003

>     services -- not globally interoperable services.

A generic search-by-value syntax in this application space would also be
restrained to single partitions. That's their value. Named searches are
needed for distributed lookups, while generalized syntaxes are needed for
targetted searches within a domain space.

Extensibility is the other related issue here: being able to define
additional named searches on-demand is another feature, and the
generalized search syntax provides a way to emulate those when they are
not available.

>     (indeed, encouraged) by the flexibility inherent in the protocol.

These are all valid, and were all considered in the FIRS design.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 10 12:41:28 2003

on 9/10/2003 12:05 PM Andrew Newton wrote:

> Adds and modifies are outside the scope of the work.

I agree that it is out-of-scope as-written. Part of this is also because
we explicitly chose not to look at 2LD and ISP requirements, where
modifies (at least) would be a requirement.

> To be more to the point, if LDAP's add/modify verbs were part of the
> equation, some people on this list have already stated they would not
> use it because of that.

This is akin to saying that they won't use HTTP because it has POST.

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Wed Sep 10 17:54:49 2003

>   data related to Internet infrastructure?"

I think people know that I support IRIS for the working group's
continued efforts, but I'd like to explain why.

Technical Reasons
-----------------

1/  The IRIS registry model is expressed in terms of the allowable
    query semantics, not the matching rules associated with 
    the data types of the individual object elements.   

That is, an IRIS registry is defined specifically in terms of "queries"
and "results", as is the definition of a global domain registry
information service.  This allows restrictions of the form
of "you can only find contact objects by providing the contact
name, not by asking for all contacts in a particular country".

My argument against infinite flexibility is that, to achieve
global deployment as a servICE, every client needs to know what
specific questions (queries) it should be able to ask of any server,
period.  It is also necessary for it to be obvious
to servER implementers what they have to implement; with
the expectation of generic queries, that is NOT at all
obvious.

The basic LDAP model is expressed in terms of data objects,
with attributes that have specific match semantics.  The
model is that you can therefore search on any subset of
those data attributes, combined with logical operands into
a vast array of possible queries -- infinite flexibility.

I recognize that FIRS combats that flexibility explosion through
the use of fixed controls/filters, but that's an added constraint
in the use of LDAP.  I.e., it goes against the grain of the basic
LDAP design model.  IMO, that means it is taking something that
is much larger than the solution we need (LDAP) and making it
bigger (additional filters) to try to make something smaller
(more focused). 

And, as long as those filters are optional, we're still left with 
an over-generalizable query language.  Even if 90% of the
FIRS servers return an error message for a query to find
a contact by a particular post office box number, we're
no better off than we are with today's whois service -- guessing
which servers answer which types of queries.

2/  The above implies that we need a different registry query 
    architecture, and hence protocol.  Once one has made that leap,
    one is looking for an encoding.  From that perspective, the
    value of XML in this equation is simply that it saves
    us from having yet-another-text-encoding-debate.  

Saying "we'll use XML" means we don't have to argue ad nauseum about 
how to express line breaks in the data v. linebreaks in the protocol, 
and other escaping wonderments.

(Do I sound scarred by the Whois++ experience?  Sorry, Patrik!).

So -- this is not "XML" v. "LDAP"; this is "XML" v. "MIME" or
"XML" v. "something entirely new".

3/  And what about reuse?

I've read Eric's arguments that FIRS can be implemented using
standard LDAP servers, by dropping the specialized filters as
a requirement.  What I don't hear is that *CRISP* can be implemented
using standard LDAP servers, or at least *only* CRISP (as defined
by a set of required queries and responses).  So I still don't
believe that you can take an off-the-shelf LDAP server and
stand up a credible CRISP servICE servER that won't be pushed
over by unreasonable queries across the space of CRISP-related
data objects.

So, to have a reasonable server solution to the CRISP task, I
believe you are still going to have to write code.

As for clients -- generic LDAP clients are not going to be aware
of how to handle the stringent naming requirements in FIRS.

So:  yes, code has to be written for IRIS.  And the XML parsing
is not the hard part.  The challenging part is getting the code
set to find the authoritative server (on the client side) and
provide the scoped search support (on the server side).

Oops.  That's exactly what (I argue) has to be adapted for
FIRS, so IRIS and FIRS are dead even on this one.

Except that IRIS doesn't have any pretensions or expectations
that there are existing clients/servers that will work.

4/  Extensibility 

I've argued above (and elsewhere) that flexibility is the
enemy of global service deployment.  That is not to say that
there is never any use for local extensibility.  IRIS
supports that dual perspective by constraining the DREG 
query/result definitions, and allowing extensions in the
form of new registries and new local objects (in the XML
rendering).  This maintains the global/local service split.

There are other technical issues I have with FIRS (e.g., 
use of SRV records, and LDAP naming), but I assume that
they could be discussed and worked out, so I don't count
them in the list of my reasons for "why IRIS".

Less Technical Reasons
----------------------

5/  What problem are we solving?

The IRIS/DREG proposal is geared to solve the problem as stated in
the WG's charter, and no other problem.   I believe that
gives it a higher probability of actually solving *that* problem,
while I'm concerned that the FIRS approach has a grand unifying
vision that is, in my opinion, in danger of eclipsing the 
task at hand, to the detriment of its solution to CRISP.

I think FIRS is an awesome effort, and has interesting
technical features in its use of LDAP.  I just don't think it's the
right answer to this WGs chartered problem. 

Leslie.

--

---

From: paf at cisco.com (Patrik Fältström)
Date: Wed Sep 10 22:27:07 2003

Summary: I support IRIS, and warn the group for choosing the LDAP path.

(I can do it now as I am not the AD anymore...but in this case a normal 
wg participant.)

It is not even the case I have "more positive feelings for IRIS". I 
even have negative feelings for LDAP due to things which go from the 
fact it is hard with ethereal to see what is going on in the protocol, 
via schema discovery issues to the hierarchal structure which is strict 
in LDAP  itself even if you have referrals in later versions of LDAP. 
We do not have a global LDAP deployment in the world for what I think 
are these reasons.

LDAP works extremely well in a closed environment where the same 
organisation (or cooperation of organisations) control all clients and 
servers, but to get LDAP to work globally one do have problems.

> (Do I sound scarred by the Whois++ experience?  Sorry, Patrik!).

No, you show experience from Whois++ which was so simple to implement 
and expand just because of the expandability where the LDAP 
schema-equivalence was not needed -- but on the other hand you remember 
the discussions between LDAP and Whois++ people as well as I.

> right answer to this WGs chartered problem.

I can not say it better myself.

     paf

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Sep 11 02:49:37 2003

on 9/10/2003 4:51 PM Leslie Daigle wrote:

> over by unreasonable queries across the space of CRISP-related

query for www.ex?mple.com using 0.04 firs.pl on goose:43, against an
off-the-shelf openldap server with no extensions:

------------------------------------------------------------------------
[Entry: iDom=com,cn=inetResources,dc=ntrg,dc=com]

         Domain Name: com

          Registrant: Internet Corporation for Assigned Names and Numbers
      Street Address: 4676 Admiralty Way,Suite 330
         City/Locale: Marina del Ray
     Postal/Zip Code: 92092
     State/Territory: CA
        Country Code: US
       External Info: http://www.icann.org/ ICANN

  Technical Contacts: [email-masked]
    General Contacts: [email-masked]

      Record Created: 2003-09-09
       Last Modified: 2003-09-09

------------------------------------------------------------------------
[Entry: iDom=ex?mple.com,cn=inetResources,dc=ntrg,dc=com]

         Domain Name: ex?mple.com
   Delegation Status: Assigned and active
     Delegation Date: 2003-04-01

    Auth DNS Servers: ns1.example.com [192.168.11.3/32],
                      ns1.ex?mple.com [192.168.12.4/32]

          Registrant: Ex?mple Widgets, AB
      Street Address: Drammensveien 18
         City/Locale: Oslo
     Postal/Zip Code: 0244
        Country Code: NO
       External Info: http://www.xn--exmple-cua.com/ Ex?mple Widgets

    General Contacts: info@ex?mple.com
  Technical Contacts: hostmaster@ex?mple.com
   Security Contacts: security@ex?mple.com,
                      [email-masked]

   Related IPv4 Nets: 192.168.12.0/24
     Related Domains: example.com
        Related ASNs: 65535

      Record Created: 2003-09-09
       Last Modified: 2003-09-09

-------------------------------------------------------------------------
[Entry: iDom=www.ex?mple.com,cn=inetResources,dc=ntrg,dc=com]

         Domain Name: www.ex?mple.com
    Alias for Domain: www.example.com

      Record Created: 2003-09-11
       Last Modified: 2003-09-11

There is only one feature missing, which is that automatic chasing of
continuation reference referrals doesn't work without the custom matching
filter. This means that the cn=ref1 child entry under www.ex?mple.com that
points to www.example.com wasn't matched by the client's use of equality
matching filters, and that the com->ex?mple.com->www.ex?mple.com tracking
wouldn't be automatic in a distributed environment.

That is admittedly a shortcoming for those usages which require it, but
it's the only shortcoming and it only applies to those usages. Adding a
single custom matching filter makes it go away. Other stuff like the
master control object is entirely optional to the protocol, but useful for
providers and clients alike.

Yes there is one piece of mandatory development effort which would be
disposed of as soon as the control were written (or at least as much as
the IRIS costs are ~disposed of by David's work). If not, then we have the
comparison of cost for ONE search gizmo next to the costs for building
everything else IN ADDITION TO a search gizmo. Some sites will have
additional (private) subordinate requirements to this, but that's not the
general or absolute case.

> the expectation of generic queries, that is NOT at all

There's nothing unpredictable about it. Servers are expected (but not
required) to provide the named queries, and clients are permitted to rely
on the presence of those queries. Servers are separately required to
support equality matching so that targeted lookups to specific entries at
specific partitions succeed (this is much more efficient use of server
processing than having clients always submit the named queries). Clients
may also take advantage of the mandatory equality matching to emulate any
missing named queries (this is also necessary for the development of
subsequent queries), but that is entirely at the client's discretion.
There's nothing unpredictable about this.

> a vast array of possible queries -- infinite flexibility.

That's a feature, not a bug.

> bigger (additional filters) to try to make something smaller

The "restraint" is at the operator's discretion, to be used as the
operator requires according to policy, server-load, or whatever. That's
also a feature, not a bug.

Whenever IRIS gets around to providing the generic searching features,
you'll need this restriction feature too for the exact same reasons.

> which servers answer which types of queries.

You've bundled multiple topics together, which have varying levels of
applicable truth to the issue.

First and foremost, the service doesn't provide a way to find a ~contact
somewhere in the universe by their PO Box, but instead provides global
locator services using a unique identifier (the key to the index).

Instead, search-by-value functionality is necessarily restricted to each
of the individual partitions. The availability of any partition-specific
searching will be determined by policy and management issues for each
operator, and isn't global. We covered this ground long ago, where places
like ~Sweden have laws which are different from other jurisdictions, and
where each operator has their own privacy policies, security concerns,
server load, or any other factors which cumulatively require that optional
searches be, umm, optional, on a per-server basis.

As we have also discussed multiple times, none of this means that ~Google
couldn't build a super-index of all servers or whatever, and in that
context, a search-by-value could be offered globally, according to the
capabilities of that super-index.

Finally, the master control object provides a way for clients to learn
about the capabilities of a particular server during the handshake, and
this knowledge can be used in numerous ways towards making advanced
searching simpler. For example, it can be used by the client to enable or
disable advanced search options whenever the client chooses to query a
specific partition. It can even be cached (and refreshed on the next
connect), to provide some sort of out-of-band indicator.

These are features not bugs.

Meanwhile, IRIS does not provide extended searches, nor does it provide
mechanisms for negotiating over the availability of any extended searches
(named or otherwise) on a per-partition or per-user basis. IRIS is
actually modal in this regard, in that "actors" such as law enforcement
will essentially have to use a separate protocol to perform advanced
searches, while FIRS can support those users through built-in features
("here's a userid with filter clearance"). This modality can also be seen
in the read-only area, where IRIS essentially requires that some other
protocol be used for maintenance, even if the managing organization (eg,
an ISP, or a corporate, where I know real-life examples of each that
already use LDAP everywhere internally) who would prefer to use a single
service. The inability (or actually, the refusal) to support any protocol
operations other than consensus queries makes IRIS excessively modal.
That's not a feature.

>     us from having yet-another-text-encoding-debate.  

I don't have any problems with XML. I've got other projects in the pipe
that use it, for example. I would even support an XML directory that
addressed many of LDAP's shortcomings. What I've got problems with are
one-dimensional arguments that focus on pixie-dust instead of mechanics.
I've also got a hard time supporting a service that doesn't addresss the
shortcomings. I mean, you're arguing that LDAP is too flexible, but
ignoring the fact that an extensible description language on top of a
modal database is antithetical towards making anything any simpler.
Similarly, LDAP is architected to favor fast-short pipes, using way too
many setup transactions, but IRIS' architects argue for adding more of
them rather than less.

This debate isn't about XML, not to me anyway, although I appear to be in
the minority on that point.

> rendering).  This maintains the global/local service split.

Please point to the text that describes the negotiation protocol.

> the WG's charter, and no other problem.

You mean the clarified charter. I've asked to have the "directory"
terminology struck, since we're no longer talking about directories, but
instead are narrowly focused on:

  a) query-only
  b) for specific attributes
  c) against TLD repositories
  d) and nothing else

IRIS is suitable for that, but it's not suitable beyond that. It's not
even suitable for the demands of all the actors listed in the requirements.

Frankly, if I'd known that's where this WG would end up, I wouldn't have
wasted my effort. An XWHOIS just isn't compelling work. There are probably
less than 10,000 people in the world who need that narrow service, versus
millions who have a demonstrable need for a distributed directory service
that is capable of storing and serving variable data associated with
network resources.

> I believe that

While it's true that CRISP would be just one of many uses of FIRS, that
doesn't equate with CRISP being unserved. On the contrary, domain and IP
delegation data would be crucial towards the success of layered service
data, and so would necessarily get primary preference.

> right answer to this WGs chartered problem. 

I appreciate the effort at outreach

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Thu Sep 11 12:58:44 2003

Eric,

It's perhaps worth noting that I addressed my comments to the
whole working group; I feel you've taken more personal responsibility
for them than is absolutely necessary.

As for your comments -- like most of our exchanges, this one
dies because we have irreconcilable differences of worldview.

This message is going out far shorter than it has been in 
various stages of editing; I can't find ways to constructively
respond that don't devolve into claims that my practical
deployment experience (Archie, Whois++, TISDAG, each of
which had lofty targets)  is at odds with your design goals,
and that's not something we're ever going to reconcile, and
there's just not a lot to talk about.

Leslie.

--

---

From: davidb at verisignlabs.com (David Blacka)
Date: Fri Sep 12 09:37:42 2003

> Please point to the text that describes the negotiation protocol.

I thought I would comment on this because it is somewhat clear to me
that *how* IRIS handles extensibility is not well understood from the
documents.

This negotiation process is really described in the core BEEP RFC
(3080), but I expect that one would have to draw some conclusions as
to how it applies to IRIS.

The IRIS beep mapping draft (draft-ietf-crisp-iris-beep-03) describes
how to map a particular version of IRIS and a particular version of a
registry type into a BEEP profile URI.  BEEP describes how, in the
initial exchange, client & server (or peers) tell each other what
profiles are available.  For instance, an IRIS client connecting to a
server could get the following initial handshake:

  <greeting>
     <profile uri="http://iana.org/beep/TLS" />
     <profile uri="http://iana.org/beep/SASL/DIGEST-MD5" />
     <profile uri="http://iana.org/beep/transient/crisp/iris1/dreg1"/>
     <profile uri="http://iana.org/beep/transient/crisp/iris1/dreg2"/>
     <profile uri="http://iana.org/beep/transient/crisp/iris1/areg1"/>
  </greeting>

Some of the profiles are what BEEP calls "tuning" profiles.  They are
called serially to "tune" the session.  The SASL profiles and TLS
profile are tuning profiles.  So far all of the known tuning profiles
are security related, either for authentication (the SASL profiles),
or for privacy (the TLS profile).

At this point, a client gets to *choose* what profile to use.  It does
so by trying to open a channel against a particular profile:

  <start number="1">
     <profile uri="http://iana.org/beep/SASL/DIGEST-MD5" />
  </start>

(I'm skipping the framing that BEEP does, as that isn't germaine).  In
this case, the client is trying to open a channel to authenticate
itself via SASL/DIGEST-MD5.

This whole step allows IRIS clients to negotiate with the server which
exact registry type it wants to deal with.  Now the different registry
types may, in fact, be totally different from each other.  Or one may
be a variation of another. Or one may be a different query interface
to the data served by another. At the protocol level, they are
entirely independent.

A client could be kinda stupid about this if it wants.  Lets say there
is dreg1 (the domain-based CRISP solution being developed at the
moment), and dreg2, a future version that adds new functionality.  A
client would probably want to use dreg2 normally, and dreg1 if it
isn't available.  It can either look at what the server has offered
and pick the profile that it wants, or it can ask for both and let the
server decide:

  Request:
  <start number="1">
     <profile uri="http://iana.org/beep/transient/crisp/iris1/dreg2"/>
     <profile uri="http://iana.org/beep/transient/crisp/iris1/dreg1"/>
  </start>

  Response:
  <profile uri="http://iana.org/beep/transient/crisp/iris1/dreg1" />

Note that, implementationally, these different profiles may actually
point to the same code and just use the profile URI as input as to
what schema to validate against.  This is, in fact, how my IRIS
implementation works in general.

Using this mechanism for feature negotiation is obviously pretty
coarse-grained (which I think is good, btw), but the IRIS core gives a
great deal of latitude to different registry types, so if a
finer-grained form of negotiation is really desired, it could be done
at the registry-type level.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: shane at ripe.net (Shane Kerr)
Date: Tue Sep 16 06:45:02 2003

> we, as chairs, are ready to present a call for consensus.

Back from vacation just in time to say:  IRIS.

;)

-- 
Shane Kerr
RIPE NCC