On Tue, Jan 30, 2024 at 8:55 AM Jason Sterne (Nokia) <jason.sterne= 40nokia....@dmarc.ietf.org> wrote:
> Hi WG, > > (and in particular to those who attended the interim). > > > > The summary below mostly matches my memory of the discussions, but I don’t > really remember us concluding on this: > > > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > > clarification the <running> alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > <intended>, which is subject to validation. > > > I do not have a problem with "<running> SHOULD always be valid" (instead of MUST). IMO the lack of standards for the "magic" that converts <running> into <intended> should be fixed. There was going to be metadata like an "enabled" flag on <running> data nodes. This never happened. Too bad, because this solution could support both NMDA and non-NMDA deployments. Andy > (the rest of the minutes/summary below also seems to contradict that > paragraph being a conclusion no?) > > > > I thought it was going to remain somewhat optional/indeterminate if > running will be valid: > > - Servers may or may not enforce running to be valid (i.e. they may > only validate intended as a proxy for validating running) > - Clients can’t necessarily expect to be able to offline validate > running, although it may work in circumstances where the operator doesn’t > use templates or inactive config **or** the client reproduces the > server logic for the running->intended transforms > > > > Jason > > > > *From:* netmod <netmod-boun...@ietf.org> *On Behalf Of *Kent Watsen > *Sent:* Monday, January 29, 2024 7:21 PM > *To:* netmod@ietf.org > *Subject:* [netmod] Draft Minutes for Virtual Interim > > > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Link to minutes: > > > https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/ > > > > Reproduced below for convenience. > > > > Please report any updates needed here. > > > > Kent (and Lou) > > > > > > > > This virtual interim was soley focused on the "system-config" draft. > > Qiufang Ma presented. > > > > Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config > > > > In the course of two hours, there was a lot of discussion. So much so > > that trying to capture all the points verbatim would take too long. A > > link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA. > > > > A high-level summary is: > > > > Qiufang's presentation focused on two main questions? > > > > 1) The "origin" issue. > > > > The WG agreed that <system> nodes copied into <running> should > > have origin "intended". The system-config draft will "update" > > RFC 8342 (NMDA) to state this. > > > > The WG agreed that data-migration is 1) not <system>-specific > > concern and 2) is out-of-scope for this draft. > > > > 2) Validity of <running> alone. > > > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > > clarification the <running> alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > <intended>, which is subject to validation. > > > > The WG agreed on a new Option 4: this document doesn't say > > anything at all about the validity of <running>. That is, > > fully rely on existing 7950 and 8342 statements. > > > > This leaves it up to interpretation. > > > > Templates and inactive configuration are nice for humans, but > > unnecessary for machine-to-machine interfaces. That is, the > > issues arounds such mechanisms are largely moot in environments > > using a controller. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
