Hi Kent, Please see my responses inline.
On May 13, 2025, at 2:56 PM, Kent Watsen <[email protected]> wrote: Hi Charles, Thanks for taking a look. Some responses below. Kent On May 12, 2025, at 10:51 AM, Charles Eckel (eckelcu) <[email protected]> wrote: Hi Kent, Rob, I reviewed the draft text. Overall, it is very clear and comprehensive in sharing the state of the drafts and the rationale behind the solutions that they provide. :) However, it is not clear to me whether this information is meant to be shared for information or if specific action is requested, and if so, what the deadline for such action would be. It would also be good to share how to provide feedback (e.g., via another LS for IETF 123 and/or via the WG mailer). I don't like introducing dependences, so if there is an option to just *inform* them of the WG consensus, then that sounds best to me. Is this actually an option? Yes, it is, and unless there are specific questions or concerns for which answers or feedback is needed, sending for information is appropriate. This LS will actually be sent in reply to the previous LS from 3GPP, and there is no need to specify any actions or deadlines. However, if it's expected to give them a chance to respond, then I'd say by email to the NETMOD list (CC-ed) within two weeks. Please note that one draft is already post-WGLC, so it's already a little too late but, if needed, I (as chair) will hold it for two-weeks to give them time to respond. Please advise. We can simply say that an email to the NETMOD list is the best and most timely way to provide any feedback. The text on this email is not the same as that at https://github.com/rgwilton/3gpp_liaison_response/blob/main/draft-liaison-response.md. I have some editorial suggestions but did not want to provide them against an out-of-date version. I can share them in a draft version of the 3GPP document that would be used to provide the LS, if that is preferred. Correct. I updated Rob's text to better reflect current status. If using a draft version of the 3GPP document, would diffs be visible? If not, maybe send text-edits to the list (e.g., OLD/NEW) or use a burner HedgeDoc page? I can copy/paste the text provided in this email into a Word document formatted as a 3GPP contribution and provide that with change tracking enabled to highlight my suggested changes. Let me know if this all sounds ok. Cheers, Charles Cheers, Charles Likewise, Kent On May 8, 2025, at 5:55 PM, Kent Watsen <[email protected]> wrote: 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]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
