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
