question about netconf and GSoC.

[Alexey Tarasov]

Hi,

I've found that netconf project will be in the GSoC'2008 and want discuss
some details, cause it seems interesting for me. I've some thoughts, but I
need confirmation that I'm thinking in correct or incorrect way. Below are
some areas, that I think, may be improved.

= 1 =
I want port netconf to FreeBSD (cause I like FreeBSD last years more than
Linux). For this purpose some replacement is needed, cause netconf deeply
relies on shell scripts, that utilize iproute2. Actually that also prevents
from porting netconf to very old Linux distributions also (I don't know if
they are still used widely enough, but I've seen some of them still
working). The main idea is go away from running creation of objects like:

runner = methods.Runner(somescript)

One of possible solutions is to make system dependent dictionary mapping
event to some script and use it like in such pseudocode:

runner = RunnersFactory.createRunner(EVENT_NAME)

where RunnersFactory is object with such system dependent dictionary or may
create Runners with other than Runner(script_string) constructors.

Other one opportunity - forget about scripts and use C module, which
executes system calls. There are not so many network related events, so one
solid network related module may handle all of them by cost of a little bit
harder extensibility.

= 2 =
Actually I've worked with DHCP-client in PXE environment, so some DHCP
related tasks such as lease renewal, getting DHCP options and etc may
implement without external DHCP client and use python or C for this purpose.
But DHCP protocol not supports all needed options as wanted at ideas page
(user may encapsulate user-defined options in reply packet, but this is not
common way).

= 3 =
I've looked through sources and found that IP class uses only IPv4. it's
better to revise all related modules and provide partial support of IPv6 at
least.

= 4 =
May be policy and security related problems. IMHO, syntax like squid acls is
good enough. E.g.

acl all_users user1 user2 group
acl bad_users user3
allow all_users interface control
deny bad_users interface any

where 'interface' may be just name for module, or plugin, or some other
keyword.

= 5 =
Some kind of related plugins. E.g. There is some task. Try first plugin,
then next if first failed. This may help use IPv6 (fall over to IPv4) and
some other fall overs from protocol to protocol. If plugin knows about
plugin to failover t, it's simple (just make event to handle by other
plugin). But if plugin has no such knowledge, some workaround is needed, e.g.
configuration files with list of plugins to use sequentially.

= 6=
It seems good idea to extract plugins from existing sources and make core
really small core with a huge amount of plugins, that now are only python
based only (mainly cause EventHandlers are python based). That also needs
some specification of core <-> plugins data exchange.

= 7 =
May be some ACPI related events. Usually (at least in FreeBSD) two scripts
are used to handle power state changes. So, new events must be implemented,
that are generated from this scripts. Not only power state change, but
configuration change (e.g. power for notebook Ethernet NIC is offed by
switch, driver is loaded, logical interface still exists but not works
really)

Thanks for any comments.

---
best regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080312/f838d557/attachment.htm