4.1 Alpha-8

• init perf / scale / soak tests

• Paging (offset + limit) query parameters. It is desirable to introduce proprietary query parameters for interacting with potentially long lists (i.e., audit-log, bootstrapping log, devices, tenants, etc.)

4.2 Alpha-9

• Tenant view device types. Currently, tenants can set a valid ‘device-types’ value only if provided to them out-of-band. These values are only set at the “host” level, (on purpose) outside the tenant’s purview. A tenant’s clients should be able use either an RPC/action to get the supported device-types from the host, or have that information exposed as opstate (i.e., read-only “config false” values)⁴.

• Validating the end-entity certificates, when being configured, match the associated private key. Currently the system trusts that the user passes in valid key/cert pairs.

• Validating base64 contents (CMS). Currently trusts that valid structures are configured. Only later, when using the structures will SZTPD decode them and potentially find errors. Exceptions will be thrown, but the error messages are not always helpful. Tests would include, e.g., that a CMS containing a sequence of certificates does not contain any spurious certificates.

4.3 Alpha-10

• RESTCONF entity-tag (ETag) Support. The HEAD and GET operations would return the “ETag” HTTP header field. The POST, PUT, and DELETE operations would inspect request headers for the “If-Match”, and “If-None-Match” fields. This enables concurrent clients to detect if changes are have been made since their using a HEAD or GET command. Support for Etag is a MUST in RFC 8040 only on the top-level datastore resource, and unspecified for inner-resources⁵

4.4 Alpha-11

• Implement the “ietf-restconf-monitoring” per Section 9 of RFC 8040. This is needed to identify which capabilities (e.g., query params) and streams (e.g., the notifications) the SZTPD server supports.

• The RESTCONF/HTTP “OPTIONS” method. This needs to be added in order to notify clients that XML is NOT supported.

4.5 Alpha-X

• Authorization / access-control. It is planned to implement the admin-account “access” node, which sets an enumerated value being one of “unrestricted”, “typical”, and “minimal”.

• Implicit change tracking. This is needed to support a few of the features listed below. It is also needed to detect when any part of the “transport” configuration changes, so that a SIGHUP can be issued. Currently SIGHUP is issued only when an “endpoint” is added or removed.

• Bootstrapping event counter. SZTPD needs to maintain bootstrapping event counters.

• Device record counters. It is planned to track when the device records are created, last modified, and the total number of modifications. Similarly, to track when the bootstrapping device first connected, last connected, and the total number of connections.

• Reference tracking. It is desired to track references to objects in the system. In YANG terms, these are the ‘leafref’ statements that reference a ‘list’ statement’s ‘key’ node. Tracking includes the current number of references and the time of last reference.

• Automated purging with notifications. It is desired to send notifications when unreferenced objects have been without a reference, for some configurable amount of time. A series of notifications with escalating urgency can be to sent to configurable notification receivers. A final notification is sent when the purging occurs.

• Password expirations with notifications. This feature goes with the previously mentioned “automated purging with notifications” feature, but has its own “preferences” setting for the timeouts.

• Email-based admin activations. It is intended that SZTPD will send email based notifications to newly created admins when their accounts are first created. It is important to validate the email address because the same email address may be emailed later when the password expiration date is approaching. This is why the email address is the primary key for the admin accounts.

• Password minimum length constraints. Currently the “preference” setting for the admin account password’s minimum length constraint is ignored.

• Client certificate based auth to NBIs. Currently SZTPD implements client cert based auth to the SBI (i.e, ‘rfc8572-interface’). This is to extend that configuration into the NBIs also (i.e., ‘native’ and ‘tenant’). This would provide 2FA to the NBI.

• Webhook-based callouts for both the “get-conveyed-information” and “verify-device-ownership” callouts. Callback-based callouts (i.e., plugins) can be used as a workaround until support for webhooks is implemented. More important to add webhook for “verify-device-ownership”?

• Plugin-based callbacks for the “relay-notification” callout. Webhook-based callouts can be used as a workaround until support for plugins is implemented.

4.6 Beta

• Run performance and soak tests. Only address issues found.

4.7 FCS

• Nothing new
• Stress tests
• Soak tests

4.8 Post 1.0

• Remove support for mode ‘1’. This change would affect the NBI only (no impact on the device-facing ‘rfc8572’ SBI).

  • Reasons to remove mode ‘1’:

    1. It may be important for non-production use environments (e.g., those used for evals and demos) to exactly mimic production environments.

    2. Eliminates an artificial constraint for Mode ‘1’ deployments, in they can easily configure an additional “tenant” for whatever reason. It also eliminates need to ever have to migrate mode-1 deployments to a mode-x deployment, which would require a database migration..

    3. The tenant-view provided by Mode ‘x’ quite nicely isolates system-level configuration enabling IT organizations to do the system-level install and then pass an “application” view that excludes the system-level install to another organization within the company.

    4. Only supporting Mode-x could greatly simplify the YANG modules. This could be important to developers as they might need to look at the YANG modules in order to understand the data model exposed by the API. While the current YANG is navigable, it could be even more so if only supporting Mode-x.

    5. Further simplify the YANG modules. Note that mode ‘0’ is already almost completely phased out, and yet the YANG modules have yet to be simplified…somewhat due to waiting to determine if also phasing out mode ‘1’.

  • Reasons to NOT remove mode ‘1’⁶:

    1. It is unclear what the market expectations are regarding metered based subscriptions versus flat-rate tiers for enterprises and service providers. Hesitant to change anything without some feedback.

• Run the “verify-device-ownership” callouts at time of bootstrapping event (in addition to when the device record was first created). Seems like something that should be opt-ed into, and hence a feature that can be implemented later.

• RESTCONF “Last-Modified” support. The HEAD and GET operations would return the “Last-Modified” HTTP header field. The POST, PUT, and DELETE operations would inspect request headers for the “If-Modified-Since” and “If-Unmodified-Since” fields. Support for timestamps is a SHOULD in RFC 8040.

• RESTCONF Filtering (depth + fields) query parameters. These query parameters are described by Section 4.8 of RFC 8040 to reduce the amount of data returned to the client. RFC 8040 does not require these query parameters to be supported. Workaround is for the client to discard the unwanted parts of the response itself.

• The RESTCONF/HTTP “PATCH” method. Though a MUST in RFC 8040, it seems mostly like a nice-to-have in SZTPD…

• XML-based messages in SBI. RESTCONF enables the Content-Type to be “application/yang.data+xml” signaling that the server supports encoding XML messages. Currently, SZTPD only supports “application/yang.data+json” for a JSON-only SBI interface. There is a question of market-demand as for if needed. All clients (both NBI and SBI) must use JSON-encoded RESTCONF messages.

• Support a callout to retrieve an ownership voucher from an external system. This would implement the “supply-ownership-voucher” RPC defined in the “wn-sztpd-callbacks” module. The RPC is currently protected by a ‘feature’ statement called “supply-ownership-voucher”, thus programmatically signalling that it is not supported, though visible in the YANG.

• Support signing conveyed information sent from SZTPD using the private key associated with a configured owner certificate.

  • Support encrypting conveyed information sent from SZTPD using the device’s public key from its identity certificate (e.g., IDevID).

  • Support stapling revocation responses to CMS objects returned to devices.

    • only needed for signed data? (what about the redirect-info’s trust-anchor CMS?)

  • Private key encryption. It is desirable for SZTPD to have an ability to encrypt private keys via a “root” key. Note that this is above and beyond DB-level encryption; it purpose to to shield keys even from administrators having appropriate access. This root key would be protected by access control and/or an HSM.

  • Actions: None of the ‘action’ statements defined in the YANG modules are implemented yet. Primarily this effects the ability to create keys, and generate certificate signing requests. The workaround is to generate the keys and certs using an external PKI and then pass those values in as configuration.

7.1 0.0.7

• Changed “/transport/listen/endpoint/use-for” to be a “mandatory true” leaf; it was a “mandatory false” leaf-list, thus removing the ability for an endpoint to present more than one API, which was unnecessarily present before.

• The “ordered-by user” query parameters (point + insert) now work, per Section 4.8 of RFC 8040^{[There are three “ordered-by user” lists in SZTPD: download-uris, bootstrap-servers, and matched-responses (the first two are leaf-lists).]}[Be advised that the “download-uri” leaf-list uses URL as keys; the client MUST percent-encode these URL-based keys.].

• Modified the “wn-sztpd-1” YANG module to set the per-device device-type leafref to “require-instance true” (was false).

• Implemented the “SZTPD_DEFAULT_ADDR” environment variable, as described in the Installation Guide.

7.2 0.0.6

• Device-ownership verification callout now works using plugin-based callouts.
• The validation-layer’s cache is now rolled back when database transactions fail.
• The validation-layer now tests for uniqueness in global keys.

7.3 0.0.5

• Now supports fronting SZTPD with a TLS-terminator. Requires that the SZTP-client’s certificate is passed to SZTPD via the HTTP header “X-Client-Cert” as a PEM (urlencoded). Tested using NGINX.

7.4 0.0.4

• Now supports concurrent write requests.

7.5 0.0.3

• all unit tests now pass when SZTPD points to a MySQL database. With or without TLS, with or without client certificate. AWS Aurora MySQL also tested.
• RESTCONF error meesages are now returned on the SBI (RFC 8572) interface.

7.6 0.0.2

• callback-based callouts implemented to support draft-kwatsen-netconf-sztp-csr.
• fixed bugs related to bootstrapping-log and audit-log not cleaning up correctly when deleted.

7.7 0.0.1

• initial public release