NETMOD WG, Two years ago this WG received a liaison request [1] from 3GPP. The request helped shaped what became the now "system-config" and "immutable-flag" drafts. The WG decided back then to defer a liaison response until these drafts matured, and to then ask for 3GPP comments during the draft's WGLCs. This email proposes text for that response. Charles Eckel (CC-ed) is a liaison coordinator for this.
PS: thank you Rob Wilton for the draft text here [0] Kent // chair ==== START ==== Dear 3GPP, We thank you for your liaison [1] dated, 2023-03-09, explaining your desire and rationale for the IETF to standardize proposed "IsInvariant" and "SystemCreated" annotations for use with the YANG language. We aplogise for the slightly delayed response, but the NETMOD working group has been considering a solution in this area, which although it may not exactly meet your concerns (further details below), we believe that we have documents [2][3] that have progressed reasonably far through the IETF publication process and hence now would be a good time for members in your community to review and provide comments on them. Please note that these drafts are either in or past IETF "Last Call", but are still held within the NETMOD WG, where they can stay for a couple weeks, sufficient for your response. The proposed solution is two-fold: 1) a new datastore called <system>, that can document what configuration is system-defined and 2) a new metadata annotation called "immutable", that a server may return for <system> defined data, thus enabling clients to know when certain edit operations against immutable data may fail. Regarding 1.2.1 isInvariant: We are not able to offer an exact solution for standardizing an "isInvariant" extension because of concerns that such an extension would end up breaking the transactional behaviour of NETCONF and RESTCONF. I.e., to help keep programmatic network managemennt clients simple, there is a very strong desire to always allow a client to migrate a devices state from any valid configuration to any different valid configuration as a single committed configuration change. Defining a flag such as "isInvariant" that forces clients to make configuration changes in multiple independent steps breaks this transactional behaviour and adds complexity to the client. Instead, the solution that the WG would propose is the servers are implemented such if it necessary to delete and recreate an object when a field within that object is changed then that instrumentation should be performed automatically by the server and be invisible to the client. This would, as your liaison indicated, potentially be a traffic impacting change, but it has been observed that many such changes are possible and supported in general network device configuration which has not previously required an 'invariant' behaviour annotation, or break in transactional behavior. As you indicate, it has also been observed that some vendors do indeed have configuration that exhibits "isInvariant" stlye behavior, but NETMODs goal here is that it would be more desirable to gradually migrate away from such behavior rather than standardize and encourage further proliferation of such behavior that introduces unnecessary complexities to automated management clients. Instead, it is assumed that clients can be designed and implemented so that they can manage such changes appropriately. Hence the "immutable-flag" draft [3] defines a metadata attribute called "immutable" that can be used by a system to declare which configuration nodes it deems immutable. Regarding 1.2.2 SystemCreated Classes: The system datastore defined in [2] provides a similar, but slightly different solution to the problem described by SystemCreated Classes in your letter. The NETMOD WG believes that that the "system-config" draft provides a solution for your problem, whilst preserving NETCONF/YANGs transactional behavior in an NMDA [4] compliant manner. Specifically, the solution in defines a new NMDA datastore called "system", where system-defined nodes may be declared. The NETMOD WG asks for 3GPP-TSG-SA-WG5 to review and provide comments on these solutions. Kent and Lou, NETMOD chairs, on behalf of IETF NETMOD Working Group References: [0] https://github.com/rgwilton/3gpp_liaison_response/blob/main/draft-liaison-response.md [1] https://datatracker.ietf.org/liaison/1818 [2] https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config [3] https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag [4] https://datatracker.ietf.org/doc/html/rfc8342 ==== STOP ==== Thoughts? Kent
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
