Hi Charles, Thanks for the follow up. Your proposed text looks good to me.
Lou, do you agree? Does anyone in the WG want to change anything? Charles, if no responses by tomorrow, I think it's safe to send as is for the 3GPP plenary next week. Kent > On Jun 4, 2025, at 3:42 PM, Charles Eckel (eckelcu) > <[email protected]> wrote: > > 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]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
