From owner-cvs-share  Sat Sep 14 19:12:50 1996
Return-Path: owner-cvs-share
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA24008
          for cvs-share-outgoing; Sat, 14 Sep 1996 19:12:50 -0700 (PDT)
Received: from veda.is (root@ubiq.veda.is [193.4.230.60])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA23993;
          Sat, 14 Sep 1996 19:12:18 -0700 (PDT)
Received: (from adam@localhost) by veda.is (8.7.5/8.7.3) id CAA00376; Sun, 15 Sep 1996 02:11:42 GMT
From: Adam David <adam@veda.is>
Message-Id: <199609150211.CAA00376@veda.is>
Subject: Re: cvs commit: src/share/doc/handbook firewalls.sgml
To: alex@fa.tdktca.com (Alex Nash)
Date: Sun, 15 Sep 1996 02:11:41 +0000 (GMT)
Cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org,
        cvs-share@freefall.freebsd.org
In-Reply-To: <Pine.BSF.3.91.960914183023.28485B-100000@fa.tdktca.com> from Alex Nash at "Sep 14, 96 06:59:12 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-cvs-share@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > >   Log:
> > >   Revert the description of -N to its original form.  It was right the
> > >   first time.
> > 
> > then why does the manpage point out that service names are not accepted as
> > valid port specifications, and why does the implementation explicitly reject
> > any attempt to specify a service by name instead of by number?
> 
> Because they're not, -N only affects the display of the ipfw chain.
> This is not clear from the man page, but given two conflicting pieces 
> of documentation, it's probably a wise idea to check the source than to 
> randomly choose which is right.

-N allows hostnames to be accepted as valid on the commandline, to be passed
to the resolver. I checked with the source and the binary.

> Your first tip off that something was wrong should have been when you 
> made these two changes (to fix something that was "clearly wrong"):
> 
> -<tag/-N/Resolve addresses and service names.
> +<tag/-N/Resolve addresses (but not service names).
> 
> -<tag/-N/Do not attempt to resolve given addresses.
> +<tag/-N/Attempt to resolve given addresses and service names.
> 
> Alex

Now I do not understand what you mean.

Anyway, the situation of the moment now is that the actual code when -N is
given resolves (on input) only hostnames, but on output it also resolves the
names of services. Output is produced both when listing the ipfw rules and
when setting them. (BTW, names of protocols are accepted whether -N is given
or not, and this seems to be the intended behaviour).

I suggest the following (or similar) change to firewalls.sgml in order to
reflect the actual implementation in the source (and the documentation in the
manpage, which is already in synch with the ipfw binary)....

[except now the manpage has been changed too]

-<tag/-N/Resolve addresses and service names.
+<tag/-N/Resolve addresses and service names. Note: service names are not
+permitted on the commandline, but instead the numeric port number must be
+specified.

BTW, the alias 'print' as an alternative to 'list' is not documented either.
Perhaps this is intentional (if list is a replacement for print, and if print
is retained solely for backwards compatibility).

Adam