Return-Path: <01000191752006b7-c2ea8ed6-94ec-459f-8f68-db94410b03ef-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4B1C14F71B for ; Wed, 21 Aug 2024 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYkqF5BBCS-L for ; Wed, 21 Aug 2024 06:28:40 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B86C14F5FC for ; Wed, 21 Aug 2024 06:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1724246919; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=GJoQ1rKRkqAOhHdXLxRWmebIyciyVku2D+B13Na5BVg=; b=OG87rNNKXGShhhUIqJeNIvEXXW0hcD4Z4XUkjy/kY9+LGKAl3en3o+ebbUtbs2bV ZF1Yt91RItXPLYmE642FTJHQK9bjGYtiXSNE7v7Bf2V4tZCb5lm82K+ADcEb8kHzDGI 8R/dkl7JViZ32L3DWooFfytJk+jHqG/wSAQA25xA= From: Kent Watsen Message-ID: <01000191752006b7-c2ea8ed6-94ec-459f-8f68-db94410b03ef-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_917B56C5-AC4A-48CD-A195-34E90AA43013" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Date: Wed, 21 Aug 2024 13:28:38 +0000 In-Reply-To: To: "maqiufang (A)" References: <0100019141c6c601-53d41832-302a-4589-9f75-f181bc2a4306-000000@email.amazonses.com> <010001916b21fa43-c8da5499-acaa-4063-8721-1ff1d4ff8678-000000@email.amazonses.com> <0100019170c0b19c-3a358146-3455-4de8-ae2a-1e9b66518dbd-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3774.400.31) Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2024.08.21-54.240.48.92 Message-ID-Hash: OP5JWOR7SY332OSOK7GEBK34YEMIXXZ4 X-Message-ID-Hash: OP5JWOR7SY332OSOK7GEBK34YEMIXXZ4 X-MailFrom: 01000191752006b7-c2ea8ed6-94ec-459f-8f68-db94410b03ef-000000@amazonses.watsen.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "netmod@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_2nd_WGLC_on_system-config-08?= List-Id: NETMOD WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_917B56C5-AC4A-48CD-A195-34E90AA43013 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Qiufang, =20 > Regarding #1, I=E2=80=99m sympathetic to not flipping an established = client-contract without warning. My proposal is to version the = protocols (i.e. NETCONF 1.2 and RESTCONF 1.1) to indicate this change in = behavior. That is, a server implementing the datastore would = have to implement the updated protocol versions. So, for this item, it = seems that it is not *needed* for a client to copy nodes into , = if the protocols are versioned. > If we move towards this way, does this mean the draft needs to be = pending until new versions of protocols are published? Possibly, but let=E2=80=99s not focus on this now. > But even if alone doesn=E2=80=99t have to be valid, no one = would stop a client keep copying referenced system nodes into , = e.g., if no template used in and the client wants to do = offline validation of . The current draft simply allows the = client to do that, it no longer states the client MUST copy any = referenced system nodes into . It is true that it would be impossible to prevent a client from copying = entire nodes into so, in any case, the interplay = still needs to be defined. > I kind of feel like we are back where we started, after around 4 = years=E2=80=99 discussion. I think the agreement at the interim in = January was to effectively say nothing in the draft and fully rely on = existing statements in RFCs. I think this approach gives flexibility and = allows the server to behave the way they do today. And then when we = comes to the discussion of NC/RC-next, we may decide whether there are = benefits to relax the rule and make further clarifications. Any issue we = see now with this handling? True, but you see how it blew up? That=E2=80=99s why I wanted to go = back to the requirements. For #1, I continue to conclude that it is not required (from a long-view = perspective) to copy system-nodes into running.=20 > Regarding #2, I am firstly unclear how this is needed, when we=E2=80=99r= e only just now, for the first time, exposing system-defined = configuration. Up to now, system-defined configuration only appeared in = , with no ability to tweak it, right? Secondly, the = example is not compelling, e.g., why would a client care what the MTU is = on the loopback interface? But, if this is important, how do vendors = enable it to be changed today?=20 > In our implementation, there are non-modifiable/immutable and = modifiable system configuration. the server allows the client to = directly write the desired value into which overrides the = value provided by the system, such examples could be, e.g., to modify = some log levels generated by the running systems, or system-provided = threshold values. Thank you for providing this concrete example. I agree that it is a = valid example. However, I don=E2=80=99t feel that it represents a case = where system-nodes are *copied* into running. It seems more like the = client is just setting regular configuration, for which the system has = default values that are used when not set by . It is possible = that my perspective for this case equally applies to all such #2 cases. What we have done recently to complicate the #2 case is to say that the = entire system-node MUST be copied into , which is truly more = than the client just setting some configuration. However, the desire to = copy the entire-node is directly tied to the =E2=80=9Crunning-alone must = be valid=E2=80=9D position. If we assume that clients MUST use updated = protocol versions (NC/1.2, RC/1.1), then this =E2=80=9Cproblem" goes = away, and it seems that we could conclude that nodes are NOT = being copied into . Makes sense? > Regarding #3, same as #2: how is this needed? The example is not = compelling. If this is important, how do vendors enable such extensions = today? > But isn=E2=80=99t the following example common? > System configures a physical interface instance with only name and = type leaf specified, and the client can further configures other = descendant nodes, e.g., ip-address. You are right. This is a valid example...and one that I often use = myself in the context of LNEs. My comment to #2 equally applies here. FWIW, a client could put any interface name, and either it overlays with = a system-define node or not, and the rules from NMDA=E2=80=99s = =E2=80=9Cmissing resources=E2=80=9D section will cull-out any = mismatches. > I feel that #2 and #3 are not really the =E2=80=9Ccopy=E2=80=9D = things, they are about editing some parts of system configuration. Exactly. :) I think the only difference between where we were before and now is a = matter of perspective. It isn=E2=80=99t a copy, if the full-node isn=E2=80=99t required, which = is only possible if we assume the clients MUST use an updated protocol = version that requires clients to know that running alone may not be = valid, for servers that support any of the following: inactive, = template, system, etc. > But speaking about copy, the authors are considering removing the = =E2=80=9Cresolve-system=E2=80=9D parameter, for the following reasons: > =C2=B7 It is complex and expensive to implement properly (see = the last paragraph = inhttps://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-05= #section-5.3) > =C2=B7 It is optional to implement, and there is workaround = (i.e., explicit copy) > Given reasons above, I doubt if it will be implemented in real = world;-) Any objections to removing this =E2=80=9Cresolve-system=E2=80=9D = parameter? No objection. Quite the opposite, I think it is a good idea, for all = the reasons you stated, and the additional reason that it = suggests/conveys that the =E2=80=9Ccopy=E2=80=9D is occurring, which I = think is a position that we should try to move away from. Kent // as a contributor --Apple-Mail=_917B56C5-AC4A-48CD-A195-34E90AA43013 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Qiufang,
 
Regarding #1, I=E2=80=99m sympathetic to not flipping an = established client-contract without warning.  My proposal is to = version the protocols (i.e. NETCONF 1.2 and RESTCONF 1.1) to indicate = this change in behavior.  That is, a server implementing the = <system> datastore would have to implement the updated protocol = versions.  So, for this item, it seems that it is not *needed* for = a client to copy nodes into <running>, if = the protocols are versioned.
If we move towards this way, does this mean the draft needs to be = pending until new versions of protocols are = published?

Possibly, but = let=E2=80=99s not focus on this = now.


But even if <running> alone = doesn=E2=80=99t have to be valid, no one would stop a client keep = copying referenced system nodes into <running>, e.g., if no = template used in <running> and the client wants to do offline = validation of <running>. The current draft simply allows the = client to do that, it no longer states the client MUST copy any = referenced system nodes into = <running>.

It = is true that it would be impossible to prevent a client from copying = entire <system> nodes into <running> so, in any case, the = interplay still needs to be = defined.


I kind = of feel like we are back where we started, after around 4 years=E2=80=99 = discussion. I think the agreement at the interim in January was to = effectively say nothing in the draft and fully rely on existing = statements in RFCs. I think this approach gives flexibility and allows = the server to behave the way they do today. And then when we comes to = the discussion of NC/RC-next, we may decide whether there are benefits = to relax the rule and make further clarifications. Any issue we see now = with this = handling?

True, = but you see how it blew up?  That=E2=80=99s why I wanted to go back = to the requirements.

For #1, I continue to = conclude that it is not required (from a long-view perspective) to copy = system-nodes into = running. 


Regarding #2, I am firstly unclear how this is needed, when = we=E2=80=99re only just now, for the first time, exposing system-defined = configuration.  Up to now, system-defined configuration only = appeared in <operational>, with no ability to tweak it, right? =  Secondly, the example is not compelling, e.g., why would a client = care what the MTU is on the loopback interface?  But, if this is = important, how do vendors enable it to be changed today? 
In our implementation, = there are non-modifiable/immutable and modifiable system configuration. = the server allows the client to directly write the desired value into = <running> which overrides the value provided by the system, such = examples could be, e.g., to modify some log levels generated by the = running systems, or system-provided threshold = values.

Tha= nk you for providing this concrete example.  I agree that it is a = valid example.  However, I don=E2=80=99t feel that it represents a = case where system-nodes are *copied* into running.  It seems more = like the client is just setting regular configuration, for which the = system has default values that are used when not set by <running>. =  It is possible that my perspective for this case equally applies = to all such #2 cases.

What we have done = recently to complicate the #2 case is to say that the entire system-node = MUST be copied into <running>, which is truly more than the client = just setting some configuration.  However, the desire to copy the = entire-node is directly tied to the =E2=80=9Crunning-alone must be = valid=E2=80=9D position.  If we assume that clients MUST use = updated protocol versions (NC/1.2, RC/1.1), then this =E2=80=9Cproblem" = goes away, and it seems that we could conclude that <system> nodes = are NOT being copied into <running>.  Makes = sense?



Regarding #3, same as #2: how is = this needed?  The example is not compelling.  If this is important, how do vendors enable such extensions = today?
But isn=E2=80=99t the = following example common?
System = configures a physical interface instance with only name and type leaf = specified, and the client can further configures other descendant nodes, = e.g., = ip-address.

You are right.  This is a valid example...and one that I often use = myself in the context of LNEs.

My comment to #2 = equally applies here.

FWIW, a client could put = any interface name, and either it overlays with a system-define node or = not, and the rules from NMDA=E2=80=99s =E2=80=9Cmissing resources=E2=80=9D= section will cull-out any = mismatches.


I feel that #2 and #3 are not really = the =E2=80=9Ccopy=E2=80=9D things, they are about editing some parts of = system = configuration.

Ex= actly.  :)

I think the only difference = between where we were before and now is a matter of = perspective.

It isn=E2=80=99t a copy, if the = full-node isn=E2=80=99t required, which is only possible if we assume = the clients MUST use an updated protocol version that requires clients = to know that running alone may not be valid, for servers that support = any of the following: inactive, template, system, = etc.


But speaking about copy, the authors are considering removing the = =E2=80=9Cresolve-system=E2=80=9D parameter, for the following = reasons:
=C2=B7         It is complex and expensive to = implement properly (see the last paragraph inhttps://datatracker.ietf.org/doc/html/draft-ietf-netmod-system= -config-05#section-5.3)
=C2=B7         It is optional to implement, and = there is workaround (i.e., explicit copy)
Given reasons above, I doubt if it will be implemented in real = world;-) Any objections to removing this =E2=80=9Cresolve-system=E2=80=9D = parameter?

No = objection.  Quite the opposite, I think it is a good idea, for all = the reasons you stated, and the additional reason that it = suggests/conveys that the =E2=80=9Ccopy=E2=80=9D is occurring, which I = think is a position that we should try to move away = from.


Kent // as a = contributor

= --Apple-Mail=_917B56C5-AC4A-48CD-A195-34E90AA43013--