On Tue, Jul 11, 2000 at 10:17:16PM -0400, John Hawkinson wrote:

> Code review can perfectly reasonably happen on tech-* lists, and I think
> is to be encouraged.

Moved to tech-userlevel.


> >1) Redundant prototypes have been removed.
> 
> Ideally that should be a seperate commit.

Okay. That's reasonable.


> Traditionally, the case of Program A writing using file-format 1, and
> program B using file-format 2 has been solved by using a conversation
> program (i.e. awk script).

That would be "e.g.", but, in any event, why maintain two configuration
files and force the admin in question to remember to use a tool to
keep them synchronized?


> Personally, I'd sao "No, it doesn't seem reasonable". But perhaps
> others feel differently -- did you get an upswell of unicast emails
> supporting the idea?

There was one post on tech-userlevel suggesting this as a possible
solution.


> In general, I do not think we want to *encourage* users to load
> their /etc/ethers file into their arp table. What would be a scenario
> where this is the right thing to do?

This could be the right thing to do in the case of a gateway-type machine
with one interface sitting on a potentially hostile network, where you
do not want your arp tables maliciously stuffed with incorrect entries.


> It seems like it could be an excellent way to cause your system to behave
> wrongly to no gain.

Arp(8) already provides the -f flag, which suggests that there might be
a need for users to load arp entries from a file. It would seem obvious
that the data in /etc/ethers would be exactly what should be loaded in
some cases. In my specific case, it's exactly what I want. The /etc/ethers
file is a general-purpose mapping of MAC addresses to host names. Not
making use of it for arp(8) would seem a bit silly.

-- 
   Mason Loring Bliss   mason@acheron.middleboro.ma.us              E w i g e
awake ? sleep : dream;  http://acheron.ne.mediaone.net  B l u m e n k r a f t