Subject: [Ietf-not43] draft-hall-ldap-whois-00.txt

From: [email-masked] (Andrew Newton)
Date: Wed, 7 Nov 2001 14:39:03 -0500

Of interest to this group, Eric Hall has written the following
draft:

  draft-hall-ldap-whois-00.txt
  http://search.ietf.org/internet-drafts/draft-hall-ldap-whois-00.txt

The overwhelming response I have received privately has been "thorough".
It makes clever but regulated use of both DNS and LDAP to solve this
problem for both domains and IP addresses.

I believe it definitely raises the bar.

-andy

-- 
Andrew Newton
VeriSign Applied Research
[email-masked]

---

From: [email-masked] (Rick H Wesson)
Date: Wed, 7 Nov 2001 13:32:01 -0800 (PST)

Andrew,

impressive for an -00 draft. does this draft describe what is implemented
by your research department at ldap.research.netsol.com?

-rick

On Wed, 7 Nov 2001, Andrew Newton wrote:

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.research.netsol.com/mailman/listinfo/ietf-not43
>

---

From: [email-masked] (Andrew Newton)
Date: Wed, 7 Nov 2001 17:14:21 -0500

> by your research department at ldap.research.netsol.com?

Well, I like to think of it like this (and Eric can correct me):
  We piloted the Referral LDAP Service (RLDAP).
  Eric said, "That's a good idea, but if you do it this way it
  is even better."

So our pilot is not compatible with this draft.  That's not to
say we won't reshape our pilot.  We are mulling over those plans
now.  I think RLDAP was an important first step to understanding
the nature of the beast (LDAP in the context of whois data), and
that Eric's draft is a very well-engineered next step.

btw, the Referral LDAP Service is described in 
draft-newton-ldap-whois-00.txt.

-andy

---

From: [email-masked] (Stig Venaas)
Date: Fri, 30 Nov 2001 20:45:08 +0100

I've read most of the draft, and I rather like it. I like the idea of
a distributed WHOIS service that is closely tied to DNS.

Even though I like the draft, there are some parts I don't like, I've
got some questions, and I think parts of it are difficult to deploy.
I think some tweaking might be necessary to ease deployment, and I
guess transition needs more thought.

See the comments I've got so far below. All in all I think it's well
written and a very good fundament for further work.

Regards,

Stig Venaas
UNINETT

3.2.    Objectives 
        *   Distributed management. As part of the above, this document 
            also defines a delegated administrative model whereby data 
            that relates to a specific entity is managed and maintained 
            by that entity. A delegation body can provide delegation 
            data about a resource, while an operational body can 
            provide operational data about that resource, and the two 
            views are independently maintained as independent entries. 
            Moreover, organizations can leverage common security 
            mechanisms for the purpose of inter-organizational resource 
            management, such that a delegation entity can choose to 
            allow the operational entity to change the delegation data 
            independently, as required by the operational entity.

Sounds good, but can we really assume that all organizations that own
domain names, will participate in this? Maybe registrars can provide
necessary data on behalf of non-participating organizations?
      
     In short, the primary objective of this service is to facilitate a 
     distributed and highly structured WHOIS-like service. This is 
     achieved by using LDAP as a rich and highly structured 
     query/response transfer mechanism, using the existing DNS domain 
     delegation hierarchy for the purposes of a fast and lightweight 
     server-locator service, and using well-defined common schema for 
     the search inputs, answer data, and redirection mechanisms. This 
     approach satisfies all of the objectives stated above, and also 
     provides an extensible framework that allows for programmatic 
     queries regarding all types of network resources, including future 
     uses which are not defined in this document. 
      
Using LDAP and server records, one could first look for server records
in the relevant domain, and if non-existant look in the parent domain
and so on; and require that each TLD has a service record. The server
for the TLD could also have referrals to LDAP servers for delegated
domain owners or provide the data directly for those domain owners that
do not have their own LDAP service.

  4.1.    Namespace Example 
      
     Figure 1 below shows a subset example of the LDAP-WHOIS namespace, 
     which will be used throughout this document to illustrate many of 
     the concepts and mandates of this specification. Each of these 
     elements are described throughout the remainder of this document. 
      
     Figure 1: Namespace for Example Widgets' domain and network. 
      
     DIT: dc=example,dc=com 
       | 
       +-cn=inetResources,dc=example,dc=com 
         [inetResources object class] 
          | 
          +-attribute: o 
          | [inherited from inetResources] 
          | value: "Example Widgets, Inc." 
          | 
          +-attribute: inetSecurityContacts 
          | [inherited from inetResources] 
          | value: "ldap://example.com/cn=security, 
          |           ou=admins,dc=example,dc=com" 
          | 
          +-cn=example.com,cn=inetResources,dc=example,dc=com 
          | [inetDnsDomain object class] 
          |   | 
          |   +-attribute: inetDnsContacts 
          |     [inherited from inetDnsDomain] 
          |     value: "ldap://example.com/cn=hostmaster, 
          |               ou=admins,dc=example,dc=com" 
          | 

I think I got this, but let me ask to make sure. The information
for a given domain "labeln. ... .label2.label1." should always
be located below
dc=inetResources,dc=labeln,...,dc=label2,dc=label1
right?

Should a DNS SRV record in the zone "labeln. ... .label2.label1."
be required? I don't think this is realistic, maybe a SHOULD for
all but the TLDs which should be a MUST. It's hard to get people
to administrate DNS correctly today, for instance PTR records are
often wrong because things mostly work anyway. If people don't
have or have wrong SRV records, they won't notice, except that
others can't find information about them.

  4.2.    The domainComponent LDAP hierarchy.       

An organization that owns the domain "labeln. ... .label2.label1.",
should in my opinion be authoritative for the DIT
dc=inetResources,dc=labeln,...,dc=label2,dc=label1
And ideally a given DN should be universally unique. Agree?
If an organization does not have an LDAP server of its own and
does not buy LDAP services from someone else, should a registry
then maintain contact data in some other LDAP server, and should
the naming then be the same as if it was stored in a server that
belongs to the organization?

     What this also means is that DNS SRV query operations can be 
     redirected to LDAP servers in a different DNS zone, which allows 
     LDAP servers outside of a DIT to be authoritative for a DIT, where 

Agree

  4.3.    The inetResources Container 
      
  4.4.    Resource-Specific Entries 
      
     This document defines four Internet resource types, and each of 
     these resource types have their own naming rules. However, each 
     resource type has a consistent naming principle, in that the 

  Hall & Newton           I-D Expires: May 2002              [page 13] 
  INTERNET-DRAFT      draft-hall-ldap-whois-00.txt       November 2001 

     specific managed resource has an RDN component which uniquely 
     identifies that explicit resource, with this RDN residing within 
     the inetResources container entry. 
      
     For example, an entry for the DNS domain resource type associated 
     with the "www.example.com" domain name might have a DN of 
     "cn=www.example.com,cn=inetResources,dc=example,dc=com". 
     Similarly, an IPv4 network resource type associated with the IPv4 
     network address of "192.0.2.0" might have a DN of 
     "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although the 
     exact naming syntax is different for each resource, the position 
     of the name within a DIT is predictable. 

Why do you insist on using cn here? Because of buggy clients?

  4.5.    Redirects and Referrals 
      
        *   The host identifier MUST specify a domain name which is 
            resolvable with a DNS SRV resource record lookup. 
      
        *   Port numbers SHOULD NOT be specified in the URL, and MUST 
            be ignored if they present (SRV resource records provide 
            port numbers for the servers associated with the queried 
            domain name). 

I don't think one can assume everyone to have DNS SRV records, it
would be useful to look up contacts when nameservers for the zone
can not be reached, and it would slow down the performance. So, I'm
a bit sceptic to this. The advantage I guess, is that the owner of
the domain can switch to another server without updating referrals
in servers administrated by others.

  5.      The LDAP-WHOIS Object Classes and Attributes 
      
        *   IPv4 address blocks. The inetIpv4Network object class is 
            also subordinate to the inetResources object class, and 
            provides attributes related to the management of IPv4 
            networks in particular. 
      
        *   IPv6 address blocks. The inetIpv6Network object class 
            provides summary data about IPv6 networks, similar to the 
            data provided by the inetIpv4Network object class. 

IPv4 and IPv6 are mostly similar. Why don't you use a common object-
class? The few attributes that are not common could either be optional
or you can have different classes for 4 and 6 that both inherit a common
inetIPNetwork class.

  5.3.1.  Naming syntax 
      
     The naming syntax for IPv4 network entries MUST follow the form of 
     "cn=<inetIpv4NetworkSyntax>,cn=inetResources,<dc-DIT>". Each IPv4 
     network address which is managed as a discrete LDAP-WHOIS network 

I think I would name this attribute inetIPv4Network or something similar
with the inetIpv4NetworkSyntax syntax.

  14.4.   Open Issues 
      
     The following issues require additional analysis: 
      
        *   inetIpv6Network entries will likely benefit from 
            certificate-related data, although the extent and nature of 
            this information (minimum requirements, preferred 
            attributes, pre-existing schema, etcetera) is currently 
            unknown by the authors. 

I think inetIPv4Network entries could benefit from that as well.
Why are you thinking of IPv6 in particular? Because IPsec is mandated?