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
