Hi Kent, Circling back on this. It would be great to get this sent out before the end of the week. There is a 3GPP plenary next week at which I can call attention to the LS.
Cheers, Charles On May 15, 2025, at 7:05 PM, Charles Eckel (eckelcu) <[email protected]> wrote: Hi Kent, It is fine to send for information; however, within the text we inform SA5 that "now would be a good time for members in your community to review and provide comments on them.” One challenge with the timing of this LS is that we missed the deadline for contributions for the SA5 meeting that is happening next week, and the next SA5 meeting after that is August 25-29. My recommendation is to remove the sentence about the drafts staying with the WG for a couple of weeks and add the information about the mailing list. Here is an updated version of the text of the LS: --- 1. Description Dear 3GPP TSG SA WG5, We thank you for your LS [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 apologize 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. 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 behavior of NETCONF and RESTCONF. I.e., to help keep programmatic network management 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 behavior and adds complexity to the client. Instead, the solution that the WG would propose is that servers are implemented such that if it is necessary to delete and recreate an object when a field within that object is changed, 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 that has not previously required an 'invariant' behavior annotation or a break in transactional behavior. As you indicate, it has also been observed that some vendors do indeed have configuration that exhibits "isInvariant" style behavior, but NETMOD's 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 LS. 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 defines a new NMDA datastore called "system", where system-defined nodes may be declared. The NETMOD WG asks 3GPP TSG SA WG5 to review and provide comments on these solutions. We encourage the use of the NETMOD WG mailing list [5] as the most effective and expedient way to provide comments. Kent and Lou, NETMOD chairs, on behalf of IETF NETMOD Working Group 2. Upcoming Meetings IETF 123, 19 - 25 July 2025, Madrid, ES IETF 124, 1-7 November, Montreal, CA 3. References [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 [5] https://datatracker.ietf.org/wg/netmod/about/<mailto:https://datatracker.ietf.org/wg/netmod/about/> — I have also attached the Word document in docx and pdf format with change tracking enabled to highlight the changes I am suggesting. Cheers, Charles On May 15, 2025, at 7:11 AM, Kent Watsen <[email protected]> wrote: Hi Charles, 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. Then let's just share for information (no action). 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. If I understand correctly, this statement is unnecessary if just sharing for information (no action) - correct? If it's a case of "it doesn't hurt", then it seems fine to include this statement as well. 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. Are you proposing to send a Word doc w/ change-tracking enabled to the netmod list? How about doing both: - attached a Word doc w/ change-tracking enabled (to act as a diff) - copy/paste email's body (to act as the "please review this" text) Cheers, Charles Likewise, Kent <ls-netmod-is-invariant-and system-created.docx><ls-netmod-is-invariant-and system-created.pdf>_______________________________________________ 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]
