summaryrefslogblamecommitdiff
path: root/doc/roadmap.rst
blob: 459edb8c8ef09013d815a885acae67081b86b7a3 (plain) (tree)































































































































                                                                               
================
 Roadmap to 1.0
================


Backend
=======

[ ] Module management system
----------------------------

* [ ] Track name/revision/namespace, and register with NSMAP

* [ ] Track features implemented

* [ ] Handle import-only modules

* [ ] Submodule support?  (possibly post-1.0)

* [ ] Respond to state requests


The module management system will be the heart of ``ncserver``.  Similar to
modules in Charybdis/Atheme or GlorIRCd.  Each module will provide a piece of
functionality (in this case, implementation of a YANG module).  Each module
will have a callback for retrieving its relevant config and state information.

The module management system will be responsible for bookkeeping and also
implement the ietf-yang-library module itself.  This exposes the internal
bookkeeping to the NETCONF world for introspecting the server.

This also makes the server more customisable.  If a user does not care about
a specific YANG module, it can just be removed from the list to import.


Outstanding TBDs
````````````````
* The ``modules-state`` requires a ``module-set-id`` which represents the
  unique combination of YANG modules present and loaded in a NETCONF server.
  We have freedom to implement this however we like.  One thought is to take
  the strings of every module's namespace and sha512 the result.  Alternatively
  we could just use Python ``uuid`` to generate a new one on each server start,
  but this would also mean that tooling that caches modules would pull in all
  modules on every server restart.

Resolved TBDs
`````````````
* None.



[ ] NACM
--------

This feature will require in-depth discussion.



[ ] System module
-----------------

* [ ] Configuration nodes

  * [ ] Retrieve and set admin contact and system location information.

  * [ ] Retrieve and set hostname.

  * [ ] Clock:

    * [ ] Retrieve and set timezone name (``/etc/localtime``).

    * [ ] Determine ``timezone-utc-offset`` from current localtime.

  * [ ] DNS configuration

  * [ ] Local user administration:

    * [ ] Password support (if in spec).

    * [ ] SSH key administration (``$HOME/.ssh/authorized_keys``).

* [ ] State nodes

  * [ ] Platform information.

  * [ ] Current date and time.

  * [ ] Boot date and time.

* [ ] RPCs

  * [ ] Set date/time.

  * [ ] Restart.

  * [ ] Shutdown.


The system module allows basic administration of system configuration.


Outstanding TBDs
````````````````
* Do we support NTP?  If so, which implementation?  Prefer chrony because it's
  available on Adélie (openntpd isn't available due to ppc/be issues)

* Where do we store the ``contact`` and ``location`` node information?

* When the admin tries to set ``timezone-utf-offset``, do we make a custom
  zoneinfo file or do we try to match?

* How do we support ``name`` of DNS resolvers?  It is mandatory.

* Can musl be configured for DNS timeout seconds and resolution attempts?
  Would Rich be open to adding this?

* Do we support password-based authentication?

* If we support password-based authentication, do we have a custom database or
  do we use ``/etc/shadow``?  Should there be a group for NETCONF-allowed
  users?  Do we support RADIUS?

* Do we calculate boot date/time naively (current time - uptime) or do we try
  to ascertain the actual boot date/time from something like ctime of ``/run``?

Resolved TBDs
`````````````
* None