inetd Enhancements Followup

[James Browning <jamesbrowning137%gmail.com@localhost>]

Hello again NetBSD Community,

We have been carefully reading and considering all of your responses. Your
responses have all been very helpful for giving us a sense of how the community
would like to see these changes implemented (if at all). We want to make some
clarifying points and address some points of contention.

Regarding the change of configuration file syntax, we agree it would be a bad
decision to completely replace the existing syntax. If we were to add this new
xinetd-like syntax, it would be entirely optional and entirely backwards
compatible. If we are to follow the project description
(http://wiki.netbsd.org/projects/project/inetd-enhancements/), users will also
need a way to specify new per-service rate-limits (with the new rate-limits
TBD). We are not set in stone about adding this new syntax, for now we just
want to spark some discussions about the pros/cons of having a new backwards
compatible syntax.

For per-service configuration files, this again would be an entirely optional
feature. We think it will be best to keep the existing /etc/inetd.conf entirely
intact, and allow for fragmentation to be done by the administrators or package
maintainers at their own discretion. Some of you brought up the concern of
over-automating the system at the potential risk of the configuration system
becoming too opaque and administrators allowing packages to configure inetd
without their knowledge of what is happening. However, we believe that with
clear and detailed documentation, the addition of per-service config files
should have no reason to cause obfuscation for administrators. We hope that
with such documentation, administrators will have a thorough understanding of
how this fragmented configuration system will work, and as a result they can
manually make changes to config files added by new packages if they wish. This
change would not be anything different from how the rc.d system currently
works.

We appreciate your thoughtful responses to our proposed changes and understand
that reaching a consensus is difficult. With your continued feedback on
potential changes to inetd, we hope to make meaningful changes to inetd and
contribute our work to the NetBSD project.

Thank you again,
James Browning
Gabe Coffland
Alex Gavin
Solomon Ritzow