Hi Charles, Thanks for taking a look. Some responses below.
Kent > On May 12, 2025, at 10:51 AM, Charles Eckel (eckelcu) > <eckelcu=40cisco....@dmarc.ietf.org> 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? 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. > 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? > Cheers, > Charles Likewise, Kent > > >> On May 8, 2025, at 5:55 PM, Kent Watsen <kent+i...@watsen.net> 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 -- netmod@ietf.org > To unsubscribe send an email to netmod-le...@ietf.org
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
