On Mon, Dec 13, 2021 at 6:55 PM Kent Watsen wrote:
> Hi Andy,
>
> I do not have any problem with containing active and inactive
> nodes.
> That's what has been in place for over 10 years. That's what is written in
> NMDA.
>
>
> For posterity, it’s been “in place” only in proprietary
On Mon, Dec 13, 2021 at 5:31 PM Kent Watsen wrote:
>
>
> On Dec 8, 2021, at 5:50 PM, Andy Bierman wrote:
>
> Andy - about use cases. Here is a problem we're trying to address:
>>
>>
>>
>> There are at least several major router implementations that have
Hi,
On Mon, Dec 13, 2021 at 4:43 PM Kent Watsen wrote:
>
> Hi Jason,
>
>
> I'm not following your "In the meanwhile" thoughts.
>
> Legacy clients are failing offline validation today. If running config has
> a leafref to system config, and doesn't return that system
> config (which it
On Mon, Dec 13, 2021 at 3:44 PM Kent Watsen wrote:
> Juergen/Andy,
>
>
> Option #3
>>
>> There is a client on the system that makes changes to running just
>> like any other remote clients can make changes to running. System
>> generate config that is not editable explicit config in running goes
e a new datastore and rewrite YANG to use a new datastore.
>
> Jason
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:* Wednesday, December 8, 2021 5:50 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa)
> *Cc:* Juergen Schoenwaelder ; Jan
> Lindblad ; Kent Watsen ; maqiufang
what was sent previously.
>
>
>
> I think we have a potential solution for this system config that keeps the
> running valid. But I'm far more worried about configuration templates. I
> don't see how we can possibly keep valid with config templates.
> That seems like a major pr
On Wed, Dec 8, 2021 at 9:27 AM tom petch wrote:
> From: Ladislav Lhotka
> Sent: 08 December 2021 12:38
>
> 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
On Fri, Dec 3, 2021 at 2:26 AM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:
> On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote:
>
> > I made some proposals earlier, both on the interim and privately to the
> draft authors, along these lines:
> >
> > Option #1
> >
On Mon, Nov 29, 2021 at 3:49 PM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:
> On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote:
> >
> > IMO the least disruptive solution possible should be used.
> > There is a use-case
On Mon, Nov 29, 2021 at 2:49 PM Kent Watsen wrote:
> Hi Andy,
>
> > RFC 7950 rules about leafref validation are very clear.
> > Adding a new datastore to these rules requires a massive change to NMDA
> > and all implementations.
>
> Not really or, rather, it seems like it would be just part of
On Thu, Nov 25, 2021 at 5:02 AM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:
> The way to resolve things is to use name bindings. I can configure the
> interface "lo" in running by refering to this interface by name. If
> there is no "lo" in the system, then the config gets
On Mon, Sep 27, 2021 at 10:42 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:
> Hi -
>
> On 2021-09-27 10:13 AM, Andy Bierman wrote:
> ...
> > SNMP GetNext and GetBulk do not handle missing nodes well at all, so it
> > became
> > common practice
On Mon, Sep 27, 2021 at 9:21 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> Hi all,
>
> Reserving a "magic value" like -1 may be workable, but it doesn't feel
> like a terribly good fit into YANG. The rest of the range of integer values
> are valid and it seems odd to
On Wed, Sep 15, 2021 at 8:44 AM Balázs Lengyel
wrote:
> Hello Rob,
>
> I can live with this, if Andy accepts.
>
This is OK
> Regards Balazs
>
Andy
>
>
> *From:* Rob Wilton (rwilton)
> *Sent:* 2021. szeptember 15., szerda 11:57
> *To:* Andy Bierman
s the cost of getting this document to the IESG, I can
> accept the data-type. Please decide, so we can move forward.
> I am willing to have a conference, would you arrange it?
>
> Regards Balazs
>
>
>
> *From:* Rob Wilton (rwilton)
> *Sent:* 2021. szeptember 13., hétfő 12:05
>
On Fri, Sep 10, 2021 at 5:15 AM Balázs Lengyel
wrote:
> See below as BALAZS4
>
>
>
> *From:* Andy Bierman
> *Sent:* 2021. szeptember 10., péntek 4:57
> *To:* Balázs Lengyel
> *Cc:* Rob Wilton (rwilton) ; NetMod WG >
> *Subject:* Re: [netmod] yang-insta
On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:
> Hi -
>
> On 2021-09-10 9:42 AM, Andy Bierman wrote:
> > Hi,
> >
> > Maybe the use of [null] in RFC 7951 is confusing people
> > https://datatracker.ietf.org/
Hi,
Maybe the use of [null] in RFC 7951 is confusing people
https://datatracker.ietf.org/doc/html/rfc7951#section-6.9
Andy
On Fri, Sep 10, 2021 at 9:26 AM tom petch wrote:
> From: Jürgen Schönwälder
> Sent: 10 September 2021 17:18
> To: tom petch
> Cc: netmod@ietf.org
> Subject: Re:
On Fri, Sep 10, 2021 at 5:15 AM Balázs Lengyel
wrote:
> See below as BALAZS4
>
>
>
> *From:* Andy Bierman
> *Sent:* 2021. szeptember 10., péntek 4:57
> *To:* Balázs Lengyel
> *Cc:* Rob Wilton (rwilton) ; NetMod WG >
> *Subject:* Re: [netmod] yang-insta
On Thu, Sep 9, 2021 at 6:19 AM Balázs Lengyel
wrote:
> Hello Andy,
>
> See below as BALAZS3.
>
>
>
> *From:* Andy Bierman
> *Sent:* 2021. augusztus 25., szerda 18:29
> *To:* Balázs Lengyel
> *Cc:* Rob Wilton (rwilton) ; NetMod WG >
> *Subject:* Re: [netmod]
On Thu, Sep 9, 2021 at 4:51 AM Balázs Lengyel
wrote:
> Hello Andy,
>
> See below as BALAZS2.
>
>
>
> *From:* Andy Bierman
> *Sent:* 2021. augusztus 24., kedd 13:35
> *To:* Balázs Lengyel
> *Cc:* Rob Wilton (rwilton) ; NetMod WG >
> *Subject:* Re: [netmod]
ance-data-set.
>
> As this is not a live server request/reply situation we do not want to
> specify a basic and additional modes, we just want to specify the handling
> used for this specific instance data set.
>
>
>
> Regards Balazs
>
>
>
> *From:* Andy Bierman
L representation is used for. The mode used to write the data will
correspond to the basic-mode with the same name.
>
> Regards Balazs
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:* 2021. augusztus 23., hétfő 18:58
> *To:* Balázs Lengyel
> *Cc:* Rob Wilton (rwilton) ; Ne
r
reported.
This mode means the server does not consider any node to be a default and
always returns
every node (if with-defaults used or not).
> This is the reason I used the SHOULD word.
>
> Regards Balazs
>
>
Andy
>
>
> *From:* Rob Wilton (rwilton)
> *Sent:* 202
Hi,
I guess I do not agree with the premise of the draft, which is that the
client
needs to take over control of the system-controlled configuration. I will
wait for a draft update and see if that helps understand it better.
Andy
On Tue, Aug 17, 2021 at 11:21 AM Kent Watsen wrote:
>
> >IMO
On Sun, Aug 15, 2021 at 12:49 PM Kent Watsen wrote:
>
> It was a different email I think proposing extensions instead of a
> datastore.
>
>
> This email:
> https://mailarchive.ietf.org/arch/msg/netmod/SHRPSxHIDxsfF2t0GXXiyFHOnGw/
>
>
What is the purpose of system-configuration
Use-case A)
On Fri, Aug 13, 2021 at 2:02 PM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> Hi Andy,
>
> Pls see inline.
>
> Jason
>
>
>
> *From:* Andy Bierman
> *Sent:* Monday, August 9, 2021 6:23 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa
t could exist.
The premise is that the server could have created these nodes
but it did not for some reason. And the client can inspect these nodes and
somehow
force the server to change the nodes it adds to . (So what is the
real use-case then?)
Retrieving the system-created nodes with origin=syst
On Wed, Aug 4, 2021 at 6:39 AM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:
> The figure in RFC 8342 section 5 documents what was agreed upon
> before. System configuration flows into but not upwards
> into . Over the years, we discussed several corner cases
> (including
> 收件人: Fengchong (frank)
> 抄送: Andy Bierman ; Kent Watsen ;
> Balázs Lengyel ;
> netmod@ietf.org
> 主题: Re: [netmod] 答复: system configuration sync mechanism
>
> On Tue, Aug 03, 2021 at 01:45:40AM +, Fengchong (frank) wrote:
> > Hi andy and all.
> >
> > I don’t
On Mon, Aug 2, 2021 at 3:31 PM Kent Watsen wrote:
>
> Hi Balazs, Andy, Quifang,
>
> I agree a new datastore will just add complexity without any value.
> Your solution approach is better, but I think it would require a new YANG
> version
> to allow config node XPath to reference non-config
On Sat, Jul 31, 2021 at 9:26 AM Balázs Lengyel wrote:
> Hello,
>
> Sorry for going back to the basics, but IMHO it is needed here. So as I
> see understand the problem:
>
> The purpose of the draft and some principles should be clearly stated. In
> my view:
>
>
>
> *P1) “There is a need to
RFC.
The solution to this NMDA problem is to report the unknown leaf with an
attribute that indicates "no-data".
Otherwise a missing leaf with a YANG default will be incorrectly
interpreted as an "in-use" value.
> Regards,
>
> Rob
>
>
>
Andy
>
>
>
;
> default value specified by any corresponding
>
> ‘default’ statement specified in the YANG schema.”;
>
> }
>
>
>
> With this, I’m not sure whether we need the “includes-default” leaf
> currently specified in the draft, but if we do, then I would think that
&
ot;trim" if it is missing.
Andy
Note, I used the term *producer*, as IMHO the above is true in all cases
> whether the server produces the file or some design activity creates the
> server.
>
> Regards Balazs
>
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Se
On Thu, Jul 8, 2021 at 2:45 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-nmda-diff-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses
excluded from the
> content
>
> data.
>
>
>
> When set to false, data nodes with default value are not filtered,
> and
>
> may appear in the content data.”
>
> }
>
>
>
> Would this satisfy your concern?
>
>
>
> Regards,
>
in the content for this draft are useless.
Any leaf that contains the default value could be a default but it is not if
it was set by a client. The 'default' attribute must be added to the node
to
identify it as a reported default.
https://datatracker.ietf.org/doc/html/rfc6243#section-6
&
form a loop, then the reader
will
not be able to find the file that has the Simplified Inline or Inline info.
That is clearly the fault of the writer, not the reader.
Regards Balazs
>
Andy
>
>
> *From:* netmod *On Behalf Of *Balázs Lengyel
> *Sent:* 2021. július 9., péntek
Original Message-
> > From: Juergen Schoenwaelder
> > Sent: 08 July 2021 11:35
> > To: Balázs Lengyel
> > Cc: Andy Bierman ; Rob Wilton (rwilton)
> > ; netmod@ietf.org; Benoit Claise
> >
> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file
Hi,
The module has this object:
leaf includes-defaults {
type enumeration {
enum report-all {
value 1;
description
"All data nodes SHOULD be included independent of
any default values.";
}
enum trim {
blish the file containing the YANG package schema
> (presumably somewhere in IANA), and it not obvious to me that adding the
> dependency on the URL is really as helpful.
>
> Regards,
> Rob
>
>
> > -Original Message-
> > From: Juergen Schoenwaelder
> > Sen
by
another tool).
Regards Balazs
>
>
>
Andy
> *From:* Andy Bierman
> *Sent:* 2021. július 6., kedd 21:28
> *To:* Juergen Schoenwaelder ; Andy
> Bierman ; Rob Wilton (rwilton) ;
> Balázs Lengyel ; netmod@ietf.org; Benoit
> Claise
> *Subject:* Re: AD review of draf
On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> w
On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> >
> > IMO the 4 separate ways to identify the schema are 3 too many, but that
> > is what the WG wants.
On Tue, Jul 6, 2021 at 8:14 AM Rob Wilton (rwilton)
wrote:
> Hi Balazs,
>
> To follow up with our conversation earlier. Andy and Juergen explicitly
> copied because they may have previously commented on these issues during WG
> LC.
>
> I think that my comment regarding the "feature statement"
On Fri, Jul 2, 2021 at 5:59 AM Shwetha Bhandari via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Shwetha Bhandari
> Review result: Has Nits
>
> I have reviewed this document as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
>
Hi,
I have many concerns about the actual deployment of this draft.
It is well-written and very careful and complete in its coverage of the
issues.
The problem is increased complexity and confusion.
The extension procedures will greatly increase the busy work that YANG
authors
are expected to
Hi,
I tried to get a couple companies interested in this draft but it did not
really work for them.
There is low demand for an NMDA diff but high demand for a more general
"YANG data compare" operation.
The main issues raised were:
1) can only compare 2 datastores
Want to compare a
erminology, since only schema nodes can be augmented.
>
>
>
> *>From:* Anima anima-boun...@ietf.org *On Behalf Of *Andy Bierman
> >An enumeration type is hard-wired.
>
> Hardwired in terms of a fixed definition of values for the enum in RFC
> 8366?
>
>
>
> >No
following this specific issue.
I was just pointing out that YANG enumeration types cannot be augmented.
It is the wrong terminology, since only schema nodes can be augmented.
> *>From:* Anima anima-boun...@ietf.org *On Behalf Of *Andy Bierman
> >An enumeration type is hard-wired.
On Wed, Jun 16, 2021 at 3:45 PM Kent Watsen wrote:
>
> Hi Michael,
>
> New assertion type for the voucher necessary for
> agent-proximity. Likely to enhance the enum in the YANG module for the
> voucher in [RFC
> 8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3)
>
>
> Kent, how do
;
Andy
>
> > -Original Message-
> > From: Kent Watsen
> > Sent: Monday, June 14, 2021 1:17 PM
> > To: Andy Bierman
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) ;
> > netmod@ietf.org
> > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 20
On Mon, Jun 14, 2021 at 9:38 AM Kent Watsen wrote:
>
>
> > Good thing we are not discussing YANG-next...
>>
>> Sarcasm? ;)
>>
>
> No. The NETMOD WG has repeatedly decided not to produce a new YANG language
> version in which the yang-version string is changed.
>
>
> That’s not possibly true.
On Mon, Jun 14, 2021 at 3:34 AM Kent Watsen wrote:
>
>
> > Good thing we are not discussing YANG-next...
>
> Sarcasm? ;)
>
No. The NETMOD WG has repeatedly decided not to produce a new YANG language
version in which the yang-version string is changed.
> I do wonder if it’s not about time we
ndirectly (e.g. YANG extensions) will fail
in the long run.
Good thing we are not discussing YANG-next...
>
> Jason
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:* Tuesday, June 8, 2021 1:49 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa)
> *Cc:* netmod@ie
On Tue, Jun 8, 2021 at 10:39 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> YANG Versioning Weekly Call Minutes - 2021-06-08
>
>
>
> Submodule vs Module in module versioning draft:
>
> - avoid 'artifact', put "submodule or module" everywhere it is applicable
>
> - Reshad:
names and revision dates. This
strategy is
not helpful to client developers because they cannot easily reuse code
across server platforms.
I agree that a revision-label helps in the case where "foo@datestring" is
only unique
within a certain proprietary context (like per-platform varia
On Tue, Jun 1, 2021 at 6:36 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> Hi all,
>
>
>
> In our YANG versioning work we are proposing that a revision-label is
> unique and the revision history of a module must not contain the same
> revision-label twice.
>
>
>
> We're
his case the data node
> cannot be marked as not-supported
>
>
>
This is a different issue.
Server capabilities specific to a data model should be handled in a related
module.
Italo
>
>
>
Andy
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* mercoledì
On Wed, May 19, 2021 at 10:12 AM Italo Busi wrote:
> We have got a question about how to deal with YANG optional data nodes and
> in particular how can a client know which optional data node has been
> implemented by a server.
>
>
>
> We think that there is no issue with config=false data nodes.
On Thu, Apr 22, 2021 at 2:07 AM Vladimir Vassilev <
vladi...@lightside-instruments.com> wrote:
>
> On 21/04/2021 17.10, Andy Bierman wrote:
> >
> > IMO mandatory-stmt has no meaning for config=false.
>
> This is not spelled out in the current version of YANG. Inste
G standard.
> Regards Balazs
>
Andy
>
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 2021. április 21., szerda 12:32
> To: Balázs Lengyel
> Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa) <
> jason.ste...@nokia.com>; netmod@ietf.org
> Subject:
at does a mandatory=true statement
> mean
> > for a config=false leaf in your interpretation?
> >
> > ---
> > IMHO we never stated that
> >
> >
> > Regards Balazs
> >
> > -Orig
rt for warnings would help real implementations right now.
It was a mistake to remove (rather than fix) warnings in NETCONF (and
now also RESTCONF).
> Regards Balazs
>
>
>
Andy
> *From:* netmod *On Behalf Of *Sterne, Jason
> (Nokia - CA/Ottawa)
> *Sent:* 2021. április
2 separate YANG compatibility tracks,
one called YANG 1.1 and another for "NBC-capable YANG". As if routinely
breaking
backward compatibility was a good thing
Regards Balazs
>
>
Andy
>
>
> *From:* netmod *On Behalf Of *Sterne, Jason
> (Nokia - CA/Ottawa)
> *Sent:* 202
On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> YANG Versioning Weekly Call Minutes - 2021-04-13
>
>
>
> Primary discussion was around the BC/NBC rules for state.
>
>
>
> Value space for config false:
>
> - more informative if you actually
On Fri, Apr 9, 2021 at 7:19 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> Creating lots of special rules makes me feel uncomfortable. Is there
> evidence that people reduce state value spaces a lot and in isolation,
> i.e., they just rev a module to reduce some state
On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote:
> Hi Eric,
>
> thanks for the answer.
>
> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
> wrote:
>
> > Hi Michal,
> >
> > This sounds like a tooling issue to me. I would expect that any augments
> > would inherit the conditional
On Fri, Apr 2, 2021 at 10:23 AM Acee Lindem (acee) wrote:
> Hi Tony,
>
> I would argue that YANG is a data modeling language. Another disadvantage
> of the bits type that it isn't augmentable with new bits. Hence, usage of
> unused bits requires a new version of the module as opposed to an
>
On Tue, Mar 30, 2021 at 10:22 AM Martin Björklund wrote:
> Hi,
>
> "Sterne, Jason (Nokia - CA/Ottawa)" wrote:
> > Hi guys,
> >
> > Let's take this model for a leaf (line numbers for reference):
> >
> > 10 leaf foo {
> > 20 type uint8 {
> > 30range "5..101";
> > 40 }
> > 50 }
>
On Fri, Mar 19, 2021 at 2:23 AM tom petch wrote:
> From: Andy Bierman
> Sent: 18 March 2021 18:02
>
> On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk dfe...@labn.net>> wrote:
> So you are saying I should beat up on the tool chain people that have not
> followed the sp
e get confused with
similar terms in the YANG RFC.
RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to
the IETF, not other organizations.
Regards,
>
> Don
>
Andy
>
>
On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk wrote:
> Clarity and consistency would help.
>
> Many of the supporting tool chains are picky about prefixes. IE they must
> be the same as in the definition file. I have a case where yanglint wants
> "local prefixes or derived-from(-or-self)
Hi,
Addressing only point 3 below...
Some article in the 90s claimed that RMON was going to replace SNMP.
RMON is just another set of MIB modules. It does not extend or replace SNMP.
It is SNMP. (pet peeve of former RMONMIB WG Chair).
Most of the RMON RFCs were widely deployed, but not all of
a in some IETF modules.
YANG has deviations so vendors can change the modules from other
organizations
without hacking the original modules.
Andy
> On Wed, 17 Mar 2021 at 18:21, Andy Bierman wrote:
>
>>
>>
>> On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev <
>>
On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev <
vladi...@lightside-instruments.com> wrote:
>
> On 16/03/2021 13.36, Vladimir Vassilev wrote:
> > Hei,
> >
> > Many drafts and RFCs are flagged with warnings by the tracker
> > validation tools:
> >
> > ...
> > yanglint SO 1.6.7: yanglint
>>
>> Given this, I think that the authors can apply the mark ups based on the
>> agreements below (and my original nits), republish, and then hopefully we
>> should be ready to progress this to IETF LC.
>>
>>
>>
>> Regards,
>> Rob
>>
>>
>
On Wed, Mar 10, 2021 at 11:24 AM Italo Busi wrote:
> Hi Jurgen,
>
> Now I can understand your concerns :)
>
> > If all clients are in an
> > NMDA world, the issue is much smaller - it is reduced to "does the client
> > believe the server has a bug or not".
>
> Yes, I was assuming that all the
pplied configuration if the other client had
>> explicitly configured the value 10 in the running DS.
>> >>
>> >> The only difference would be that when the value 10 is explicitly
>> configured by the other client the origin is set to intended while when
>> “implicitly
>
Read sec. 7.6.1 again, especially this part:
When the default value is in use, the server MUST operationally
behave as if the leaf was present in the data tree with the default
value as its value.
Your proposal violates this MUST because the default is in use
according to the rule
On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> Changing the semantics of a definition via augments is bad design.
>
> A system that does not understand the augment will believe the default
> is 0. Since there is no way to force an existing
On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka
wrote:
> On 09. 03. 21 17:58, Andy Bierman wrote:
> >
> >
> > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka > <mailto:ladislav.lho...@nic.cz>> wrote:
> >
> > Italo Busi mailto:italo.b...@huawei.c
it is a
WG decision.
It does not seem that there are any objections to making this change.
Regards,
>
> Rob
>
>
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:* 05 March 2021 16:36
> *To:* Rob Wilton (rwilton)
> *Cc:* joel jaeggli ;
> draft-ietf-netmod-nmda-diff
lease see [RW] inline below …
>
>
>
>
>
> *From:* Andy Bierman
> *Sent:* 30 October 2020 01:43
> *To:* joel jaeggli
> *Cc:* Rob Wilton (rwilton) ;
> draft-ietf-netmod-nmda-diff@ietf.org; netmod@ietf.org
> *Subject:* Re: AD review of draft-ietf-netmod-nmda-
> > Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> > > Subject: Re: [netmod] type equivalence
> > >
> > > Andy Bierman wrote:
> > > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund
> > > wrote:
> > > >
> > > > > &qu
On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund wrote:
> "Rob Wilton \(rwilton\)" wrote:
> >
> >
> > > -Original Message-
> > > From: netmod On Behalf Of Juergen
> Schoenwaelder
> > > Sent: 24 February 2021 20:39
> > > To: netmod@ietf.org
> > > Subject: Re: [netmod] type equivalence
>
On Fri, Feb 26, 2021 at 3:45 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Fri, Feb 26, 2021 at 11:31:58AM +, Rob Wilton (rwilton) wrote:
> >
> > I also note that draft-ietf-netmod-yang-module-versioning-02 states:
> >
> >This document updates [RFC7950]
On Thu, Feb 25, 2021 at 10:00 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Thu, Feb 25, 2021 at 05:10:21PM +, Rob Wilton (rwilton) wrote:
> >
> > Since the YANG module versioning draft clarifies the BC/NBC rules,
> perhaps we could add text to clarify this in
On Wed, Jan 20, 2021 at 8:41 AM tom petch wrote:
> Juergen, Lada, Martin, Andy
>
> I wonder if one of you, or perhaps another on this list, would be willing
> to give advice on the
> structuring of the YANG module for DHCP. It has been revised and
> restructured several times and, to me, is
rian
>
Andy
>
> -Original Message-
> From: netmod On Behalf Of Juergen Schoenwaelder
> Sent: 23 December 2020 18:09
> To: Andy Bierman
> Cc: NetMod WG Chairs ; NETMOD Group
>
> Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
>
> On
hat the senior IETF people mentioned as
> co-authors or contributors, who are very well familiar with the
> relevant history (Benoit Claise, Andy Bierman, Alex Clemm), would have
> explained here (or in the document) why this approach to create an
> interoperable standard for ECA has pot
hat the senior IETF people mentioned as
> co-authors or contributors, who are very well familiar with the
> relevant history (Benoit Claise, Andy Bierman, Alex Clemm), would have
> explained here (or in the document) why this approach to create an
> interoperable standard for ECA has pot
On Wed, Dec 23, 2020 at 3:14 AM tom petch wrote:
> From: netmod on behalf of Dhruv Dhody <
> dhruv.i...@gmail.com>
> Sent: 21 December 2020 17:12
>
> Hi Lou, WG,
>
> I find the motivation in the Introduction to be focused on ECA at the
> network devices (with all the talk about issues with
;
> we're still missing responses from:
>
> Qin Wu
> Benoit Claise
> Andy Bierman
>
> Thanks,
>
> Lou
>
> On 12/7/2020 8:46 PM, Qin Wu wrote:
> >
> > Hi, Lou:
> >
> > Does forwarding confirmation from the authors to the list count?
> >
n. Although not a good practice, in this case the
"import-without-revision"
semantics are not changed if an extension is used to restrict the search
for the import.
>
>
> Jason
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:* Saturday, December 12, 2020 10:39 AM
> *To
On Sat, Dec 12, 2020 at 5:47 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> If module A imports from module B, then the question whether a change
> in module B is compatible or not for module A is answered by what
> module A actually uses of module B's definitions. The
"No, I'm not aware of any IPR that applies to this draft"
Andy
On Mon, Nov 23, 2020 at 3:02 PM Kent Watsen wrote:
> Authors,
>
> Per the 109 session, it is the chairs intent to do another adoption call
> on the "yang-node-tags” draft. In preparation for that, we’ve determined
> both that the
On Thu, Nov 19, 2020 at 9:51 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:
> Hi all,
>
>
>
> RFC8808 talks about a use-case where a network element first comes from
> the factory.
>
>
>
> Would it also make sense to use the factory default configuration in a
> scenario
On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli wrote:
> Rob,
>
> These seem like reasonable suggestions.
>
> Lets see what the authors say.
>
> Thanks for this
> joel
>
> On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton)
> wrote:
>
>> Hi,
>>
>> Here is my AD review for
201 - 300 of 1100 matches
Mail list logo
