[bind10-dev] ACL task ←→ feature mapping
Michal 'vorner' Vaner
michal.vaner at nic.cz
Tue May 31 16:44:07 UTC 2011
As pointed out on the call, I've created the tickets by building blocks and I
didn't really think about features at that time (I considered ACLs as one, big,
So, this is some list of what may be needed for each feature:
In this, we would be able to provide a check for single value of single property
in a program. This is not complete and probably not enough for most of people,
but it's already visible:
• Abstract ACL base class (#977)
• The ACL for property being checked (let's say IP address, no ticket yet)
• Simplified loader (#978)
• Named ACLs (#982)
• Python wrappers (#983)
• Configuration plugin to check ACLs (#768)
• Actual integration into the program
The property depends only on the base ACL class. The others are consecutive (but
if we split the Python wrappers a little, part of it can be started sooner, for
example the wrapper around the ACL class). The python wrappers are needed for
the configuration plugin. Technically, it's not needed to have the configuration
plugin completely written (one providing spec only would be enough) for the
program integration, so that task could be started in parallel as well, but I
believe releasing without the checking would be bad. I think we want to
integrate it into auth first, because it doesn't need the python wrappers and
AFAIK the C++ config session doesn't check the data against the spec, modifying
the specs so they allow the free-form way would be part of the #768.
What we really want
We really want to provide a way to specify more complicated ACLs than just
single value of single property. This will be established by:
• AND and OR operators (#979)
• NOT operator (#981)
Both depend on the simplified loader.
We probably want soon the abbreviated form (for convenience, #980, depends on
AND and OR), and first-match operator (depends on simplified loader, no ticket
More properties, like TSIG, whatever else. These depend on #977 only and can be
highly parallelized. Therefore they form nice „filler“ and small tasks. We also
want to add the support to more programs, which can be done in parallel then
(with both the configuration plugin, and the „we really want“ section, and, if
more is left, the properties).
So, I suggest we start with the critical path first, which is probably the
„Basic support“ part without the property being checked and start the sideways
paths as there's extra „waiting“ manpower (both because the parallelization
efforts and because it's the most visible part, we can include one more checked
property as visible eye-candy feature every release then ;-).
Does it help to clarify what I mean? I'll create the page with more detailed
design tomorrow (and possibly some dependency graph picture).
Wait few minutes before opening this email. The temperature difference
could lead to vapour condensation.
Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the bind10-dev