path: root/doc/roadmap.rst

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


Backend
=======

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

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

  * Namespace includes prefix, since this is standardised.  i.e.
    ns "urn:ietf:params:xml:ns:yang:ietf-interfaces" -> prefix "if:".

* [ ] 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.



[ ] Interfaces module
---------------------

* [ ] Configuration nodes

  * [ ] Name, description, type

  * [ ] Enabled

* [ ] State nodes

  * [ ] Operational state

  * [ ] Time operational state entered

  * [ ] Interface index

  * [ ] MAC address

  * [ ] Related higher/lower layer interfaces

  * [ ] Link speed (bits/second)

  * [ ] Statistics (``ifctrstat``)


The interfaces module allows configuration and inspection of the physical layer
of system network interfaces.


Outstanding TBDs
````````````````
* We support ``arbitrary-names``, right?  Pretty sure GRE / tuntap / etc all
  let you name things whatever you want.

* Do we support ``pre-provisioning``?  It would make sense, since /e/n/i and
  /e/c/n both let you just specify whatever configuration you want for whatever
  interfaces you want.

* Where do we store interface ``description``?

* How do we retrieve ``last-change``?

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