Re: [netmod] Draft Minutes for Virtual Interim
The draft interim minutes have been updated. Thank you Jason, Jurgen, and Carsten for your valuable comments. Link to minutes: https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/ The minutes are reproduced below for convenience. Please report any updates needed here. Kent (and Lou) = START = 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 consensus in the room was that nodes copied into should have origin "intended". The system-config draft may "update" RFC 8342 (NMDA) to state this. The consensus in the room was that data-migration is 1) not -specific concern and 2) is out-of-scope for this draft. 2) Validity of alone. The consensus in the room was to let 7950-bis "update" 8342 (NMDA) with the clarification the alone does not have to be valid. E.g., clients may have to perform transforms to calculate , which is subject to validation. The consensus in the room was a new "Option 4" - i.e., this document doesn't say anything at all about the validity of . 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. = STOP = ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Draft Minutes for Virtual Interim
On 2024-01-31, at 16:46, Kent Watsen wrote: > > Clearly the email is the “confirmation" on the list, and hence it didn't > seem wrong to predictively say "the WG agrees”. The minutes are minutes of the *meeting*. The WG wasn’t all there, so “the WG agrees” can’t have happened in the meeting. We tend to speak about “consensus of the room” if we want the minutes to assess whether the room agreed. If you get confirmation of the “consensus in the room” later on, you might want to add a note to the minutes, but that is not formally part of the minutes. (Consensus in the room is a good basis for a follow-on confirmation call on the list, because you don’t have to ask all people again who where there in the room. But I don’t think you should hide a consensus call in some meeting minutes.) Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Draft Minutes for Virtual Interim
On Tue, Jan 30, 2024 at 8:55 AM Jason Sterne (Nokia) 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 alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > , which is subject to validation. > > > I do not have a problem with " SHOULD always be valid" (instead of MUST). IMO the lack of standards for the "magic" that converts into should be fixed. There was going to be metadata like an "enabled" flag on 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 *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 nodes copied into 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 -specific > > concern and 2) is out-of-scope for this draft. > > > > 2) Validity of alone. > > > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > > clarification the alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > , 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 . 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
Re: [netmod] Draft Minutes for Virtual Interim
Well, statements like "the WG agrees" are problematic for things that have not been discussed on the mailing list. Perhaps it is the people attending the interim agreed? Well, I can't tell, I have not been there... On Wed, Jan 31, 2024 at 02:15:56AM +, Kent Watsen wrote: > Hi Jason, > > > On Jan 30, 2024, at 11:55 AM, Jason Sterne (Nokia) > > 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 alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > , which is subject to validation. > > The audio indicates Rob saying this and no one objecting. > Are you objecting? > > > > (the rest of the minutes/summary below also seems to contradict that > > paragraph being a conclusion no?) > > Your comments below are not text-edits to the minutes, so it is unclear how > they apply to the minutes. > > Kent > > > > 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 mailto:netmod-boun...@ietf.org>> On > > Behalf Of Kent Watsen > > Sent: Monday, January 29, 2024 7:21 PM > > To: netmod@ietf.org <mailto: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 <http://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 nodes copied into 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 -specific > > concern and 2) is out-of-scope for this draft. > > > > 2) Validity of alone. > > > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > > clarification the alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > , 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 . 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 -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Draft Minutes for Virtual Interim
Hi Jason, > On Jan 30, 2024, at 11:55 AM, Jason Sterne (Nokia) > 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 alone does not have to be valid. > E.g., clients may have to perform transforms to calculate > , which is subject to validation. The audio indicates Rob saying this and no one objecting. Are you objecting? > (the rest of the minutes/summary below also seems to contradict that > paragraph being a conclusion no?) Your comments below are not text-edits to the minutes, so it is unclear how they apply to the minutes. Kent > 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 mailto:netmod-boun...@ietf.org>> On > Behalf Of Kent Watsen > Sent: Monday, January 29, 2024 7:21 PM > To: netmod@ietf.org <mailto: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 <http://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 nodes copied into 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 -specific > concern and 2) is out-of-scope for this draft. > > 2) Validity of alone. > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > clarification the alone does not have to be valid. > E.g., clients may have to perform transforms to calculate > , 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 . 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
Re: [netmod] Draft Minutes for Virtual Interim
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 alone does not have to be valid. E.g., clients may have to perform transforms to calculate , which is subject to validation. (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 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 nodes copied into 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 -specific concern and 2) is out-of-scope for this draft. 2) Validity of alone. The WG agreed to let 7950-bis "update" 8342 (NMDA) with the clarification the alone does not have to be valid. E.g., clients may have to perform transforms to calculate , 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 . 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] Draft Minutes for Virtual Interim
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 nodes copied into 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 -specific concern and 2) is out-of-scope for this draft. 2) Validity of alone. The WG agreed to let 7950-bis "update" 8342 (NMDA) with the clarification the alone does not have to be valid. E.g., clients may have to perform transforms to calculate , 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 . 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
