[bind10-dev] Idea for simple (but limited) views

[Michal 'vorner' Vaner]

Hello

Once again, into the mailing list (with small update).

First, my idea was to implement both ‒ this kind of views, which would be
simpler to use as well as simpler to implement, and the full one with the
receptionist, that would be harder to set up, harder to code, more heavy-weight
and possibly slower, but significantly more flexible.

With the configuration, I know opinions here may differ, but I would still
prefer my approach, because:
 • Does not clutter config of people who don't want views. I guess you would
   need to include a catch-all view even if it was the only one.
 • Allows to have large shared part of the configuration between all views.
 • Allows stuff like deriving sub-views without large copy-paste of parts of
   configuration.
 • It seems easier to grasp as an administrator to me than the thing with first
   splitting to views.
 • Less code changes to implement.

And, I don't think this breaks the behaviour of the client list and its
matching. It just allows the user to tweak the matching to his needs more than
now. For normal administrators, it is enough to tell them about the first-match
principle of client list. But once they want something more, you can add „oh,
well, you can customise it little bit with this“. With your approach, you need
to explain the views to everybody.

Maybe it would be easier if this thing was _not_ named views. While it solves
some part of the problem that is solvable with views too, it does so in somewhat
backwards manner, so people who operate with views would get confused by the
name.

As for the transfers. Well, I guess you'd need a way to configure it with your
approach as well as with the receptionist model. The XfrOut would be probably
simple, as the same ACLs would be used to pick up the zone to transfer from.
XfrIn, I guess we would need to have a name of the data source as well as the
zone name to configure it.

With regards

-- 
If life didn't have a point, it wouldn't have to be real. Integer would be enough.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130613/840bb8e9/attachment.bin>