[bind10-dev] ACL Syntax proposal

[Michal 'vorner' Vaner]

Hello

On Mon, Jun 06, 2011 at 08:07:49AM +0200, Jelte Jansen wrote:
> On 06/04/2011 12:39 PM, Michal 'vorner' Vaner wrote:
> > 
> > Would someone want to have a look at how to encode it in JSON in the least
> > awkward way? I'd be probably too influenced by the proposal I wrote (despite the
> > effort and knowledge it would be best, it's hard to discard some ideas). Or,
> > should I try it anyway?
> > 
> 
> Regarding this specific part of your message, and on a more general note,
> there's 3 parts here that kind of got conflated;
> 
> 1. The way to specify rules
> 2. The way to serialize rules
> 3. The way to match rules

Well, 2 implicitly includes 1, at last partly.

Anyway, stepping little bit back, I try to summarise what we need:
• We want a configurable black box, which gets the message and other info and
  responds true/false.
• The preferred method for configuration is first match.
• We want some kind of nesting (so we can include one list in another, and do
  negations).
• We may want some other combining of sub-results?
• It needs to be extensible, so if someone codes a new check, it should be
  possible to just include it.

Do we agree on this?

So, if we turn the original proposal inside out a little bit, something like
this (for example, the exact serialisation isn't that important, but I need to
show it somehow)?

[
   {
     "mode": "accept",
     "ip": "192.168.0.0/16"
   },
   {
     "mode": "reject-not-impl",
     "opcode": "ddns"
   },
   "other_list",
   {
     "mode": "reject",
     "sublist": [
        {
          "mode": "accept",
          "tsig": null
        },
        "accept"
     ]
   },
   {
     "mode": "accept",
     "any-of": [
        {
          "ip": "1.2.3.4",
          "tsig": "key"
        },
        {
          "ip": "5.6.7.8",
          "tsig": "another_key"
        }
     ]
   }
   "reject"
]

We could have mode: accept as default, and otherwise tweak it. But
structure-wise and feature-wise, is it something like what we might want?

I'd ignore 3 for a while, it seems that if we have internal syntax tree, it
should be possible to optimise it and we can postpone the optimisation when we
have something working.

Some pretty-printing and pretty-reading can be postponed as well. But we need to
set 2 now, to be able to do some work on it and 2 holds the general
structure/nature of the language, even if we decide we don't want the curly
braces ;-).

With regards

Thanks

-- 
_(){ _&_;};_

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110606/6a89149b/attachment.bin>