Hi Qiufang,
> I think that it is undesirable to support the "with-immutable" request
> parameter on non-configuration datastores. The reason why is that I believe
> the "with-origin" flag is more useful. If the "origin" is "system", then
> immutability is "true".
> Is this true: If the
There are several different cases one can consider and the text in the
description is not particulary clear which ones are covered (due to the
'e.g.' style).
a) Configuring an interface type that is not supported by the
firmware / operating system.
b) Configuring an interface type that is
> Where in the NC or YANG RFCs do we talk about immutable data? Where in
> the interfaces data model do we define that the type leaf becomes
> immutable once a line card has been plugged into a slot?
Following is from RFC 7223. Note that the description statement almost says
that the value is
On Wed, Apr 26, 2023 at 12:04:41PM +, Kent Watsen wrote:
> Hi Jürgen,
>
> > I am not sure I follow. If I replace the line card, I may have to
> > update the type of the interface config. Why would this be disallowed?
>
> Nothing is being disallowed, by this proposal. There is no new server
Hi Jürgen,
> I am not sure I follow. If I replace the line card, I may have to
> update the type of the interface config. Why would this be disallowed?
Nothing is being disallowed, by this proposal. There is no new server
behavior. The proposal only enables a server to programmatically
Hi, Kent
I support ensuring XC/Y remains transactional, such that a client can always
move from valid config-A to valid config-B in a single update. I also support
requiring a "with-immutable" flag in client-requests in order for the
"immutable" annotations to be returned (like
nt Watsen
> 发送时间: 2023年4月25日 19:53
> 收件人: Jürgen Schönwälder
> 抄送: maqiufang (A) ; netmod@ietf.org;
> Jan Lindblad (jlindbla)
> 主题: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
>
>
> Hi Jürgen,
>
>> My assumption so far is that an interface configur
Hi Andy,
> I hope the immutable flag will work with non-NMDA as well as the current NMDA.
Yes.
A non-NMDA server can still:
Present YANG modules having the "immutable" extension statements. It's up to
the clients if they understand it and, if not, then nothing changes.
Return the
On Tue, Apr 25, 2023 at 6:15 AM Jürgen Schönwälder
wrote:
> On Tue, Apr 25, 2023 at 12:46:05PM +, Kent Watsen wrote:
> >
> >
> > > Which merge fails?
> >
> > + =
>
> So far this merge step does not exist (and it may be bad if it would
> exist). The WGs need to think very careful about
On Tue, Apr 25, 2023 at 12:46:05PM +, Kent Watsen wrote:
>
>
> > Which merge fails?
>
> + =
So far this merge step does not exist (and it may be bad if it would
exist). The WGs need to think very careful about introducing such a
step and the consequences.
/js
--
Jürgen Schönwälder
> Which merge fails?
+ =
> If the mac-addr in running does not match the
> hardware (and it has to match according to the model), then the
> interface config simply will not be applied.
Maybe that’s the answer. I was thinking that just the ‘key’ fields were used
to “match the hardware”.
On Tue, Apr 25, 2023 at 11:52:32AM +, Kent Watsen wrote:
>
> Hi Jürgen,
>
> > My assumption so far is that an interface configuration is matched
> > against hardware and it is applied if there is matching hardware. In
> > other words, if an edit makes the interface configuration not match
>
Hi Jürgen,
> My assumption so far is that an interface configuration is matched
> against hardware and it is applied if there is matching hardware. In
> other words, if an edit makes the interface configuration not match
> the hardware anymore, then the config is simply not applied anymore
> and
On Mon, Apr 24, 2023 at 08:50:02AM +, maqiufang (A) wrote:
>
> 2) The "immutable" YANG extension statement (not the metadata annotation)
> designates, at the schema-level, config=true nodes that, when present in
> , are system-defined and hence immutable.
> Note that NMDA does allow clients
Hi Qiufang,
> I support ensuring XC/Y remains transactional, such that a client can always
> move from valid config-A to valid config-B in a single update. I also
> support requiring a "with-immutable" flag in client-requests in order for the
> "immutable" annotations to be returned (like
is immutable.
Thoughts?
Kent // contributor
Best Regards,
Qiufang
On Apr 17, 2023, at 5:29 AM, maqiufang (A)
mailto:maqiufa...@huawei.com>> wrote:
Hi, Jan
Thank you so much for the follow-up, please see my reply inline.
From: Jan Lindblad (jlindbla) [mailto:jlindbla=40cisco@dm
.
>
> From: Jan Lindblad (jlindbla) [mailto:jlindbla=40cisco....@dmarc.ietf.org]
> Sent: Tuesday, April 11, 2023 10:05 PM
> To: maqiufang (A) mailto:maqiufa...@huawei.com>>
> Cc: Kent Watsen mailto:kent+i...@watsen.net>>; Rob
> Wilton (rwilton) mailto:rwil...@cisco.com>>
; Rob Wilton
(rwilton) mailto:rwil...@cisco.com>>;
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
Qiufang,
Thank you for your continued work on this. I think the critical point to decide
now is which use cases are in and wh
>>
Cc: Jan Lindblad (jlindbla)
mailto:jlindbla=40cisco@dmarc.ietf.org>>;
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
Hi Rob,
My prior response to you focused on what the draft specifies (not the liaison)
(rwilton) mailto:rwil...@cisco.com>>
Cc: Jan Lindblad (jlindbla)
mailto:jlindbla=40cisco@dmarc.ietf.org>>;
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
Hi Rob,
My prior response to you focused on what t
gt; To: Rob Wilton (rwilton) <mailto:rwilton=40cisco@dmarc.ietf.org>>
> Cc: Jan Lindblad (jlindbla) <mailto:jlindbla=40cisco@dmarc.ietf.org>>; netmod@ietf.org
> <mailto:netmod@ietf.org>
> Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag
:23
To: Rob Wilton (rwilton)
Cc: Jan Lindblad (jlindbla) ;
netmod@ietf.org
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
Hi Rob,
- In terms of properties that cannot be changed once written, I would rather
see this issue framed more in the direction of it just being extra
Hi Rob,
> - In terms of properties that cannot be changed once written, I would rather
> see this issue framed more in the direction of it just being extra
> documentation written in a machine-readable way. Specifically, using the
> annotation to give an indication that servers MAY reject
Hi,
I think that we need to be careful here. In summary, I agree with a lot of the
concerns flagged by Jan, both in ensuring that we don't break existing
NETCONF*/YANG configuration paradigms (*, by NETCONF, I mean NETCONF or
RESTCONF), but also the approach of considering the best long-term
24 matches
Mail list logo
