On Thu, Dec 09, 2021 at 05:51:48PM +, Sterne, Jason (Nokia - CA/Ottawa)
wrote:
> I wonder if having all the system config appear in intended and operational
> may be annoying. We didn't want to pollute running with 100s/1000s of lines
> of unreferenced system config. So maybe putting all tha
I wonder if having all the system config appear in intended and operational may
be annoying. We didn't want to pollute running with 100s/1000s of lines of
unreferenced system config. So maybe putting all that in intended & operational
is also ugly ?
We should have *some* way that a client can r
On Thu, Dec 9, 2021 at 7:19 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> Hi Andy,
>
>
>
> I'm not sure I understand Kent's alternative that you're referencing here.
> Are you talking about something like JUNOS active/inactive configuration
> annotation ?
>
>
>
> Is the "
To help illustrate "Many major server implementations (at least in the router
space)":
JUNOS and Nokia SR OS have it.
I'm not sure about Cisco - maybe someone who knows IOS-XR well could point out
an example of this (or confirm they do/don't have it, or do/don't see a use
case given their mode
Hi Andy,
The actual system instance data isn't in a YANG model, but that instance data
sits in schema defined in the YANG model. It is typically a list entry
populated by the system. But there may also be other list entries created by
the users/clients, and other areas of the YANG model may re
> FWIW, JUNOS “solves” this by *hiding* these system-nodes, such that
> clients must use a special command just to discover them. And, yes, if ever
> any of these are hidden-nodes are reference, offline-validation of
> will fail.
Other implementations have a similar concept with the same cons
> We’ve always maintained that should only contain client-provided
> config, right?
+1
Or at least the clients (or at least operators of a network element) should
have the option of avoiding any config appearing in the running besides what
they put in there.
If config can magically appear in
I think it may be a server implementor's choice whether they would put a
loopback interface into (i.e. consider it as system provisioned
configuration), or into (and not system, i.e. consider it as
state information).
The primary config use cases I see aren't so much interfaces, cards,
etc.
+1. If a value was explicitly configured in , that takes precedence as
origin whether it matches or not (just like it takes precedence as the
value in ).
For config that is *not* in , and comes from , then we should
probably go with "system" as the origin. It is a bit confusing that
flows i
Hi Qiufang Ma,
Please see inline.
Jason
From: maqiufang (A)
Sent: Thursday, December 9, 2021 7:57 AM
To: Sterne, Jason (Nokia - CA/Ottawa)
Cc: netmod@ietf.org
Subject: RE: [netmod] "immutable" flag
Hi, Jason,
Thanks for your comments, please see my reply inline.
From: Sterne, Jason (Nokia - C
Hi Andy,
I'm not sure I understand Kent's alternative that you're referencing here. Are
you talking about something like JUNOS active/inactive configuration annotation
?
Is the "enable" some configurable metadata against data nodes ?
When you say the "full set of nodes in running" are you talk
On Thu, Dec 09, 2021 at 03:15:24PM +, Sterne, Jason (Nokia - CA/Ottawa)
wrote:
> > A server accepting and returning non-valid config is also a surprise
> > and inconvenience.
>
> Andy made a similar point in his reply but it is currently implemented today
> and there are some desirable aspec
> A server accepting and returning non-valid config is also a surprise
> and inconvenience.
Andy made a similar point in his reply but it is currently implemented today
and there are some desirable aspects of that functionality. Many major server
implementations (at least in the router space) ha
On 08/12/2021 13:38, Ladislav Lhotka wrote:
tom petch writes:
The BFD WG are revising RFC9127 to add a new feature if-feature
"client-base-cfg-parms"; and make uses base-cfg-parms { conditional
thereon in module ietf-bfd-types. Reading and re-reading RFC7950,
especially about mandatory and to
Sorry all - I just noticed that my email client didn't thread all the responses
to this topic in with the original post. It looks like this has been heavily
discussed and I'll look through those emails.
From: netmod On Behalf Of Sterne, Jason (Nokia -
CA/Ottawa)
Sent: Wednesday, December 8, 20
On Thu, Dec 09, 2021 at 01:07:09PM +, maqiufang (A) wrote:
>
> Regarding open #3, it is natural for the clients to believe that what they
> read back from the server is exactly what they sent to the server.
> If there is a "system client" playing a role, this would require some extra
> handl
Hi, all
I agree that option #1 will overwhelm a client severely.
Avoid-copying and client-control over written in the introduction of
draft-ma-netmod-with-system-00 are actually two competing objectives, if the WG
thinks offline-validation of alone IS required,
I think we need to make a compr
Hi, Jason,
Thanks for your comments, please see my reply inline.
From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.ste...@nokia.com]
Sent: Thursday, December 9, 2021 6:42 AM
To: maqiufang (A) ; netmod@ietf.org
Subject: RE: [netmod] "immutable" flag
Hi Qiufang,
I think there are use-cases fo
Hi, Jason
Thanks for kicking off some discussion around this question.
Please see my reply inline.
From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.ste...@nokia.com]
Sent: Thursday, December 9, 2021 6:51 AM
To: maqiufang (A) ; netmod@ietf.org
Subject: RE: [netmod] Should the "with-origin" par
From: Andy Bierman
Sent: 08 December 2021 17:58
On Wed, Dec 8, 2021 at 9:27 AM tom petch
mailto:ie...@btconnect.com>> wrote:
From: Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>
Sent: 08 December 2021 12:38
tom petch mailto:ie...@btconnect.com>> wr
20 matches
Mail list logo
