NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: misc/39327

The following reply was made to PR misc/39327; it has been noted by GNATS.

From: "Martin S. Weber" <>
Subject: Re: misc/39327
Date: Fri, 22 May 2009 15:42:26 -0400

 On Fri, May 22, 2009 at 05:45:02PM +0000, Jukka Ruohonen wrote:
 > The following reply was made to PR misc/39327; it has been noted by GNATS.
 > From: Jukka Ruohonen <>
 > To:
 > Cc: 
 > Subject: Re: misc/39327
 > Date: Fri, 22 May 2009 20:39:55 +0300
 >  On Fri, May 22, 2009 at 01:14:03PM -0400, Martin S. Weber wrote:
 >  > 
 >  > That makes me think: There exists a mapping of domain parameters to
 >  > a set of usable protocol parameters. Look at protocols(5) (and thus
 >  > at /etc/protocols) to find out which. But /etc/protocols only documents
 >  > the possible protocols at all. Now if /etc/protocols had also a field
 >  > for the "communication domain in which communication is to take place",
 >  > there would be no doubt about usable protocols. Take "icmp 1 ICMP" for
 >  > instance. If it read "icmp 1 ICMP PF_INET" instead, it would be obvious
 >  > that icmp is not for PF_INET6. Actually even expanding the comment instead
 >  > of adding a new field to improve documentation on where this procotol 
 >  > "belongs" would improve the situation in my opinion.
 >  Sure, I understand now and think you are right. But then again, someone
 >  would need to push this to IANA. But note that there is a quite extensive
 >  list of RFCs and other references in /etc/protocols in case a reader really
 >  wonders if IPv4 ICMP can be used with IPv6, and so forth.
 Yeah that's true and I really like the rfc references from protocols. But
 it's always sort of true that if you read more you learn more... to me the
 direct usefulness of /etc/protocols would sufficiently increase if either
 another field with the symbolic name of the fitting 'domain' parameter for
 socket(2) would be added, or if that symbolic name would be added to the
 beginning of the comment in /etc/protocols. This augmented file then could
 be pushed to iana as an improvement request. That leaves some questions:
 - who does it? I don't think I have the expertise or fell home enough in
 the netbsd source code to dig up everything easily but if no one else will
 do it, I will ... sometime ...
 - another field or comment? Adding another field at the end shouldn't break
 functions reading out data line-wise and then field-wise, should it? that
 also would have the benefit of the data being (more easily) available to
 programs working with /etc/protocols (that ignore comments). Adding it in
 the comment would "only" make the information available to a human reader,
 but then again, that's the motivation for this PR - the human reader.
 - no matter the questions above, who would tap the IANA? I wonder if they
 accepted input from an individual "from outside" like me, but surely from
 an OS "vendor" or even better, some NetBSD "community member" that is
 directly involved with IANA?
 Given you (Jukka) agree that augmenting /etc/protocols makes sense, I
 think this PR should remain open until there are some answers on the above
 points, while still the "DARPA" part can safely be cut from the manpages.
 Thanks so far & regards,

Home | Main Index | Thread Index | Old Index