directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Henne <>
Subject Re: LDAP schema for DHCP
Date Thu, 30 Mar 2006 07:46:08 GMT
Enrique Rodriguez schrieb:
> Jörg Henne wrote:
>> Enrique Rodriguez schrieb:
>>> I'm not surprised and I don't think any of us have any objection to 
>>> removing it.  If you'd like, we are interested in a well-designed 
>>> DHCP schema and we can allocate a range of OID.
>>> Enrique
>> *sigh*.
>> I don't really know whether this is where I want to go. In 
>> particular, I doubt that I'll be able to commit enough time to such a 
>> rather large-ish effort. I'm currently implementing a 
>> proof-of-concept, but working, DHCP server. To accomodate this, I'll 
>> probably use something like the unix DHCP configuration file format 
>> (or an XML file) first, but separate configuration storage from DHCP 
>> serving, allowing for different backend implementations.
> Well, maybe we can split this up.  I'm familiar with writing the 
> directory back-end, so I feel I can write that pretty efficiently.  
> What I don't have time for right now is re-learning/launching into a 
> big DHCP protocol workflow undertaking and it sounds like you are 
> beginning that.  You could, perhaps, design the store API and I could 
> work to directory back it.  You could start with file-based storage 
> (unix, XML) or even stub Java classes.  WDYT?
that sounds great!

WRT the discussion about basing the work on the proposed working draft 
for a DHCP schema:
yesterday I tried to understand how the schema is supposed to work and 
ended up feeling somehow uncomfortable with it. The reason for that is, 
that it seems awfully convoluted. In particular, I dislike the fact that 
about everything is held together by forward links (attributes holding 
DNs of related objects) instead of relying on container structures.

As an example: a host definition can be outfitted with options, i.e. 
parameters which are sent to a specific DHCP client while it acquires a 
lease. It would be quite simple to have a dhcpHost object which can have 
any number of dhcpOption children (or even simple dhcpOption attributes, 
since options can be stored quite comfortably in an attribute). Instead, 
as proposed in the working draft, the options need to be held inside a 
dhcpOptions (plural) object, which has to be pointed to by a 
dhcpOptionsDN in the dhcpHost entry. While this, theoretically, opens up 
the possibility to use shared options objects, it makes management and 
use of the data much harder, since all those links have to be maintained 
carefully. Furthermore sharing option objects isn't all that attractive, 
since there are already constructs defined for sharing of configuration 
information across a number of hosts, namely classes, pools and groups.

As the next steps, I think we should try to get in touch with the 
authors of the working draft (which, BTW, has long expired, accoring to 
IETF), in order to see whether there has been any progress since when it 
was published.

Joerg Henne

View raw message