From 3199044e30f6398509eeb444f9e43ebac31ffdf1 Mon Sep 17 00:00:00 2001
From: "A. Wilcox" <AWilcox@Wilcox-Tech.com>
Date: Tue, 25 Aug 2020 19:02:17 -0500
Subject: doc: Add initial roadmap/architecture documentation

---
 doc/roadmap.rst | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 128 insertions(+)
 create mode 100644 doc/roadmap.rst

diff --git a/doc/roadmap.rst b/doc/roadmap.rst
new file mode 100644
index 0000000..459edb8
--- /dev/null
+++ b/doc/roadmap.rst
@@ -0,0 +1,128 @@
+================
+ 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
-- 
cgit v1.2.3-70-g09d2