All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Lodal <simonl@parknet.dk>
To: Henrik Nordstrom <hno@marasystems.com>
Cc: Ben Efros <ben@xgendev.com>, netfilter-devel@lists.netfilter.org
Subject: Re: RFC: Partial IP4 syntax
Date: Wed, 29 Sep 2004 20:45:33 +0200	[thread overview]
Message-ID: <415B02CD.2080403@parknet.dk> (raw)
In-Reply-To: <Pine.LNX.4.61.0409291855130.15266@filer.marasystems.com>

Henrik Nordstrom skrev:
> I repead once again, introducing a new notation looking the same as an 
> older well established (even if depreated) notation but with a different 
> meaning is a terribly bad idea.

Agree, and I am trying to avoid it! By only adding previously unused syntax.

But I still feel that programs relying on undocumented, partly working 
features should know they are in trouble.


>> iptables -L is for human eyes while iptables-save is for machine 
>> parsing. So what if we make iptables -L print in any format it likes 
>> (not intended for machine parsing anyway), but have iptables-save 
>> always print addresses in full dotted quad?
> 
> Having iptables -L output anything else than quad dotted format is an 
> even worse idea. Why outputting any other notation than the official 
> standard?

Because iptables -nvL lines are already horribly long. Anything making 
them shorter is good for readability.

There is no point in trying to parse iptables -L output since all the 
modules already output random stuff in the right column. So we should 
rather try to make it more readable for humans.


>> The question is how to interpret a single number. Implicitly append or 
>> prepend a dot? Or interpret as full 32bit notation? Or ignore it?
> 
> Depends on if it is a CIDR number or not.

Requires backwards parsing? Not good.


> The following syntaxes I see as acceptable
> 
> 
> quad dotted IP, hex or dec

Hex in iptables -L output would cause more confusion and anger than my 
proposals, I believe.

Hex on input ok except noone uses it.


> N dotted IP (less than quad), hex or dec notation
> 
> CIDR notation
>   N octets (up to four) / masksize. Only decimal.
> 
>   10/8 == 10.0.0.0/8

In other mail you say 1/0.255.255.255 = 0.0.0.1/0.255.255.255, inconsistent?

Again question is: When address is only one number, is it interpreted as 
first or last octet, if any? (ie. append dot, prepend dot, or bark?)

Or do you really mean that:
cidr mask => interpret as first octet
dotted mask => interpret as last octet


> Mask notation
> 
>   quad or N dotted IP / netmask in quad or N dotted IP form. hex or dec.
> 
> To differentiate between CIDR and Mask notation when the mask is 
> specified using a single number use the <=32 magics.

 From all this I do not see how you interpret N dotted IP or mask, or 
how it provides the flexibility I am aiming for.

As I understand it you rule out numbers >255, I agree to that.

BTW iptables currently parses 10.20 as 10.0.0.20, but 10.20/24 becomes 
10.0.0.0/24, so apparently the common understanding is not so common.


> I do not find 10. as suitable shorthand for 10.0.0.0/8 even if this form 
> is currently not in use in any of the established notations. The problem 
> with 10. is that this could just as well be a partially typed IP address 
> where the administrator meant to enter more information but forgot. 
> These things happens more often than one would think.

If that is a concern (and I agree it is) then we should *start* by 
ruling out all the short forms and big decimal forms outlined in other 
mails! I could just as well have forgotten a few dots in 1001122, who knows?

I believe my proposal will make partial addresses (and masks) easier to 
understand since the dot(s) explicitly show where the missing octets 
are. Contrary to N dotted form without extra dots.

May not have been clear but the idea is of course that dotted masks can 
be partial as well, fx. "10./255.", "0.0.1.0/.255.0" etc.


Simon

  reply	other threads:[~2004-09-29 18:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-29  1:41 RFC: Partial IP4 syntax Simon Lodal
2004-09-29  3:56 ` Ben Efros
2004-09-29  5:42   ` Simon Lodal
2004-09-29  8:55     ` Henrik Nordstrom
2004-09-29 16:38       ` Simon Lodal
2004-09-29 17:05         ` Henrik Nordstrom
2004-09-29 18:45           ` Simon Lodal [this message]
2004-09-29 19:11             ` Cedric Blancher
2004-09-29 22:41               ` Simon Lodal
2004-09-29 19:39             ` Henrik Nordstrom
2004-09-29  8:50 ` Henrik Nordstrom
2004-09-29 16:37   ` Simon Lodal
2004-09-29 16:54     ` Henrik Nordstrom
2004-09-29 18:21       ` Simon Lodal
2004-09-29 19:30         ` Henrik Nordstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=415B02CD.2080403@parknet.dk \
    --to=simonl@parknet.dk \
    --cc=ben@xgendev.com \
    --cc=hno@marasystems.com \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.