[netmod] Re: Yang Scalability

[Jan Lindblad (jlindbla)]

Deepak,

Thank you for your presentation yesterday. Even if it was severely compressed, 
I think the basic message got across, and I browsed through your presentation. 
Scaling is certainly an interesting topic for many of us.

Scaling any solution will always require some forethought, care and iteration, 
but I would not consider 30k interfaces or 30k of any kind of object as 
remarkable under YANG-based management. Lots of operators are managing such 
networks today using YANG-based tools, and some would consider 30k outright 
tiny as they are dealing with millions of objects under control by a single 
YANG-based server.

Obviously, it makes sense to model things using templates to capture the 
similarity between large groups of objects, if that is a common situation with 
your use cases. It may also make sense to organize your objects into 
hierarchies for easier navigation and separation of concerns. If the 
ietf-interfaces module doesn’t do that the way you need, you (or BBF) is free 
to build your own independent or augmenting model that is better suited to your 
goals. YANG-mount and similar techniques may or may not be needed or ideal for 
this.

On the topic of validation using must- and when-expressions, you state that 
“For very large data stores, performance collapses far below practical levels 
!” I would argue that this is an implementation issue rather than something 
that should concern the NETMOD WG. The YANG language allows you to describe the 
constraints of your data structure, but it does not prescribe any particular 
approach to how it should be validated. Many implementations will use an XPath 
evaluation engine to validate these expressions, and that is fine and great in 
most cases. But as you say, when data sets grow, naïve XPath evaluation will 
often not scale. For those cases, you will need to implement the validation in 
a smarter way in your server.

I’d be happy to join a discussion with you on this topic. Either privately or 
as an IETF side meeting, or whatever, if others are interested. In that 
discussion, I think we should rephrase the vague term “YANG scalability”, which 
is used a lot in the presentation, with something that clarifies if the issue 
is about

i)The YANG language itself

ii)  Specific YANG modules (by NETMOD, other IETF WGs, other 
SDOs or vendors)

iii)Implementations of those YANG-based management interfaces

Thanks for bringing up this topic.

Best Regards,
/jan

From: Deepak Rajaram (Nokia) 
Date: Tuesday, 23 July 2024 at 10:53
To: netmod@ietf.org 
Subject: [netmod] Yang Scalability
Dear all

Thanks for the opportunity to present on yang scalability, this is a follow-up 
after having briefly introduced the real-life YANG scalability and performance 
challenges layed out in the Broadband Forum liaison.

I would encourage NETMOD participants to go over the slides in the meeting 
materials section of ietf-120/netmod. 
slides-120-netmod-10-bbf-liaison-on-management-at-scale-projects

Short summary:

Based on studies conducted by several Broadband Forum meeting participants, it 
is found that existing standard YANG implementations do not scale up to 
configurations that contain a very high number of interfaces; for instance in a 
Passive Optical Network, a single Optical Line Termination (OLT) can easily 
surpass 30.000 interfaces (i.e. a few per Optical Network Unit). This is a real 
challenge for network deployments. We are seeing scaling challenges in terms of 
datastore sizes and datastore manipulations (slow configuration, slow data 
retrieval).

While a PON network is taken as an example, it’s more than likely this scaling 
challenge will find its way to other parts of networks as products and industry 
evolves.

We believe this is something NETMOD needs to address with urgency.

As a result of the study, to address such scalability issues, few salient 
points were analyzed and translated into following requirements:


1.  “Clustering” data nodes

2.  Reducing datastore size by using shared profiles

3.  Reducing datastore size by using “templates”

Existing ietf-schema-mount (RFC8528) 
and the new draft of full: 
embed 
definitely prove to be useful for certain aspects, including reusability of 
modules as-is. Still, in their current form they fall short for overcoming the 
scalability issues, which we believe can be mitigated using “templates” and 
profiles.

I expect a more detailed ID will be brought forward explaining the proposal of 
templates/profiles. In anticipation of this ID, I would welcome the group to go 
over the slides for more details on the concepts. Any feedback/suggestions are 
more than welcome 

Regards
Deepak

[netmod] Re: YANG Versioning question - namespace version?

[Jan Lindblad (jlindbla)]

Kent,

I was recently asked why YANG module namespaces aren’t versioned.  For example, 
the “1.0” at the end of this URI 
"urn:ietf:params:xml:ns:yang:ietf-crypto-types:1.0”.  The stated concern was 
"because without this, then management of backward compatibility becomes a 
nightmare.”

In the very early days of YANG, we actually had a brief while when the NS 
strings were composed just like that, with a sort of version number at the end.

To know that something is a new/different version of something else you need 
two information elements. Something that indicates “sameness” and something 
that indicates “newness”.

When tracking files in git, the “sameness” typically comes from keeping the 
same filename (even if git can handle file renames if registered properly). In 
YANG, we didn’t want to rely on the filename, since the module filenames are 
not necessarily globally unique, as the thinking went. So the NS string serves 
as the sameness factor, and must therefore not change. Basically, modules with 
different NS strings are (considered) completely unrelated.

To indicate “newness”, we depend on the revision statement in YANG. In the 
Versioning Design Team, we have also been toying around with a checksum to 
indicate newness, but that has not taken root.

Theoretically, it would of course be possible to indicate both things in the NS 
string by appending a version number at the end, but then all clients and 
servers would have to agree on the convention/rule that the characters after 
the last colon in the NS string need to be processed differently. That ship has 
probably crossed the ocean by now, but we could bring it up for YANG next.

But I fail to see why our non-choice of this particular solution would 
necessarily drive us into a nightmare. The necessary information is available 
in the modules, just not in the NS string alone.

Best Regards,
/jan



This convention was established prior to my becoming active in the IETF, but my 
guess is that the reason is because the YANG-module update rules in RFC 7950 
Section 11 ensure backwards compatibility, and hence the versioning the 
namespace would have no value.  That said, the YANG Versioning effort 
introduces the possibility of NBC changes, which makes me wonder if this is 
something that should be discussed.

Thoughts?

Kent



___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Comments on draft-lindblad-tlm-philatelist-01

[Jan Lindblad (jlindbla)]

James,

Many thanks for taking the time to review, and for great suggestions!
Comments inline marked [janl].

From: James Henderson 
Date: Thursday, 6 June 2024 at 19:53
To: netmod@ietf.org 
Subject: [netmod] Comments on draft-lindblad-tlm-philatelist-01
I have a couple of comments and questions on philatelist. Overall, I think this 
is important work, and I’m happy to see someone is working on it!

1)

In access-g it seems there is a reason why an identityref for method, and 
containers with when statements were used instead of a choice with similarly 
named containers.

The obvious awkwardness of configuring something like:

method get-local-url-once
get-static-url-once url https://bogo

vs:

get-static-url-once url https://bogo

I am curious to understand what reasons went into this decision. I suspect it 
was for extensibility to make it easier for someone to expand on the available 
options.

[janl] Exactly. By using a discriminator design (the method leaf) with an 
identity type, plus containers with detailed settings, it will be easy to 
expand this model. It would be easy both to add new variants of the already 
existing methods as well as completely new methods. Let me show an example of 
each.

Example 1: Variant method

Let’s say someone comes up with a variant of the get-local-url-once where the 
document fetched by the URL contains information about many different kinds of 
devices, each under a different section header.

To allow this sort of file to be used, the user would have to additionally 
configure which section should be read in the file pointed to by the URL. To 
add this possibility in YANG, something like the following would be required:

module get-local-url-section-once {
   namespace blabla prefix import …

  identity get-static-url-section-once {
base ietf-tlm-philatelist-types:get-static-url-once;
  }
  augment /ietf-tlm-philatelist-collector:tlm-collector/
ietf-tlm-philatelist-collector:organizations/
ietf-tlm-philatelist-collector:organization/
ietf-tlm-philatelist-collector:device-groups/
ietf-tlm-philatelist-collector:device-group/
ietf-tlm-philatelist-collector:accesses/
ietf-tlm-philatelist-collector:access/
ietf-tlm-philatelist-collector:get-static-url-once {
  when "derived-from-or-self(../method,
'ietf-tlm-philatelist-types:get-static-url-section-once')";
  leaf section-heading {
type ietf-tlm-philatelist-types:something;
  }
}
  }
}

Example 2: Completely new method

Let’s say someone comes up with a completely collection method, e.g. “SNMP v8” 
It could be added like this:

module tlm-snmpv8-subscribe {
   namespace blabla prefix import …

  identity snmpv8-subscribe {
base ietf-tlm-philatelist-types:connection-method;
  }
  augment /ietf-tlm-philatelist-collector:tlm-collector/
ietf-tlm-philatelist-collector:organizations/
ietf-tlm-philatelist-collector:organization/
ietf-tlm-philatelist-collector:device-groups/
ietf-tlm-philatelist-collector:device-group/
ietf-tlm-philatelist-collector:accesses/
ietf-tlm-philatelist-collector:access {
  when "derived-from-or-self(method,
'ietf-tlm-philatelist-types:snmpv8-subscribe')";
  // 
}
  }
}

Hope this explains why I did it this way. We may of course decide that we don’t 
need this level of flexibility, or that we can achieve a sufficient level of 
flexibility using some other design. This was just my initial proposal, 
discussion welcome.

2)

For the access-path I noticed that there was not a way to deal with paths that 
may themselves require a literal dollar sign followed by a literal parenthesis. 
While this may not seem like a very likely path, it may be technically possible 
in some systems. I was thinking a more complicated, but also more flexible 
solution would be to use the IETF proposed standard URI Template 
https://datatracker.ietf.org/doc/html/rfc6570

I think this might allow the easier construction of some more complicated URIs, 
and is also simple enough for the usual case, which would be something like:


/if:interfaces/interface[name='{interfaces_interface_name}']/statistics/in-unicast-pkts

However, this solution has the same problem that there seems to be no way to 
escape the braces! However, since literal braces are considered unsafe for URIs 
in general, I think that is the reason, since you can just use percent encoding 
on the braces for a URI.

I think the challenge is that while access-path may often _be_ a URI, it is not 
guaranteed to be so. In addition, adding URI Template as a requirement for any 
implementation does add some challenge although several libraries do exist.

So, I don't think URI Template works unless we can say that the access-path is 
a URI fragment.

Another option might be to simply document that two dollar signs will be 
converted into a single dollar sign, or pick an existing standard template 
language.

[janl] Thanks! I had entirely missed RFC 

[netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt

[Jan Lindblad (jlindbla)]

Qiufang, WG,

Thank you for the effort you put into working out all the wrinkles of system 
config. I read the updated version, and I think it is a significant 
improvement. As usual, I have some comments, questions and suggestions.  In 
order of appearance.

#1 Somewhat unclear conceptual model

Section 5.1 has a nice drawing of how the datastores relate to each other, and 
an introductory text that explains the interactions. The following sections 
explain how data can be copied from system to running, or can be filled in 
automatically using the resolve-system parameter. But the first sentence of 
section 5.1 is

Clients MAY reference nodes defined in , override system-provided 
values, and configure descendant nodes of system-defined configuration in 
.

In my mind, this is only true when the client uses the resolve-system 
parameter. Otherwise, a client cannot reference  directly, but needs to 
copy from  to . So maybe the introductory sentences could be 
reworded?

#2 No way to squelch system config from intended

The software on a device decides what config from  that show up in 
 (i.e. is considered “referenced”). If the client would like 
something not to flow through to , there is no mechanism for that.

Let’s say some device always creates a loopback0 interface in . The 
client can change the loopback0 mtu by configuring it in running, but there is 
no way to entirely remove loopback0. Maybe a stupid example, but let’s say the 
client wants the loopback0 to be called lo0 instead. The same situation would 
arise for anything else in , e.g. some system TPM security credential, 
system traffic classification rule or whatever else people may throw into 
.

Is this a problem? Is this something that should be mentioned so that people 
leveraging  are aware of this limitation?

#3 Still unclear what needs to be copied

In section 5.2 it is explained how a client can copy data from system to 
running. The introduction in section 1 has some bullets about conditions that 
require copying to happen. Section 6 was added with some language about leafs 
with default values that need to be copied. The same need probably also applies 
to presence containers (which are not mentioned anywhere in -06).

All in all, I think the design work around the rules for what needs to be 
copied is hard to grasp in the current version, and is probably incomplete.

Similarly, section 5.3, which deals with what is being copied by resolve-system 
parameter should probably also refer to the same rules, once established.

#4 Resolve-system without 

At the end of section 5.3, there is a sentence about what a system should do if 
it supports resolve-system but not .

If a server implements , referenced system configuration is copied from 
 into the target datastore when the "resolve-system" parameter is used; 
otherwise it is an implementation decision where to copy referenced system 
configuration.

This sentence was a bit confusing to me. After reading it many times, I think 
an alternative text with similar meaning would be

If a server implements , referenced system configuration is copied from 
 into the target datastore when the "resolve-system" parameter is used.

If a system does not implement , it’s up to the implementation to 
determine how the resolve-system mechanism fills in the missing configuration 
items in the target datastore, e.g. .

#5 Example missing ns qualifier

Section 5.5.1 has a nice example of how resolve-system works. But the example 
rpc that is using it is missing the namespace qualifier, I think. Isn’t this 
what it should look like?


  

  


  

  allow-access-to-ftp-tftp
  

  198.51.100.0/24
  192.0.2.0/24

ftp
tftp
my-app-1
  
  forward

  


  


#6 Old value in example

The example in 5.5.3 and 5.5.4 used to change an mtu from 65536 to 65535. Since 
it’s somewhat hard to spot the difference between those values, you replaced 
65535 with 9216. This is great. But I think the old 65535 value is still 
lurking there twice and should be replaced by 9216.

Section 5.5.4 starts with the following sentence.

In the above example, image the client further configures the description node 
of a "lo0" interface in  as follows:

Perhaps “image” should be “imagine”? And maybe it should be mentioned that the 
client is doing a merge, not a replace? How about this?

In the above example, imagine the client further configuring the description 
node of the "lo0" interface in  using a merge operation as follows:

#7 Implied semantics

Section 7.1 describes how the factory-default datastore is meant to be used. It 
is implied that the system datastore is not meant to be used in this situation, 
but it is never mentioned. Perhaps it would be worth mentioning that system is 
not to be used in this way?

#8 Confusing ietf-system-datastore example

The 

[netmod] Re: WGLC on system-config-05

[Jan Lindblad (jlindbla)]

The module example-acl in section 5.5.1 is using underscores _ in names (e.g. 
acl_rule, source_address) where YANG style typically is to use hyphen. Consider 
updating?


#7 NETCONF protocol as example

The example in section 5.5.1 says

   If a client configures an ACL rule referencing system provided
   applications which are not present in , take NETCONF
   protocol for example,

but when you look at the example, I can’t find anything NETCONF related there. 
I think that is good, since using NETCONF as an example here has the potential 
to confuse the reader, but then that sentence probably needs updating.


#8 No before and after in a transaction

The first paragraph in section 5.5.2 introduces an example like this:

   For instance, in the above example, the
   client MAY also explicitly configure the following system defined
   applications "ftp" and "tftp" only with the list key "name" before
   referencing:

In this sentence, I find the use of “before” a bit unfortunate. I am afraid 
some readers may interpret this as meaning that the “ftp” and “tftp” list items 
have to be configured in a separate transaction prior to the one where they are 
being referenced, while in reality they can be added in the same transaction as 
the reference.


Thank you for your efforts authoring this document!

Best Regards,
/jan



From: Lou Berger 
Date: Monday, 29 April 2024 at 23:55
To: Balazs Lengyel , Rob Wilton (rwilton) 
, Jan Lindblad (jlindbla) , Mohamed 
Boucadair 
Cc: Kent Watsen 
Subject: Fwd: [netmod] WGLC on system-config-05

Hi - Time for a little peer pressure.

We, the chairs, would like to ask for your help in reviewing the  system-config 
that is currently in last call.  We are not asking for any specific position or 
opinion, simple that you review the document and then provide a statement of if 
you do/do not support publication.  Of course, technical details support 
objections are most helpful -- and that all comments should be sent to the list.

Thank you so much for your on going, meaningful and important contributions to 
our WG!

Kent and Lou
 Forwarded Message 
Subject:
Re: [netmod] WGLC on system-config-05
Date:
Mon, 29 Apr 2024 17:48:57 -0400
From:
Lou Berger <mailto:lber...@labn.net>
To:
netmod@ietf.org<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>
CC:
Kent Watsen <mailto:kent+i...@watsen.net>


WG,

We'd like to extend this LC for another couple of weeks in the hope that we get 
more feedback from the WG on this document.

Positive comments, e.g., "I've reviewed this document

and believe it is ready for publication", are welcome!

This is useful and important.



Thank you,

Lou and Kent
On 3/29/2024 10:08 AM, Kent Watsen wrote:
This email begins a two-week WGLC on:
System-defined Configuration
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/

Please take time to review this draft and post comments by April 12.  Favorable 
comments are especially welcomed.
There is no known IPR for this document:
https://mailarchive.ietf.org/arch/msg/netmod/IpzWIAbgifXoKaNfLhEDmYbyXkY/
Kent  // co-chair




___

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Re: [netmod] IPR Call on draft-ietf-netmod-system-config-05

[Jan Lindblad (jlindbla)]

No, I'm not aware of any IPR that applies to this draft.
/Jan

On 26 Mar 2024, at 16:40, Kent Watsen  wrote:

My last message didn’t tag all authors and contributors.

This message adds to the “To” line the following additional authors and 
contributors:
- Chong Feng
- Kent Watsen
- Jan Linblad
- Jason Stern

Kent // chair


On Mar 25, 2024, at 9:30 PM, Kent Watsen  wrote:

Authors, Contributors, WG,

As a prerequisite for the WGLC on this document:

System-defined Configuration
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

PS: Currently no IPR is filed for this draft:
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-netmod-system-config.


Thanks.
Kent Watsen (as co-chair)


___
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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Jan Lindblad (jlindbla)]

Andy, very good summary!
/jan

On 15 Mar 2024, at 16:22, Andy Bierman  wrote:



On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>
 wrote:
I wonder which problem we are solving with adding more little rules.
Perhaps a future version of YANG will do away with prefixes but until
this happens, I do not think we need to add more rules about how to
choose prefixes. The original intend was that they are short to keep
YANG snippets concise and easy to read.



This is the IETF Coding Conventions document, not the YANG specification.
Naming conventions are CLRs but often with some benefits.

What problems?

1) If there are multiple modules used in imports then the reader must be able to
easily tell the prefixes apart.  If prefixes are too short and not meaningful, 
this task
gets more difficult.  I find myself constantly going back to the imports to 
make sure
I am matching the prefix to the correct module.

2) If there are complex XPath expressions then prefixes that are too long make 
the
expression unreadable, especially as it is chopped into "string" + "string"  
format
to fit into 72 character lines. If prefixes are too short then back to problem 
(1).

3)  It is becoming more common to have vendor modules import modules from 
multiple SDOs.
Prefix naming conventions are already the BCP everywhere but the IETF.

Is it too late to start for IETF? There are many modules already with no naming 
consistency,
so this would only affect new modules. There will never be consistent naming of 
prefixes
so it may not be worth the change now.



/js


Andy


On Fri, Mar 15, 2024 at 01:02:58PM +, 
mohamed.boucad...@orange.com wrote:
> Hi Andy,
>
> (changing the subject to ease tracking this)
>
> The thread I was referring is: 
> https://mailarchive.ietf.org/arch/msg/netmod/6VkSrroaxwXHSI19Jj0j-tbFCjA/
>
> I do personally think that it is a good guidance to prefix IETF modules with 
> “ietf-“ and IANA-maintained ones with “iana-‘. This is consistent with the 
> practice we followed recently for iana-maintained modules.
>
> If we recommend this prefix pattern, I’m afraid that we need to revisit the 
> text about short prefixes, e.g.,
>
> OLD:
>Prefix values SHOULD be short but are also likely to be unique.
>Prefix values SHOULD NOT conflict with known modules that have been
>previously published.
>
> NEW:
>Prefix values SHOULD be prefixed with “ietf-“ for IETF modules and
>“iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
>too long and SHOULD NOT conflict with known modules that have been
>previously published.
>
> Cheers,
> Med
>
> De : Andy Bierman mailto:a...@yumaworks.com>>
> Envoyé : jeudi 14 mars 2024 22:53
> À : Mahesh Jethanandani 
> mailto:mjethanand...@gmail.com>>
> Cc : BOUCADAIR Mohamed INNOV/NET 
> mailto:mohamed.boucad...@orange.com>>; 
> netmod@ietf.org
> Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis
>
> Hi,
>
> I cannot find this email wrt/ short prefixes
>
>
>   *   (short/uniqueness of prefixes
>
> Other SDOs are using a prefix in their prefixes (e.g. openconfig).
> It is common for servers to have both "if:interfaces" and "oc-if:interfaces" 
> subtrees.
>
> It might be a good idea to have a guideline that all IETF YANG modules SHOULD
> use the "ietf-" string in the module prefix.  This should reduce the chance 
> of name collisions
> between SDOs and vendors, and helps identify the module as an IETF module.
>
>
> Andy
>
>
>
> On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani 
> mailto:mjethanand...@gmail.com>>>
>  wrote:
> Hi Med,
>
> Thanks for driving this effort on updating RFC 8407.
>
> One additional change coming your way, is to address the question of how IANA 
> is supposed to handle updates to IANA YANG modules. The YANG doctors are 
> currently debating those changes. Once agreed, we will bring that discussion 
> here, and will need to update rfc8407bis to provide guidance to authors who 
> update an IANA module. Stay tuned.
>
> Cheers.
>
>
> On Mar 12, 2024, at 5:00 AM, 
> mohamed.boucad...@orange.com>
>  wrote:
>
> Hi all,
>
>
>   *   A candidate -10 is ready to address 3 comments from Jan:
>
>  *   Long trees
>  *   Updated security template
>  *   Minor tweaks to Section 3.8
>  *   The changes circulated on the list can be seen here: Compare 
> Editor's Copy to 
> Datatracker
>
>   *   Jan raised two other comments (short/uniqueness of prefixes + how to 
> handle “not set”) but no changes were made per the feedback received on the 
> list.
>   *   Next steps:
>
>  *   Submit -10 right after IETF#119
>  *   WGLC
>
> Cheers,
> Med
>
> 

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[Jan Lindblad (jlindbla)]

Kent,

Hi Jan, you attended the Interim on Jan 23, and didn’t object to the Minutes 
[1] that say:

 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.

Has something changed since then?

[1] 
https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/

Thanks for keeping me honest :-) Nothing has changed, and if everyone agrees 
that 7950 and 8342 language prevail (i.e. running always valid as well as 
intended always valid), I'm probably ok. I wasn't sure that was the case? But 
if we all agree with this, maybe stating just that wouldn't be a bad thing? 
Just so that this is perfectly clear now and in the future.

I'm not against discussing changes in this area, as long as the fundamental 
values of YANG are preserved and our mechanisms are clearly defined.

Best Regards,
/jan

On Mar 12, 2024, at 12:15 PM, Jan Lindblad (jlindbla) 
 wrote:

Qiufang,

I'm sorry to say I'm strongly against WGLC at this time because of point #2 
below.

One of the great contributions to network automation that YANG has brought is 
that clients now have a fair chance at computing a desired configuration change 
for a network element. Maybe we need to develop a more elaborate model for 
configuration consistency relative today's "The running configuration datastore 
MUST always be valid", but have I trouble with us stirring up multiple 
interpretations and then staying silent. That's not the way to build 
interoperability.

IMO we need to sort out what the rules are before we come close to WGLC, or 
else the grief outweighs the gain.

Best Regards,
/jan

On 12 Mar 2024, at 03:44, maqiufang (A) 
 wrote:

Hi, chairs,

For system-config draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), the 
authors have submitted a new version to reflect the outcome of the interim, the 
main updates are following:
1.  Address the "origin" issue
a.   The current document explicitly states that system configuration 
copied from  into  have its origin value being reported as 
"intended" and update the examples accordingly
b.  Also, update the definition of "intended" origin identity in 8342 to 
allow a subset of configuration in  to use "system" as origin value
c.   The current document states data migration is out-of-scope except that 
gives a couple of implementation examples in section 4.2 (please feel free to 
propose text if you have better suggestion)
2.  validity of  alone
a.   The current document is silent on this point. Related statements which 
requires referenced system nodes must be copied into  are removed.
3.  Other updates
a.   Usage examples refinement, e.g., fix validation errors, remove 
redundancy for conciseness

There is currently no open issues, thus the authors believe this draft is ready 
for WGLC, but this might be worth a broad review on the mailing list.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Friday, March 8, 2024 9:44 PM
To: NETMOD WG 
Cc: netmod-cha...@ietf.org
Subject: Re: [netmod] Draft IETF 119 NETMOD Agenda posted


**IMPORTANT**

Authors of WG documents,

If your document has not yet been submitted to the IESG for publication *and* 
your draft is not on the agenda, please either:
(a) request to present status or
(b) send email to the list summarizing status by end of day (any TZ) Friday, 
March 15.

In either case, please include recent changes, open issues, plan to resolve 
open issues/complete the document.

Thank you!

Lou (and Kent)

On 3/7/2024 3:53 PM, Jason Sterne (Nokia) wrote:
Hello NETMOD WG,

A draft NETMOD agenda for IETF 119 has been published. Please review and let 
the chairs know if any changes are needed or additional topics should be 
covered.

The agenda is pasted below, but here's the link to the always-current version: 
https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod

Presenters: please provide slides to 
netmod-cha...@ietf.org<mailto:netmod-cha...@ietf.org> no later than Sunday 
March 17 (any time zone).

Thanks,
Jason (+ chairs Kent and Lou)

Draft Agenda for the NETMOD 119 WG Session

https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
https://datatracker.ietf.org/meeting/119/session/netmod

Session:

Thursday, March 21, 2024
13:00-15:00 Brisbane (Australia - Eastern Time)
03:00-05:00 UTC
23:00-01:00 Wednesday March 20 America - Eastern Time
https://www.timeanddate.com/worldclock/converter.html?iso=20240321T03=47

Room: M2 https://datatracker.ietf.org/meeting/119/floor-plan?room=m2

WG Chairs:

Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)

WG Secretary

Jason Sterne (jason dot sterne at nokia dot com)

Available During Sessi

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[Jan Lindblad (jlindbla)]

Qiufang,

I'm sorry to say I'm strongly against WGLC at this time because of point #2 
below.

One of the great contributions to network automation that YANG has brought is 
that clients now have a fair chance at computing a desired configuration change 
for a network element. Maybe we need to develop a more elaborate model for 
configuration consistency relative today's "The running configuration datastore 
MUST always be valid", but have I trouble with us stirring up multiple 
interpretations and then staying silent. That's not the way to build 
interoperability.

IMO we need to sort out what the rules are before we come close to WGLC, or 
else the grief outweighs the gain.

Best Regards,
/jan

On 12 Mar 2024, at 03:44, maqiufang (A) 
 wrote:

Hi, chairs,

For system-config draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), the 
authors have submitted a new version to reflect the outcome of the interim, the 
main updates are following:
1.  Address the "origin" issue
a.   The current document explicitly states that system configuration 
copied from  into  have its origin value being reported as 
"intended" and update the examples accordingly
b.  Also, update the definition of "intended" origin identity in 8342 to 
allow a subset of configuration in  to use "system" as origin value
c.   The current document states data migration is out-of-scope except that 
gives a couple of implementation examples in section 4.2 (please feel free to 
propose text if you have better suggestion)
2.  validity of  alone
a.   The current document is silent on this point. Related statements which 
requires referenced system nodes must be copied into  are removed.
3.  Other updates
a.   Usage examples refinement, e.g., fix validation errors, remove 
redundancy for conciseness

There is currently no open issues, thus the authors believe this draft is ready 
for WGLC, but this might be worth a broad review on the mailing list.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Friday, March 8, 2024 9:44 PM
To: NETMOD WG 
Cc: netmod-cha...@ietf.org
Subject: Re: [netmod] Draft IETF 119 NETMOD Agenda posted


**IMPORTANT**

Authors of WG documents,

If your document has not yet been submitted to the IESG for publication *and* 
your draft is not on the agenda, please either:
(a) request to present status or
(b) send email to the list summarizing status by end of day (any TZ) Friday, 
March 15.

In either case, please include recent changes, open issues, plan to resolve 
open issues/complete the document.

Thank you!

Lou (and Kent)

On 3/7/2024 3:53 PM, Jason Sterne (Nokia) wrote:
Hello NETMOD WG,

A draft NETMOD agenda for IETF 119 has been published. Please review and let 
the chairs know if any changes are needed or additional topics should be 
covered.

The agenda is pasted below, but here's the link to the always-current version: 
https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod

Presenters: please provide slides to 
netmod-cha...@ietf.org no later than Sunday 
March 17 (any time zone).

Thanks,
Jason (+ chairs Kent and Lou)

Draft Agenda for the NETMOD 119 WG Session

https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
https://datatracker.ietf.org/meeting/119/session/netmod

Session:

Thursday, March 21, 2024
13:00-15:00 Brisbane (Australia - Eastern Time)
03:00-05:00 UTC
23:00-01:00 Wednesday March 20 America - Eastern Time
https://www.timeanddate.com/worldclock/converter.html?iso=20240321T03=47

Room: M2 https://datatracker.ietf.org/meeting/119/floor-plan?room=m2

WG Chairs:

Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)

WG Secretary

Jason Sterne (jason dot sterne at nokia dot com)

Available During Session:

MeetEcho: https://meetings.conf.meetecho.com/ietf119/?session=31987
Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=31987
Audio Only: https://mp3.conf.meetecho.com/ietf119/31987.m3u

Available During and After Session:

Notes: https://notes.ietf.org/notes-ietf-119-netmod?both
Slides: https://datatracker.ietf.org/meeting/119/session/netmod
Zulip (chat): https://zulip.ietf.org/#narrow/stream/126-netmod/topic/ietf-119
Drafts (TGZ): https://datatracker.ietf.org/meeting/119/agenda/netmod-drafts.tgz
Drafts (PDF): https://datatracker.ietf.org/meeting/119/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/119/session/31987.ics

Available After Session:

Recording: http://www.meetecho.com/ietf119/recordings#NETMOD
Jabber Logs: https://www.ietf.org/jabber/logs/netmod

1) Session Intro & WG Status (10 min)

Presenter: Chairs

Chartered items:
2) YANG Versioning Update (40 min)

Presenter: Rob Wilton and Joe Clarke
Draft: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-11
Draft: 

Re: [netmod] Deviating in circles

[Jan Lindblad (jlindbla)]

Reshad,

Does the same question arise with augments?

No, I don't think so. Augments cannot modify existing namespaces, only add 
content in their own namespace, then graft that namespace onto some existing 
module. If that existing module imports the augmenting module, I would imagine 
all YANG compilers would catch the attempt to create an import loop.

Inline.
...
Is the construct in module d legal? RFC 7950 is not very clear on the subject, 
but it does say:

   After applying all deviations announced by a server, in any order,
   the resulting data model MUST still be valid.

If "applying" means actually replacing the original module text with the 
deviated text, then I'm fairly sure module d would violate the rule against 
circular imports. If "applying" is something that happens on a more "global" or 
"logical" level, then maybe this should be allowed?

 I don't know what was the intention of the 7950 authors and not even sure 
what would be the "right thing". My guess would be it's more in the "logical" 
level.

By allowing deviations of this kind, we might create a temptation for people to 
use deviations for their own modules in order to create YANG structures 
otherwise not possible. I find this problematic, since I don't like deviations 
much. On the other hand, allowing deviations of this kind increases the freedom 
of expression in the YANG world. I think many would regard a moratorium as 
another YANG CLR (crappy little rule).

If we were to decide that this sort of deviation is allowed, wouldn't a logical 
conclusion be that we should drop the circular imports rule? Compilers could 
very well track which modules have already been imported (like in python), and 
not go into unbounded spin just because there is a circular reference loop.

 yang-next?

We could of course clarify this or change the rules in yang-next once we know 
what we want (I'm split on this one), but I was interested in the opinion of 
the list whether this is allowed today.

Best Regards,
/jan

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Deviating in circles

[Jan Lindblad (jlindbla)]

Dear NETMODers,

I'm on site at the annual EANTC interop-event in Berlin, and came across an 
interesting case relating to import and deviations that I'd like the views of 
the list on.

According to RFC 7950:

   There MUST NOT be any circular chains of imports.  For example, if
   module "a" imports module "b", "b" cannot import "a".

This is clear and I believe most people find this reasonable enough.

With this rule in mind, I can make two modules a and b, where a imports b. 
Module b does not and cannot import a.

module a {
yang-version 1.1;
namespace "http://example.com/ns/a;;
prefix a;

import b {
prefix b;
}

typedef A {
type uint32;
}

leaf aa {
type A;
}
leaf ab {
type b:B;
}
}

module b {
yang-version 1.1;
namespace "http://example.com/ns/b;;
prefix b;

typedef B {
type uint32;
}

leaf bb {
type B;
}
}

Now let's add a deviation in a separate module d. The deviation module can 
import both a and b (since neither a or b imports d), and it changes the 
structure so that module b now refers to a type in module a.

module d {
yang-version 1.1;
namespace "http://example.com/ns/d;;
prefix d;

import a {
prefix a;
}
import b {
prefix b;
}

deviation /b:bb {
deviate replace {
type a:A;
}
}
}

As far as I can tell, this follows all the explicit YANG rules regarding 
deviations and imports. Still, it would not have been possible to create this 
YANG structure without a deviation. Module b cannot refer to types or objects 
in module a without an outside intervention.

Is the construct in module d legal? RFC 7950 is not very clear on the subject, 
but it does say:

   After applying all deviations announced by a server, in any order,
   the resulting data model MUST still be valid.

If "applying" means actually replacing the original module text with the 
deviated text, then I'm fairly sure module d would violate the rule against 
circular imports. If "applying" is something that happens on a more "global" or 
"logical" level, then maybe this should be allowed?

By allowing deviations of this kind, we might create a temptation for people to 
use deviations for their own modules in order to create YANG structures 
otherwise not possible. I find this problematic, since I don't like deviations 
much. On the other hand, allowing deviations of this kind increases the freedom 
of expression in the YANG world. I think many would regard a moratorium as 
another YANG CLR (crappy little rule).

If we were to decide that this sort of deviation is allowed, wouldn't a logical 
conclusion be that we should drop the circular imports rule? Compilers could 
very well track which modules have already been imported (like in python), and 
not go into unbounded spin just because there is a circular reference loop.

As a side note, recent versions of the OpenConfig model have fallen into this 
YANG-module reference trap. Some OC modules violate RFC 7950 rules because 
their authors were not able to plan ahead and divide their modules properly 
into layers. They have skipped importing modules that they are using because 
their compiler errors out if they do the import, but the compiler they use 
misses/tolerates the illegal reference without the needed import. If modules 
could mutually import each other, this problem would be easily solved. Several 
major vendors of YANG-based servers have navigated around this problem by 
essentially using a single module (namespace) for most of their functionality. 
Then there are no restrictions for what part of the model can reference what 
else, but everything ends up in a single (rather huge) namespace.

Thoughts?

Best Regards,
/jan

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Agenda posted for Jan 23 Interim on system-config-04

[Jan Lindblad (jlindbla)]

Jason, WG,

There seems to be some confusion about the exact time of this interim. Earlier 
in this thread, there was a quite elaborate table evaluating the viability of 
various times of day. In that table, one of the columns is labeled CET. Closer 
scrutiny of the time offsets in that table suggests it should probably have 
been called UTC, however.

I suppose this means that most people (outside the CET zone) have interpreted 
the agreed upon time as 2pm-4pm *UTC* (1500-1700 CET). That is also what the 
calendar invite .ics file provided in the invitation suggests.

In the invitation below, the time is given as 1600 UTC (=1700 CET). This seems 
to be two hours off. Could you please clarify what the exact time will be?

Best Regards,
/jan




> On 12 Jan 2024, at 00:19, Jason Sterne (Nokia) 
>  wrote:
> 
> Hello NETMOD WG,
> 
> The (short) agenda for the Jan 23 1600 UTC Virtual Interim on 
> draft-ietf-netmod-system-config-04 has been posted.
> 
> Some introductory slides from the chairs are posted, but more specific 
> meeting materials will follow sometime before the meeting:
> https://datatracker.ietf.org/meeting/interim-2024-netmod-01/session/netmod
> 
> Calendar link (ICS):
> https://datatracker.ietf.org/meeting/interim-2024-netmod-01/sessions/netmod.ics
> 
> Hope to see many of you there!
> 
> Jason (and chairs Lou and Kent)
> 
>> -Original Message-
>> From: Kent Watsen 
>> Sent: Tuesday, December 12, 2023 1:50 PM
>> To: netmod@ietf.org
>> Cc: Jason Sterne (Nokia) ; Per Andersson (perander)
>> 
>> Subject: Re: [netmod] Proposed date for Interim on system-config-04
>> 
>> 
>> 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.
>> 
>> 
>> 
>> Thank you Per for raising the concern, and Jason for dismissing it.
>> Since no objections are standing, we will schedule the Interim at the 
>> proposed
>> time.
>> 
>> Thanks again,
>> Kent (and Lou)
>> 
>> 
>>> On Dec 5, 2023, at 10:51 AM, Jason Sterne (Nokia) 
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> After a quick poll of some weekly YANG versioning call members we think it
>> would be fine to leave that Jan 23rd slot to the system config interim. We 
>> can skip
>> our YANG Ver meeting that week.
>>> 
>>> Jason
>>> 
 -Original Message-
 From: netmod  On Behalf Of Per Andersson
 (perander)
 Sent: Monday, December 4, 2023 7:05 PM
 To: Kent Watsen ; netmod@ietf.org
 Subject: Re: [netmod] Proposed date for Interim on system-config-04
 
 
 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.
 
 
 
 Hi!
 
 Tuesdays 3pm-4pm CET conflicts with the module versioning meetings.
 
 
 --
 Per
 
 
 From: netmod  on behalf of Kent Watsen
 
 Sent: Tuesday, December 5, 2023 00:18
 To: netmod@ietf.org
 Subject: [netmod] Proposed date for Interim on system-config-04
 
 Dear NETMOD WG,
 
 Following up on an action from the 118 session, the chairs would like to
>> schedule
 an Interim meeting to discuss draft-ietf-netmod-system-config.
 
 Considering various time-options with Qiufang, as author, it seemed that 
 the
 following 2-hour slot was best for all (see table at bottom for details):
 
 Tue, Jan 23, 2024:
   - PST: 6am-8am
   - EST: 9am-11am
   - CET: 2pm-4pm
   - CST: 10pm-12am
 
 Please let us know this week if there is a conflict.
 
 Kent and Lou
 
 
 
 CET EST PST CST
 === === === ===
 10pm 5pm 2pm 6am <- maybe okay?
 11pm 6pm 3pm 7am <- a little too late CET
 12am 7pm 4pm 8am <- way too late CET
 1am 8pm 5pm 9am <- way too late CET
 2am 9pm 6pm 10am <- way too late CET
 3am 10pm 7pm 11am <- way too late CET
 4am 11pm 8pm 12pm <- way too early CET, a little too late EST
 5am 12am 9pm 1pm <- too early CET, too late EST
 6am 1am 10pm 2pm <- way too late EST
 7am 2am 11pm 3pm <- way too late EST
 8am 3am 12am 4pm <- way too late EST, too late PST
 9am 4am 1am 5pm <- way too late EST, way too late PST
 10am 5am 2am 6pm <- a little too early EST, way too late PST
 11am 6am 3am 7pm <- way too early PST
 12pm 7am 4am 8pm <- way too early PST
 1pm 8am 5am 9pm <- a little too early PST
 2pm 9am 6am 10pm <- maybe okay?
 
 ___
 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
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Extending YANG by implementation-specific blocks

[Jan Lindblad (jlindbla)]

Hi Maria,

Thanks for reaching out and explaining your plans. I think the approach with 
basing your interface on a YANG module is excellent. We have been doing similar 
things massively since more than decade ago, and there a re a couple of caveats 
I would like to point out:

+ Using YANG extension statements to tie your interface to your code works 
great. Actually writing the code in the YANG module extension bodies works, but 
is rather cumbersome. The support you would normally get from an IDE for 
writing or debugging your C code is easily lost or complicated. So I would 
recommend tying the code with the interface using extension statements that 
just mention the name of C functions or C data structures, etc.

+ Code generation based on YANG works well if the number and size of the YANG 
modules is modest, e.g. when only your own project YANG modules are in scope. 
If you want to do this sort of code generation for an entire router or 
controller, for example, the code generated often gets incredibly large. As an 
example of this you could look at the many attempts to generate OpenAPI/Swagger 
APIs from YANG (one example: https://github.com/bartoszm/yang2swagger). Even 
with the limited support provided by these tools, my experience with this 
approach has invariably ended with "Code too large" error messages from the 
compiler. If you want to support larger (sets of) YANG modules, maybe treating 
the YANG structures more as a data structure rather than a code skeleton would 
make sense. As in letting methods use paths to YANG elements as arguments, 
rather than having a separate function call for every element.

+ For parsing YANG and generating either data structures or code, I find both 
pyang (easier) and yanger (faster) an excellent base for the job. Their plug-in 
architecture makes it easy to add your own extensions. Takes a day or two to 
understand how, but after that initial learning curve, I find them very useful.

Best Regards,
/jan




On 16 Nov 2023, at 09:09, Maria Matejka  
wrote:


Dear Netmod WG,

we're currently trying to create a YANG-described API for BIRD. The interface 
will be (at least) one large C file generated from the YANG files, as we want 
the implementation to be directly tied to the specification. What we're aiming 
to do, though, is to have the code generator as simple as possible, maybe even 
completely language-agnostic, and putting pieces of C code directly into our 
YANG files.

Reasons why to do it this way, finally boil down to this:

  *   we don't want BIRD to have any additional layer of data structures 
between API and internals, so there will be specific code for most of the YANG 
tree nodes anyway
  *   we also want to provide the clients with a semantics-aware interface, to 
e.g. canonically format the structured data for human-readable output

There is an alternative approach, to write a separate generator for each 
usecase. We haven't decided yet whether it is viable for us. What I personally 
see most valuable on the YANG extension approach, is a possibility to easily 
ship and update access libraries with a native object model for each supported 
language. (If you smell a new Bison from this, you are quite right.)

My major question is for now, whether there is any work or thoughts in this 
direction; I couldn't find any but it may be just my bad search skill.

Then it depends → if this approach has already been proven wrong, please point 
me to the discussion to learn how to do the right way. Otherwise, would there 
be any interest on designing a canonical extension to the YANG syntax? I would 
call it somehow like YANG-With-Embedded-Code (YWEC), which could be then 
processed by toolings, generating the "bare" YANG and all the code files from 
one normative YWEC.

Thank you all for considering this topic.
Maria and the BIRD Team

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

___
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] [Inventory-yang] New Internet Draft on Peer-Mount

[Jan Lindblad (jlindbla)]

Alex,

Great meeting you this week, and thanks for the many presentations about 
interesting and sometimes pressing topics. I have read the draft and have a few 
comments.

First of all I want to say that I understand the value of this use case. In 
fact, we have implemented a fairly similar proprietary mechanism more than 10 
years ago, and it is still in daily use around the world today. That said, I 
can also attest to the wealth of implementation difficulties when it comes to 
make this efficient/reliable enough for a broad range of use cases.

Restricting this mechanism to only provide read-only data is smart :-) when it 
comes to limiting potential issues. To standardize federated config management 
in this vein would be a truly massive undertaking. Still, what you propose 
isn't easy to get right. We will have to open a can of worms (even if we avoid 
the "config true" barrel of worms).

You have obviously thought about this quite a bit, but let me ask what you 
think about the following:

1) Performance & caching

The primary problem we see with our existing, proprietary implementation of 
something in this direction is that the performance is not good enough for many 
use cases. The mechanism is used a fair bit, so clearly it is good enough for 
some. Every time a call to another server is required (and you even talk about 
cascading mounts), a delay is incurred. This can of course be mitigated by 
caching strategies. Anyone who has studied distributed caching algorithms knows 
this is really complex, though, and results are not always ideal.

2) Authentication & mount server mgmt

You propose a YANG module for management of mounts. This list includes details 
about server IP addresses etc, but not user credentials. This means the 
structure is not usable by itself, additional knowledge is required to do the 
reading. I am not so sure everyone would want to manage their device federation 
and authentication/authorization mapping using this model structure (we 
certainly would not), so maybe it would be better to just provide a list of 
host names (string) and leave the exact meaning of that string out of scope?

3) YANG model merging

Since we are in the YANG world where all data we read is well described by a 
YANG DM, we'd like the clients to know what the mounted YANG looks like. This 
is a non-trivial matter even with YANG-mount, but here we're also not mounting 
entire modules, but rather pointing at random points in those mounted models. 
How a client is to make sense of that situation is not entirely clear, even if 
it is only for config false.

4) YANG-push, gnmi subscriptions, etc

You mentioned yourself that it may be difficult to create the (synchronized?) 
responses to any client's subscriptions over this data. Maybe it could be left 
out of scope, but doing so would make the federated solution appear as 
something negative to clients.

5) Consistent network configuration

The mechanism described in section 4.2 is a kind of configuration mechanism. I 
do think it looks rather weak, however, compared to the functionality available 
to applications running on top of common NETCONF servers. In order to get 
proper transactional behavior, clients will typically need to validate and 
coordinate their consumption of configuration changes, and that sounds 
difficult to achieve with this approach. I fear this would lead to low quality 
systems (i.e. not fully transactional, not properly validated, etc).


So to summarize, while I say "we need this" (and have and use this in our 
proprietary context), I'm also saying it's not going to be easy to standardize.

Best Regards,
/jan



> we have just submitted a new Internet Draft regarding Peer-Mount, a mechanism 
> that allows to reference and incorporate information from remote datastores.  
> This will allow, for example, a network controller to provide a federated 
> datastore containing management data transcending individual network devices 
> without needing to keep this data redundantly.  You can find the draft here: 
> https://datatracker.ietf.org/doc/html/draft-clemm-netmod-peermount-00
> 
> The concept of Peer-Mount was in fact originally introduced several years ago 
> but not pursued further due to lack of interest and IETF use cases at the 
> time.   It is being revived now, with a few modifications, in light of IETF 
> interest in network inventory, network topology, and related use cases that 
> have emerged since. Inevitably, these use cases may lead to the need to 
> incorporate some management data regarding particular state or configuration 
> that is already maintained on networking devices into a holistic network-wide 
> view.  Unlike Schema Mount, which allows to reuse existing model definitions 
> by allowing them to be  instantiated in a local data tree, Peer Mount is 
> aimed at incorporating a  local view of data subtrees that are remote, 
> authoritatively owned and maintained by separate systems.
> 
> We believe that 

Re: [netmod] MUST offline-validation of alone be required? possible solution and further discussion

[Jan Lindblad (jlindbla)]

Kent,

Very good. Our products are leveraging the features you mention in Junos 
systems, and we have similar functionality in our own. I certainly see good 
value in these "configuration transformations”, but I also know that much of 
this value can be realized without changes to YANG, since in fact we already 
have such features implemented while also supporting an always valid running at 
the same time.

I agree more value could potentially be made available if the config 
transformations could be expressed more freely, but in my world, trading such a 
gain for the loss of a robust machine readable interface is a huge net negative.

You are pointing to the crucial spot below when you say '''clients can 
"offline-validate ", when such features are in use, by groking and 
applying the processing-logic behind the features'''. If we can make a client 
grok and apply that processing logic by either a) applying processing logic 
defined in a standards track document, or b) applying a machine readable recipe 
(which is provided by the server) of what the transformations do exactly, I 
think this is a discussion worth pursuing.

If, on the other hand, the suggestion is that clients should reverse engineer 
the black box transformation logic of each version of each type of system from 
each vendor and keep it up to date, then I think the potential value we're 
discussing here is dwarfed by the maintenance cost and interoperability 
concerns.

So there you have it. To progress this idea of a changed definition of what 
"valid " means, I think we would need to standardize the 
transformation logic in some way. There is some potential value, but surely a 
lot of work. Are we up for it?

Best Regards,
/jan



RFC 8342 defines the ability for "configuration transformations” to map 
 to , which is "subject to validation”.Section 5.1.4 
describes cross-cutting features, such as deactivating nodes and templating, 
that can result in an invalid , when  is considered alone.  
However, clients can "offline-validate ", when such features are in 
use, by groking and applying the processing-logic behind the features 
(mimicking that which the server does to produce ), and then 
YANG-validate the result (same as the server).  All this is well understood, 
expected, and good - right?

FWIW, these features have been implemented in Junos for as long as I know.  And 
yes, the Juniper NMS systems I worked on offline-validated “” before 
 by mimicking the processing logic locally, as described above.

What Qiufang proposes now adds to this.  It is one more thing for clients 
wishing to offline-validate  to mimic.   In this case, they need to 
mimic the merging of  and , which entails the clients also 
fetching  from the server, in case they don’t have it already.

None of this takes away from transactional interfaces, machine readable 
constraints, high automation levels, or the ability for clients to express 
intent.

With regards to owner and consumer value, I see each of these three features 
(deactivating nodes, templating, and ) as providing clients 
greater/better flexibility/control/insight.  Agreed?

Kent



On Oct 26, 2023, at 10:42 AM, Jan Lindblad (jlindbla) 
 wrote:

Qiufang,

While we have tools that actually do offline validation a lot, I am not against 
discussing removing that possibility from YANG (in a multi-year plan), if there 
are strong benefits with this idea. So far I haven't seen them.

In the old SNMP world, we had MIB models. They described what you could read 
and write, but not when you could do so or how things interacted. Now we have 
YANG-based interfaces that are transactional (sequencing no longer a client 
concern) and with machine readable constraints. I don't see any way to reach 
the high automation levels we are enjoying today without this. These principles 
are bringing a lot of very tangible owner and consumer value $€¥ every day.

Running reflects the client's intent. If an upcoming intent can no longer be 
validated by anybody else than the system being managed, and the rules by which 
it validates running depends on a black box, then it becomes very hard for the 
client to express its intent. Sounds like we'd be going back to the SNMP age.

If anyone can explain a) how a client should go about expressing its intent in 
a world where running no longer needs to be valid, and b) what the strong 
benefits of this model would be, I'd be happy to discuss.

Best Regards,
/jan



I want to bring up a key issue that has been discussed before but hasn’t really 
been agreed upon: MUST offline-validation of  alone be required?

The question behind this issue is about: must referenced system config always 
be copied into  to satisfy referential integrity constraints, or 
 is implicitly valid if  is valid by merging  and 
 (after config transformation like removal of inactive config and 
expansion of templates) to create its contents,  alone doesn’t hav

Re: [netmod] MUST offline-validation of alone be required? possible solution and further discussion

[Jan Lindblad (jlindbla)]

Qiufang,

While we have tools that actually do offline validation a lot, I am not against 
discussing removing that possibility from YANG (in a multi-year plan), if there 
are strong benefits with this idea. So far I haven't seen them.

In the old SNMP world, we had MIB models. They described what you could read 
and write, but not when you could do so or how things interacted. Now we have 
YANG-based interfaces that are transactional (sequencing no longer a client 
concern) and with machine readable constraints. I don't see any way to reach 
the high automation levels we are enjoying today without this. These principles 
are bringing a lot of very tangible owner and consumer value $€¥ every day.

Running reflects the client's intent. If an upcoming intent can no longer be 
validated by anybody else than the system being managed, and the rules by which 
it validates running depends on a black box, then it becomes very hard for the 
client to express its intent. Sounds like we'd be going back to the SNMP age.

If anyone can explain a) how a client should go about expressing its intent in 
a world where running no longer needs to be valid, and b) what the strong 
benefits of this model would be, I'd be happy to discuss.

Best Regards,
/jan



I want to bring up a key issue that has been discussed before but hasn’t really 
been agreed upon: MUST offline-validation of  alone be required?

The question behind this issue is about: must referenced system config always 
be copied into  to satisfy referential integrity constraints, or 
 is implicitly valid if  is valid by merging  and 
 (after config transformation like removal of inactive config and 
expansion of templates) to create its contents,  alone doesn’t have to 
be offline valid.

It feels like the WG has a mixed viewpoints, and I would like to find a 
solution and seek convergence here. Actually I am thinking, instead of directly 
stating in the draft that any referenced system config must be contained in 
, we can point to RFC 7950 and RFC 8342 and state that  MUST 
always be a valid configuration data tree. So that we just leave it there and 
interpretations may vary. Anyway, the client can always explicitly copy 
referenced system config into  or use the “resolve-system” parameter 
if an offline-validation of  is needed.

If we can reach an agreement on this handling, I believe then we can move on.

One the other side, I also understand that we should not shy away from this 
issue and need effectively work it out. Below are some thoughts and inputs from 
the WG:

• Yes,  alone must be offline valid
o   Pros
•  Clients can easily offline validate  without offline merging 
 and  (which would bring extra complexity to clients)
o   Cons:
•  Painful copy is needed.
•  Need to deal with the scenario where the system config has updated and a 
stale copy is still in 
• No, Offline validation of  MAY consider other datastores as 
well, two options:
o   Treat it as a bug-fix in existing RFCs
•  Cons: might break legacy clients and existing tool chains
o   Wait for a new version of YANG/NC/RC
•  Cons: might incur delay

Any further thoughts on this? Comments and suggestions would be much 
appreciated.


Best Regards,
Qiufang
___
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] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

[Jan Lindblad (jlindbla)]

Jürgen,

Fair enough. We'll discuss more later then. Thanks for providing quick feedback 
and an outline of what you see as favorable.

Best Regards,
/jan

On 3 Oct 2023, at 19:32, Jürgen Schönwälder 
 wrote:

Jan,

I need to see the text. Using the existing versioning draft as a base
for this minimal solution scares me since this document went over
board. I need to see the text that details in which situations an NBC
change is allowed. I need to see the definition of the extension to
mark NBC changes. Only then I can tell whether we made progress.

If the WG does draft-schoenw-netmod-yang-relaxed-versioning-00 without
the import statement change (section 2), which was the reason to bump
the YANG language version number, then I am OK.

/js

On Tue, Oct 03, 2023 at 05:06:42PM +, Jan Lindblad (jlindbla) wrote:
Jürgen,

Thanks for the clarifications. It seems to me we're in complete agreement here.

Here are the use cases I can think of:
a) Tools that don't care about modules being backwards-compatible are fine. 
They will see good-old 7950 and 6020 YANG modules which are supposed to be 
backwards compatible, but sometimes are not. Occasionally they will see an 
unknown extension statement that they ignore.
b) Tools which flag YANG modules that are not backwards compatible and are 
unaware of the extension statement will flag all incompatibilities as errors. 
Not ideal, but an uncommon case that is pretty easy to handle in practice.
c) Tools which flag YANG modules that are not backwards compatible and are 
*aware* of the extension statement will flag incompatibilities without proper 
markup as errors, and allow the rest. This is great.
d) 7950 and 6020 module authors are (theoretically) bound by the strict sec 11 
and sec 10 backwards compatibility rules, like today.
e) Module authors that need to introduce backwards incompatible changes may do 
so provided some appropriate extension statement defined in an upcoming 
document is applied.

To me, this makes sense. If it does to you too, Jürgen, that would certainly 
make me happy.

Best Regards,
/jan




On 2 Oct 2023, at 18:06, Jürgen Schönwälder 
 wrote:

RFC 7950 is clear that extensions must be designed such that they can
be ignored by YANG parsers and tools.

If you use 'mandatory, are you talking about 'mandatory' in an RFC
8407 sense (and not in an YANG language sense)? The difference here is
between 'mandatory to use by module authors' versus 'mandatory to be
understood by tools'.

/js

On Mon, Oct 02, 2023 at 03:52:00PM +, Jason Sterne (Nokia) wrote:
Hi guys,

I think we'll need to be concrete about exactly which parts/extensions in 
Module Versioning we're talking about. And it will likely be a slightly 
different debate/discussion for each one.

I think the top level rev:non-backwards-compatible extension (and it being 
mandatory) is important to bundle in with the NBC rule change to SHOULD NOT.

The rev:recommended-min is useful IMO but may not be critical to include & 
bundle into the first versioning RFC. I still think it is useful for the YANG 
ecosystem to have this though.

In Key Issue #2 we've raised the question about the rev:revision-label-scheme 
already.

We should probably discuss each of these different & separate ideas/concepts in 
individual threads though..

Jason

-Original Message-
From: Jürgen Schönwälder 
Sent: Monday, October 2, 2023 11:45 AM
To: Jan Lindblad (jlindbla) 
Cc: Jason Sterne (Nokia) ; Kent Watsen
; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
(from Key Issue #1)


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.



Jan,

I am certainly not against documenting NBC changes. This can be done
using extension statements. Whether such extensions are defined in the
same document or not at the end is a procedural question.

That said, any extensions that go beyond something that can be safely
ignored (e.g., extensions that for example influence how imports are
resolved) do for me require a new YANG language version. It would help
if people could acknowledge that we have agreement on this. Otherwise,
I fear that we may repeat the same discussion we had again several
months later.

/js

On Mon, Oct 02, 2023 at 02:34:31PM +0000, Jan Lindblad (jlindbla) wrote:
Jürgen, WG,

I agree that a document that updates 7950 would be the preferred solution
here, rather than a bis or errata.

I'm quite attracted, however, by the idea to bundle the softening of 7950 with
the requirement to document any incompatibilities introduced. This way, we get
something useful back as we provide the needed flexibility. This is something I
would have an easy time to explain to YANG practitioners, and it seems pragmatic
to me.

I agree completely that YANG extensions cannot change YANG at all for clients
that are not in on them. In the key issue #1 debate, however, I beli

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

[Jan Lindblad (jlindbla)]

Jürgen,

Thanks for the clarifications. It seems to me we're in complete agreement here.

Here are the use cases I can think of:
a) Tools that don't care about modules being backwards-compatible are fine. 
They will see good-old 7950 and 6020 YANG modules which are supposed to be 
backwards compatible, but sometimes are not. Occasionally they will see an 
unknown extension statement that they ignore.
b) Tools which flag YANG modules that are not backwards compatible and are 
unaware of the extension statement will flag all incompatibilities as errors. 
Not ideal, but an uncommon case that is pretty easy to handle in practice.
c) Tools which flag YANG modules that are not backwards compatible and are 
*aware* of the extension statement will flag incompatibilities without proper 
markup as errors, and allow the rest. This is great.
d) 7950 and 6020 module authors are (theoretically) bound by the strict sec 11 
and sec 10 backwards compatibility rules, like today.
e) Module authors that need to introduce backwards incompatible changes may do 
so provided some appropriate extension statement defined in an upcoming 
document is applied.

To me, this makes sense. If it does to you too, Jürgen, that would certainly 
make me happy.

Best Regards,
/jan




On 2 Oct 2023, at 18:06, Jürgen Schönwälder 
 wrote:

RFC 7950 is clear that extensions must be designed such that they can
be ignored by YANG parsers and tools.

If you use 'mandatory, are you talking about 'mandatory' in an RFC
8407 sense (and not in an YANG language sense)? The difference here is
between 'mandatory to use by module authors' versus 'mandatory to be
understood by tools'.

/js

On Mon, Oct 02, 2023 at 03:52:00PM +, Jason Sterne (Nokia) wrote:
Hi guys,

I think we'll need to be concrete about exactly which parts/extensions in 
Module Versioning we're talking about. And it will likely be a slightly 
different debate/discussion for each one.

I think the top level rev:non-backwards-compatible extension (and it being 
mandatory) is important to bundle in with the NBC rule change to SHOULD NOT.

The rev:recommended-min is useful IMO but may not be critical to include & 
bundle into the first versioning RFC. I still think it is useful for the YANG 
ecosystem to have this though.

In Key Issue #2 we've raised the question about the rev:revision-label-scheme 
already.

We should probably discuss each of these different & separate ideas/concepts in 
individual threads though..

Jason

-Original Message-
From: Jürgen Schönwälder 
Sent: Monday, October 2, 2023 11:45 AM
To: Jan Lindblad (jlindbla) 
Cc: Jason Sterne (Nokia) ; Kent Watsen
; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
(from Key Issue #1)


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.



Jan,

I am certainly not against documenting NBC changes. This can be done
using extension statements. Whether such extensions are defined in the
same document or not at the end is a procedural question.

That said, any extensions that go beyond something that can be safely
ignored (e.g., extensions that for example influence how imports are
resolved) do for me require a new YANG language version. It would help
if people could acknowledge that we have agreement on this. Otherwise,
I fear that we may repeat the same discussion we had again several
months later.

/js

On Mon, Oct 02, 2023 at 02:34:31PM +0000, Jan Lindblad (jlindbla) wrote:
Jürgen, WG,

I agree that a document that updates 7950 would be the preferred solution
here, rather than a bis or errata.

I'm quite attracted, however, by the idea to bundle the softening of 7950 with
the requirement to document any incompatibilities introduced. This way, we get
something useful back as we provide the needed flexibility. This is something I
would have an easy time to explain to YANG practitioners, and it seems pragmatic
to me.

I agree completely that YANG extensions cannot change YANG at all for clients
that are not in on them. In the key issue #1 debate, however, I believe most
people agreed that we should allow non-backwards compatible changes to some
degree. To also require that any such non-backwards compatible changes are
documented using an extension statement is not to muddy the waters in my
opinion. Quite the contrary, actually. People's understanding of what's going on
will likely be improved by this requirement, for clients and server implementors
alike.

We can certainly discuss the pros and cons of requiring users to document their
non-backwards compatible changes once we have the key issue #1 behind us.

Best Regards,
/jan


On 29 Sep 2023, at 07:45, Jürgen Schönwälder
 wrote:

Jason,

the must/should change is technically a change of the language. We can
do a short RFC to do that so that we get unstuck and oour AD allows us
again to publish YANG modules where b

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

[Jan Lindblad (jlindbla)]

Jürgen, WG,

I agree that a document that updates 7950 would be the preferred solution here, 
rather than a bis or errata.

I'm quite attracted, however, by the idea to bundle the softening of 7950 with 
the requirement to document any incompatibilities introduced. This way, we get 
something useful back as we provide the needed flexibility. This is something I 
would have an easy time to explain to YANG practitioners, and it seems 
pragmatic to me.

I agree completely that YANG extensions cannot change YANG at all for clients 
that are not in on them. In the key issue #1 debate, however, I believe most 
people agreed that we should allow non-backwards compatible changes to some 
degree. To also require that any such non-backwards compatible changes are 
documented using an extension statement is not to muddy the waters in my 
opinion. Quite the contrary, actually. People's understanding of what's going 
on will likely be improved by this requirement, for clients and server 
implementors alike.

We can certainly discuss the pros and cons of requiring users to document their 
non-backwards compatible changes once we have the key issue #1 behind us.

Best Regards,
/jan


On 29 Sep 2023, at 07:45, Jürgen Schönwälder 
 wrote:

Jason,

the must/should change is technically a change of the language. We can
do a short RFC to do that so that we get unstuck and oour AD allows us
again to publish YANG modules where bug fixes or alignment with other
modeled technologies is desirable.

Adding decorations that can be ignored is something one can do with
YANG extensions.  However, once such extensions change the behaviour
of YANG language constructs, we get into muddy waters.

I prefer to clearly separate changes of the language from additional
decorations that can be ignored and do not influence the behaviour of
YANG implementations (i.e., they can be ignored).

/js

On Thu, Sep 28, 2023 at 08:57:42PM +, Jason Sterne (Nokia) wrote:
Hi all,

IMO - We've already started moving out of the "stuck" situation. We no longer 
have to debate whether a new YANG 1.2 is needed for allowing an NBC change. 
That will be the end of a big distraction and circular discussions for the WG.

I'm not so convinced we want to rush and do a separate RFC just for that one 
part of Module Versioning (and one part of the original versioning 
requirements). It is a key/critical part, but we should continue discussing 
what other parts we'd want to also tackle as part of the "first" versioning RFC.

I'm very doubtful we should relax MUST to SHOULD NOT without also at least 
making the rev:non-backwards-compatible marker mandatory (as per Module 
Versioning). The marking is a key part of making this all better for consumers 
of modules and clients (one of the main problems is the current silent NBC 
changes happening).

We should also clarify that marking an element as "status obsolete" is NBC. 
That has major impact on clients who are trying to continue using an old 
version of the module.

(and there are likely at least a few other pieces from Module Versioning that 
should be in a "first" RFC)

Jason

-Original Message-
From: netmod  On Behalf Of Jürgen Schönwälder
Sent: Thursday, September 28, 2023 9:12 AM
To: Reshad Rahman 
Cc: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
(from Key Issue #1)


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.



The truth is that we did bug fixes in the past. We now have maneuvered
us into a situation where work is put on hold because we do not even
do bug fixes anymore (and yes, I know, the line between bug fixes,
alignment with moving targets and other changes is vague and needs to
be decided on a case by case basis). The fastest way to get unstuck is
to write this one page content RFC that changes MUST to SHOULD and
then we at least get out of the being stuck situation.

/js

On Thu, Sep 28, 2023 at 01:00:23PM +, Reshad Rahman wrote:
As a client (consumer of models), I do not want only the MUST -> SHOULD
change, IMO that would be worse than the current situation.
Regards,Reshad.
   On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen
 wrote:

This was my thought as well, that it would be best to have the smallest-possible
draft update 6020/7950.  That way, when someone follows the “Updated” links,
they’re not overloaded with material that could’ve been left out.
Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at
least the "rev:non-backwards-compatible” extension statement should be
included and, by extension I suppose, the rules for editing the revision 
history.
Presumably revision labels could be left out.  IDK what minimal is possible.
K. // contributor



On Sep 27, 2023, at 7:06 PM, Rodney Cummings
 wrote:


It is easy to write a short RFC updating RFC 7950, changing one sentence from
MUST 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jan Lindblad (jlindbla)]

Jernej,

Hat off for the tools (and tool vendors!) that assist authors to stay true to 
YANG RFC sections 10 and 11 also. Well done. :-)

I intentionally used "compiler" rather than "toolchain", "IDE" or something 
more open ended, because a compiler is what I have and can speak for.

Even so, I have a hard time thinking the customers of even the best YANG IDEs 
would be interested to pay the effort for distinguishing between YANG 1.1 and 
YANG 1.2 solely on the proposed RFC wording difference. Since a BC verification 
capability apparently already exists in some IDEs, I think it would make sense 
for their vendors to turn the checks it into a warnings (if they aren't 
already), regardless of which yang-version statement is found in the module 
header.

This might mean a non-zero implementation effort for a few YANG toolchain 
implementors. While this is a good point, it does not really sway my opinion 
about what the pragmatic choice for IETF is. Or Jernej, do you think the users 
of those good IDEs would prefer a new YANG version? If so, why?

Best Regards,
/jan





On 13 Sep 2023, at 10:57, Jernej Tuljak  wrote:

On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no 
actual change to the YANG *language*. If we require user's to mark their 
modules with version 1.2 (or 2.0), from the compiler's pov, that would just be 
an alias for YANG 1.1. It means a fair amount of trouble to update all the 
tools out there to accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go through all 
YANG 1.1 modules and mark them 1.2, for no change in meaning. For organizations 
with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.

You will first have to define what a YANG compiler is before you can make such 
assumptions. YANG code validation rules may be implemented in several ways, 
depending on what the tool that utilizes them is used for. I choose to call 
that a "validation engine" - "compiler" implies translation into a lower level 
language in my world and not all tools require that. I know of at least one 
tool that utilizes a validation engine that performs the checks in Updating a 
Module sections of RFC 6020 and RFC 7950, when requested. And I would expect a 
YANG authoring tool to do the same if it claims full RFC compliance. Those are 
not optional guidelines intended just for humans. It is true that some of the 
rules can only be reliably checked by a human, but not all (or even most) of 
them. Point being - there are implementations out there that rely on the text 
of this Section to remain unchanged. I would imagine that they represent a drop 
in the sea compared to implementations that have chosen to completely ignore 
the spec (forking YANG into YANG' in the process), but they do exist.

I disagree that changing those sections does not change the language. Of course 
it does. It makes combinations of language constructs, that were previously not 
allowed, valid. This is no different to prescribing a mandatory-to-implement 
YANG extension.

File versioning is baked into YANG, a peculiarity of the language. There are 
many more such peculiarities. I'd like to know what other backward incompatible 
changes to the spec I can expect to occur in the future because there's now a 
precedent for it.

Jernej


Best Regards,
/jan



On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
 wrote:

I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way that a new versioning approach will be
understood by existing YANG tooling. That's an illusion.

/js

On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
WG,

Please help the YANG-versioning effort move forward by participating in

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jan Lindblad (jlindbla)]

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no 
actual change to the YANG *language*. If we require user's to mark their 
modules with version 1.2 (or 2.0), from the compiler's pov, that would just be 
an alias for YANG 1.1. It means a fair amount of trouble to update all the 
tools out there to accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go through all 
YANG 1.1 modules and mark them 1.2, for no change in meaning. For organizations 
with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.

Best Regards,
/jan



> On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
>  wrote:
> 
> I disagree with the poll. There are important teachnigal differences
> behind the two options that this polls tries to hide.
> 
> Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> 1.1'. There is no way that a new versioning approach will be
> understood by existing YANG tooling. That's an illusion.
> 
> /js
> 
> On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
>> WG,
>> 
>> Please help the YANG-versioning effort move forward by participating in the 
>> following poll:
>> 
>>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)
>> 
>> Kent and Lou
>> 
> 
>> ___
>> 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
> Fax:   +49 421 200 3103 
> 
> ___
> 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] List name: singular or plural?

[Jan Lindblad (jlindbla)]

Carsten,

> Should list names be singular or plural?

The convention is to have the list name singular, and surrounding container 
name plural. I would think someone just accidentally reversed the convention.

A quick grep across IETF RFC YANG modules for list names ending in s versus 
ending with other letters gave 370 vs 1663 = ~20% (some modules may have been 
scanned more than once, due to multiple versions etc).

For some transport encodings (e.g. XML), the surrounding container makes the 
list contents a bit more manageable. A surrounding container is also a 
convenient for use in filters and NACM rules.

Best Regards,
/jan

> 
> 
> Archived-At: 
> 
> As a convention, in IETF YANG modules, the node name of a list is in the
> singular form.
> Above the list there can be a container with a name in the
> plural form.
> 
> This seems to be supported by the example in 4.26 in RFC 8407.
> 
> 
> Archived-At: 
> 
> The usual YANG convention is for a list to be plural and the leaf singular.  
> You have the plural list but not the leaf.  And who needs the container?  
> This is mpls not a common module that might be augmented so what does the 
> container give apart from complexity?
> 
> (Note that this is contradicting the above.)
> 
> 
> RFC 9243 has plural for  leaf-list interfaces {
> also RFC 9127  list interfaces {
> 
> 
> All examples in RFC 9254 (YANG-CBOR) have singular list names
> 
> 
> RFC8040:
> container interfaces {
>   description "System interfaces.";
>   list interface {
> 
> RFC6243:
> container interfaces {
> description "Example interfaces group";
> list interface {
>   description "Example interface entry”;
> 
> The singular list name seems to be quite popular with a plural container name.
> Where there is no such container name, it gets a bit more mixed.
> 
> Is there a document that I could consult?
> 
> Grüße, Carsten
> 
> 
> ___
> 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] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[Jan Lindblad (jlindbla)]

Kent, Quifang,

I support adoption of this work. It is an architecturally deep and important 
topic. I think a good amount of work remains before we reach consensus, and 
that it is important to get the details just right since this is going deep 
towards the roots of our vision.

I have some detailed comments below, but nothing that affects the adoption call.

On 1 Jun 2023, at 22:55, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Hi Quifang,

The latest update looks very good to me - IMO, ready for adoption.

Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed?

Thanks,
Kent

Quifang,

Thank you for the updated draft. I think each version is getting better :-) but 
I still have some comments.

+ Section 1, Introduction

   Immutability is an existing model handling practice.  While in some
   cases it is needed, it also has disadvantages, therefore it MUST be
   avoided wherever possible.


While I strongly agree with the view stated here, I don't think we can have a 
MUST requirement on something so nebulous as "whenever possible". Change to 
SHOULD?

+ Section 1.2, Applicability

   The immutability of data nodes
   is protocol and user independent.

I agree fully that the immutability concept should be protocol and user 
independent (i.e. works the same for both NC/RC/xC and all users). I would also 
like to add that immutability needs to be independent of operational state, 
i.e. that immutable nodes are immutable from time of creation and remain so for 
as long as they exist. The immutability property and configured value of an 
existing node must only change by software update.

+ Section 2, Solution overview

   However, the following operations SHOULD be allowed for immutable
   nodes:

   *  Use a create, update, delete/remove operation on an immutable node
  if the effective change is null.  E.g., if a leaf has a current
  value of "5" it should be allowed to replace it with a value of
  "5"

   *  Create an immutable data node with a same value that already
  exists in  or  (if exists) in order to e.g.,
  configure a mutable descendant or reference it in a "when", "must"
  or "leafref" expression.

   *  Delete an immutable data node from read-write configuration
  datastores (i.e., ,  and ) which do
  not prevent the data node still appearing in  or
   (if exists)

By the already established rules of 7950, I think the above statements are 
already MUST requirements. It may be good to clarify/restate that expectation 
here, but if so, I find it essential not to weaken the requirement to SHOULD 
(in the first cited line above) , but keep it MUST.

+ Section 6.1, Definition

   Note that "immutable" metadata annotation is used to annotate data
   node instances.  A list may have multiple entries/instances in the
   data tree, "immutable" can annotate some of the instances as read-
   only, while others are read-write.


I think the immutable annotation on individual instances is useful, meaning 
those list instances would always have to be present. This is however getting 
very close to the edge for some of the deep no-nos for me. Let's say there is a 
management interface that always has to exist for the configuration to be 
valid. Annotating that with immutable seems ok. But if someone suggests that 
some of these must-exist list elements can vary over time, i.e. sometimes have 
to exist, sometimes not, then I'm out. Not supportive.

Basically, I don't want to ever get into a situation where I have a backup from 
time t that is not valid at some later time t+1.

+ Section A.5, UC5 - Immutable BGP peer type

 list neighbor {
   key "remote-address";
   leaf remote-address {
 type inet:ip-address;
 description
   "The remote IP address of this entry's BGP peer.";
   }
   leaf peer-type {
 im:immutable;
 type enumeration {
   enum ebgp {
description
  "External (EBGP) peer.";
   }
   enum ibgp {
 description
   "Internal (IBGP) peer.";
   }
 }
 mandatory true;
 description
   "Specify the type of peering session associated with this
neighbor. The value can be IBGP or EBGP.";
   }


In my opinion, this use case is taking the immutability concept too far. It 
creates more problems than it solves. A configuration that was valid at time t 
may no longer be valid at time t+1.

Someone may argue that this use case is similar to UC2 in section A.2, which is 
an interface list with the interface type being immutable. I think UC2 is ok if 
the set of immutable list nodes is constant as long as the hardware 
capabilities and software version remains the same.

With UC5, the dependency is towards an external system that could basically 
change at any time. I don't want immutable nodes to appear, disappear or change 
value unless we're doing something 

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Jan Lindblad (jlindbla)]

I am not aware of any IPR that applies to this draft.
/Jan Lindblad


On 25 Apr 2023, at 00:04, Kent Watsen mailto:k...@watsen.net>> 
wrote:

Bo and Jan (CC-ed),

Please reply-all to this email with your response to the original IPR call here:
https://mailarchive.ietf.org/arch/msg/netmod/xHDWFr5e2ykRBEseq-99PhRENGM/


Jason, thank you for highlighting this issue to the chairs.

Kent // as chair


On Apr 24, 2023, at 5:48 PM, Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>> wrote:

Hello chairs and WG,

(as an author)

We've updated both drafts to refactor Acknowledgements vs Contributors:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/09/
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/11/

The IPR call for Module Versioning is complete. It already included all authors 
+ contributors.

For YANG Semver, we're missing IPR declarations from the following people (we 
didn't include them in the original IPR call):
 Bo Wu
 lana.w...@huawei.com

 Jan Lindblad
 jlind...@cisco.com

Rgds,
Jason

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: Monday, March 13, 2023 7:35 PM
To: netmod@ietf.org
Cc: Rob Wilton (rwilton) 
Subject: Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09


CAUTION: This is an external email. Please be very careful when clicking links 
or
opening attachments. See http://nok.it/ext for additional information.



Authors/All,

One of the authors pointed out that the list of contributors was incomplete, and
specifically didn't include all listed in the paragraph of the contributors 
section.
We had mistakenly read this paragraph as Acknowledgments versus
Contributors.  It does appear that some of those listed may be Contributors, 
i.e.,
materially contributed to the technical solution or the text (excluding 
editorial
changes),  while others may in fact belong in an Acknowledgement section.
Given this, we'd like to ask the authors to refactor the Contributors section 
into
separate Acknowledgement and Contributor sections before moving forward on
this document.  Once we have the new version, we can then judge if there are
any missing IPR statements.

Thank you,

Kent and Lou


On Jan 16, 2023, at 5:59 PM, Kent Watsen  wrote:

[NOTE: A response is needed from all listed in this message's "To" line, the
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WGLC Call:

 Are you aware of any IPR that applies to drafts identified above?

Please state either:

 "No, I'm not aware of any IPR that applies to this draft"
or
 "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

 "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
 "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This
document will not advance to the next stage until a response
has been received from each author.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent and Lou

PS Please include all listed in the headers of this message in your
response.
___
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

___
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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Jan Lindblad (jlindbla)]

Qiufang,

Thank you for your continued work on this. I think the critical point to decide 
now is which use cases are in and which are out.

If we decide that only the five or six use cases listed currently in -06 are 
included, I'm quite happy about standardizing some YANG extension and metadata 
keywords for them. As I mentioned earlier, I think a slightly simpler solution 
would be sufficient and preferable for the current, rather small and simple set 
of use cases. If someone prefers the solution proposed in -06 because it better 
caters for some not yet listed use case, please share that use case so we can 
see the whole picture and discuss.

I think that regarding the isInvariant concept in the liaison, 3GPP is asking 
to model the object which cannot be modified once created. While it's just a 
natural workaround for the clients to first delete it and then recreate with 
the really desired value, but not requiring that clients must do that.

Objects that cannot be modified once created cannot exist in a transactional 
protocol. If we introduce such objects, that would seriously detract from the 
value of NETCONF/YANG (XC/Y). Rather than watering down XC/Y to match the 
expectations by legacy management protocols, I'd suggest we ask servers that 
want to advertise themselves as XC/Y servers to add the missing functionality 
to their implementation. This is not unreasonable, as many, many server 
implementors have already done so across many industries.

If a particular vendor is unable or unwilling to implement a server to industry 
expectations, there is no way for me or anyone to prevent that vendor from 
releasing a YANG module with some proprietary extensions to describe that 
behavior. In fact, several already have, and that's probably fine. I just don't 
understand why IETF should spend valuable time to confuse he market and 
standardize such backward things. If 3GPP thinks the create-no-modify concept 
is valuable in the world of automation interfaces, they could release a 3GPP 
YANG module with such extensions.

As Jan pointed out, all the use cases written in the current document now are 
targeting configuration cannot be updated or deleted. I also feel it better to 
define identities to only support our current use cases now, and leave the door 
open to allow other implementation to extend more if needed.

While I like the flexibility with identities, they would really remove most of 
the value of standardization in this case. YANG already allows any vendor to 
invent their own extension keywords. If we standardize a new extension that 
relies on identities specified by vendors, we have not really gained much.

Again, as mentioned, the objective is to document existing server behaviors, if 
the server already internally considers some configuration immutable for valid 
reasons. It doesn't apply to servers which don't have any immutable 
configuration, much less to encourage servers to add more such restrictions. 
The document should be updated if it failed to make that clear.

I'm fine with marking some parts of the configuration as immutable/impossible 
to change. This may cause some operational trouble in the field, but not as 
much as non-transactionality. It is the non-transactional behavior I find 
really hard to live with. Let's first decide which use cases we are addressing, 
then find the least intrusive solution to that set.

Best Regards,
/jan




From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, April 6, 2023 12:12 AM
To: Rob Wilton (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 the draft specifies (not the liaison), 
since you wrote:

"Fundamentally, I generally interpret this draft as saying:  NETCONF/YANG 
doesn't really match the existing management model/API in 3GPP and hence we 
want to make non-backwards compatible changes to NETCONF/YANG to match the 3GPP 
semantics."

Which isn't the draft's proposition.  Maybe you meant s/draft/liaison/?


I just re-read the liaison and I fail to see how the immutable-flag draft's 
goal of describing existing server behavior isn't aligned with the liaison.  At 
the end of the day, it doesn't really matter what extensions exist in the YANG, 
or annotations in the data, the client can send any request it wants to the 
server and, ultimately, the server must enforce whatever it wants to enforce.

It effectively comes down to a quality-assurance effort to determine if the 
YANG accurately describes the server's existing behavior.  To the extent that 
XC/Y tools might someday grok the YANG-extensions and/or data-annotations (to 
do some of the heavy-lifting) is out of scope, IMO.

I'm unsure if the set of the extensions and annotations in the curr

[netmod] Comments on draft-ma-netmod-immutable-flag-06

[Jan Lindblad (jlindbla)]

Quifang,

Thank you for the excellent presentations at the NETMOD session today. I 
understand how and why the immutability topic is important to 3GPP, and several 
other IETF liaised organizations, and I certainly think we should respond to 
their liaison inquiry in a timely manner.

In my opinion, that response should be along the lines that we understand and 
support the use cases as put forward in the liaison statement. We should say 
that NETMOD is working on a solution which provides an operationally useful way 
of handling all the use cases without changing the fundamental properties of 
the existing management protocols and modeling standards.

Going a level deeper into what that solution should look like, I have read the 
latest immutable draft, draft-ma-netmod-immutable-flag-06. It lists six use 
cases, which I think are the key to resolving this. I think our liaison 
response should focus on them. I noted that UC5 is qualitatively very different 
from how it was in -05. 

In the below, I first discuss why immutable is not already part of 
NETCONF/RESTCONF/.../YANG (will call this XC/Y), then go through each of the 
use cases. At the end, I also have a few comments about the proposed YANG 
constructs. In order to write the liaison response, I think getting our minds 
into agreement about the approach to the use cases is the important thing, and 
probably also enough. The exact YANG expression may be agreed later, after 
responding to the liaison statement.


As emphasized in the draft, a NETCONF server can reject any configuration 
attempt at any time for any reason. So by this logic, what the immutable draft 
proposes is "nothing new", it's just documenting some of the cases in which 
such a rejection will happen. This is true, but by this reasoning there is no 
limit to what sort of rules could be added to XC/Y. Just because there is a 
possibility to reject for any reason doesn't mean that you can impose any set 
of additional rules on top of YANG and still call it YANG. 

Servers often call upon the possibility to "randomly" reject when they are 
running out of memory. Or when certain instances (e.g. mgmt interface) are 
being deleted, but simply has to be in the config at all times. This is fine, 
since few operators desire configs that exceed the available memory (and it is 
generally hard to predict+describe exactly when that happens) or removes the 
mgmt interface. The problems arise when operators want to go live with a config 
that is fundamentally valid, but the server rejects *at this time* due to some 
settings in the current configuration. 

Such constraints were (are) common in the CLI and SNMP world, and for good 
reason in their usage context. Servers are being nice when they protect 
operators from goofing. But to apply those same safeguards in a high level 
automation context is not a good idea, since it complicates, slows or prevents 
core automation use cases. For example, if the "safeguards" require a 
transaction to be split into two transactions, the solution is no longer 
transactional, and something has been fundamentally lost. The good news is that 
I think there are good solutions to the six use cases that preserve the 
fundamental properties of our management protocols.

 
The immutable-flag draft often refers to "problems" where constructs are not 
allowed in YANG. Here's a typical example:
 
   However, this is not possible as 'supported-timer-values' must be
   read-only thus config=false while 'interface-timer' must be writable
   thus config=true.  According to the rules of YANG it is not allowed
   to put a constraint between config true and false schema nodes.
 
This text seems to forget that these YANG rules, e.g. the rule that you cannot 
have config true objects below or otherwise depending on a config false one, 
were a super-conscious choice made when designing YANG. The SNMP world 
"transient configuration" gave operators a lot of gray hairs, so was given as a 
requirement to the NETCONF work to get rid of. So it was that such things are 
now very deliberately made impossible to model in YANG. The immutable draft is 
trying to reintroduce this (at least in some cases) in YANG. But if we change 
YANG to allow this sort of behavior in general, the additional value of XC/Y is 
lost, and we're back where we started (SNMP-level automation functionality) 20 
years ago. Now with two competing, but equally useless configuration mechanisms.

In the routing domain, and in many others, it has proven possible to leave 
those old practices behind and build quite functional management interfaces 
even within the confines of current XC/Y rules. I am convinced that this is 
possible in the 5G world too. I am well aware of the traditions in the 3G/4G/5G 
world, where the immutable and other concepts were born long ago and are still 
considered core functionality today. I have helped many XC/Y server developing 
organizations to overcome these traditions, which used to be 

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Jan Lindblad (jlindbla)]

Hi,

This is becoming a long thread, and it is already recurring theme. It is a 
quite interesting and perhaps necessary discussion, but I think a summary of 
the questions at hand is in order.


Question 1: Data store validity according to current RFCs

Some of the debate concerns what current RFCs say about data store validity. I 
believe it is stated quite clearly in RFC 8342 (NMDA), and is supported by RFC 
7950 (YANG 1.1) as well as earlier works that:

a) Datastores that MUST be valid for edit-config/edit-data to succeed are 
:running, :intended, :startup

b) Datastores that MUST be valid for commit to succeed are :candidate (and 
private candidate datastores, as far as they are being discussed)

c) Datastores that do not need to be valid are :operational, :system, :learned, 
:default and other dynamic configuration datastores


Question 2: Validity relation between :running and :intended

Pre-NMDA there is no difference between :running and :intended, so if one is 
valid, the other is valid too. Simple. With NMDA, some transformations between 
the two are allowed. Implementations will most certainly want to validate only 
once for each edit-config/edit-data/commit, so should that be on :intended or 
:running?

I think validating either one works fine, but on one condition: that the 
transformations applied guarantees that the validity of the datastores stay 
interlinked. If :running is valid that implies :intended is valid. And also, if 
:intended is valid, that implies :running is valid.

This requirement obviously puts some rather serious constraints on what you can 
do. Server implementors will have to be rather restrictive on what 
transformations are applied between :running and :intended, or they will have 
to be a little more cautious about what YANG constraints they proclaim in the 
server's YANG interface. Any YANG constraints need to be general enough to 
apply to both :running and :intended.

Nobody forces a server implementor to declare any constraints (that they may 
feel are difficult to uphold) in their YANG interfaces. But if this means the 
server often uses its right to "randomly" refuse configuration change without 
apparent reason, as seen from a YANG perspective, we may be headed back to the 
dark SNMP ages again even if this is allowed by current RFCs.


Question 3: Proposed changes to NMDA-validity model

There have been some proposals to change the NMDA (and also YANG 1.1) validity 
model in various ways. In several proposals the idea is that the YANG 
constraints should apply only to :intended, or to :intended merged with the 
:system datastore in some way or other (where :system may or may not refer to 
the :system datastore as described in NMDA).

Since this question is not about agreed upon RFC contents, it is a matter of 
opinion, taste and architecture.

As you may be aware, I have voiced rather strong skepticism around changing the 
validity model, but please allow me to nuance and explain this stance a little.

I believe one of the real values brought to network management by NETCONF/YANG 
is the introduction of clearly documented and trustworthy management interfaces 
with predictable behavior. If we change the validity of the YANG interface 
description to only apply to :intended, what do we know about the rules of 
:running? A client cannot write to :intended, but has access to :running 
(possibly only indirectly through :candidate or :startup).

Currently there is no formal way for a device to describe what the 
transformation step between :running and :intended does, so in principle the 
client has no way of knowing what rules apply to :running. We're back to the 
lawless land of SNMP. What most clients would do is either to start reading up 
on vendor specific interface descriptions in english (bye bye automation level 
3 and higher), or assume the YANG interface description is relevant for 
:running anyway and hope for the best. Not very attractive IMO.

Another reason to keep the YANG constraints relevant for :running is that this 
is what a fair amount of pre-NMDA clients (rightfully) assume.

I can see two paths forward, if we want to separate the validity of :intended 
from :running. Either servers will need a way to describe the transformations 
done between the two, so that clients can figure out what is valid or not for 
themselves. Or we will need to introduce separate YANG descriptions for 
:running and :intended. Realistically, I expect this could would be done with 
some sort of YANG extensions that declare which constraints that do not apply 
to :intended, or which additional constraints should be placed on it.


Question 4: Datastore validity with respect to hardware/environment

In YANG, great care has been taken to design it such that it is possible to 
express formal validity constraints only within the upcoming configuration. 
Specifically, it is not possible to express constraints towards the current 
configuration, nor to the operational 

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Jan Lindblad (jlindbla)]

No, I'm not aware of any IPR that applies to this draft

/Jan Lindblad



> On 16 Jan 2023, at 23:59, Kent Watsen  wrote:
> 
> [NOTE: A response is needed from all listed in this message's "To" line, the 
> authors and contributors listed in the draft]
> 
> 
> Authors, Contributors, WG,
> 
> In preparation for a WGLC Call:
> 
>   Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
>   "No, I'm not aware of any IPR that applies to this draft"
> or
>   "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
>   "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
>   "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate. If you are listed as a document author or contributor
> please answer the above by responding to this email regardless
> of whether or not you are aware of any relevant IPR. This 
> document will not advance to the next stage until a response
> has been received from each author.
> 
> If you are on the WG email list or attend WG meetings but are not
> listed as an author or contributor, we remind you of your obligations
> under the IETF IPR rules which encourages you to notify the IETF 
> if you are aware of IPR of others on an IETF contribution, or to
> refrain from participating in any contribution or discussion related
> to your undisclosed IPR. For more information, please see the RFCs
> listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> Kent and Lou
> 
> PS Please include all listed in the headers of this message in your
> response.
> ___
> 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] [Anima] mcr's YANG question raised during the ANIMA WG session

[Jan Lindblad (jlindbla)]

Michael,

> I have taken a third pass at getting the extension of yang modules done.

Sorry for my slow response. I had a look at your latest version now, and I 
think it looks good from a general YANG pov. 

> This time, I am using RFC8791 (Structure), rather than YANG-DATA.
> I do not use Augment (or structure-augment).  Not sure how I would.

Yes, if what you want is to describe protocol messages, sx:structure would be a 
good way to package this.

> My module D, which wants to inherit from A, B and C, even though B and C also
> inherit from A, looks like this:
> 
>  sx:structure module-D-things {
>uses module-D;
>  }
> 
>  grouping module-D {
>description "A module D structure";
>container module-D {
>  description "A wrapper container for the module-D things";
>  uses vA3:module-A-contents;
>  uses vB3:module-B-contents;
>  uses vC3:module-C-contents;
>  uses module-D-contents;
>}
>  }
> 
>  grouping module-D-contents {
>leaf attribute-D-Delta {
>  type binary;
>  description "DeltaThree";
>}
>  }
> 
> This produces a tree printout of:
> 
> module: module-D3
> 
>  grouping module-D:
>+-- module-D
>   +-- attribute-A-Alpha?   binary
>   +-- attribute-B-Beta?binary
>   +-- attribute-C-Gamma?   binary
>   +-- attribute-D-Delta?   binary
>  grouping module-D-contents:
>+-- attribute-D-Delta?   binary
> 
> This is not great, but better than before.

What aspect of this solution do you consider less than optimal? That's not 
quite obvious to me.

If any of this causes problems with SID generation, I'm afraid that's not my 
territory. :-)

> The results are still at:
> 
>https://github.com/mcr/yang-augment-test
>look at module-?3.yang and practice3.sh.

Thanks for putting this in concrete and easily accessible form, i.e. as 
compilable YANG modules on github.

Best Regards,
/jan


> 
> Please tell me/us (ANIMA WG) if we can do better.
> We have revisions to RFC8366 that we'd like to go forward with, but we need
> to make sure that we accomodate the extensions that are planned.
> Probably converting to RFC8791 is also a good thing.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption call for draft-ma-netmod-with-system-05

[Jan Lindblad (jlindbla)]

As contributor, I support the adoption of this draft.
/Jan


On 1 Nov 2022, at 23:27, Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com>> wrote:

Hi all,

I support the adoption of this draft. I think this is a worthwhile topic to 
work on. We do still need some discussions on the details of the solution.

I'm a bit tied up with the YANG versioning work/drafts at the moment so I'll 
have limited time to dedicate to work on this in the short term (but will try). 
But it does need a good cross section of different people involved and 
reviewing IMO to make sure it is broadly applicable.

Jason

-Original Message-
From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Kent Watsen
Sent: Monday, October 17, 2022 10:54 AM
To: netmod@ietf.org
Subject: [netmod] Adoption call for draft-ma-netmod-with-system-05

NETMOD WG,

This email begins a 2-week adoption poll for:

   https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-05


Please voice your support or objections on list before Nov 1st.

Notes:
  1) The authors addressed the issues raised in the 114 meeting.
  2) No IPR has been declared.


Kent // NETMOD Chair

___
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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR Poll on draft-ietf-netmod-with-system

[Jan Lindblad (jlindbla)]

No, I'm not aware of any IPR that applies to this draft

Best Regards,
/Jan

On 13 Oct 2022, at 03:23, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

[NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WG Adoption Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This
document will not advance to the next stage until a response
has been received from each author.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent (Co-Chair)

PS Please include all listed in the headers of this message in your
response.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR Poll on draft-ietf-netmod-with-system

[Jan Lindblad (jlindbla)]

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
/Jan

> On 13 Oct 2022, at 03:23, Kent Watsen  wrote:
> 
> [NOTE: A response is needed from all listed in this message's "To" line, the 
> authors and contributors listed in the draft]
> 
> 
> Authors, Contributors, WG,
> 
> In preparation for a WG Adoption Call:
> 
>   Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
>   "No, I'm not aware of any IPR that applies to this draft"
> or
>   "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
>   "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
>   "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate. If you are listed as a document author or contributor
> please answer the above by responding to this email regardless
> of whether or not you are aware of any relevant IPR. This 
> document will not advance to the next stage until a response
> has been received from each author.
> 
> If you are on the WG email list or attend WG meetings but are not
> listed as an author or contributor, we remind you of your obligations
> under the IETF IPR rules which encourages you to notify the IETF 
> if you are aware of IPR of others on an IETF contribution, or to
> refrain from participating in any contribution or discussion related
> to your undisclosed IPR. For more information, please see the RFCs
> listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> Kent (Co-Chair)
> 
> PS Please include all listed in the headers of this message in your
> response.
> ___
> 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

[netmod] Unintended when-expression semantics in many IETF YANG modules

[Jan Lindblad (jlindbla)]

Hi NETMOD,

A few days ago, as I was looking for examples of when-expressions in standard 
modules, I stumbled over this in RFC 8944:

 augment "/nw:networks/nw:network" {
   when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
 description
   "Augmentation parameters apply only for networks
with L2 topology.";
   }
   description
 "Configuration parameters for the L2 network
  as a whole.";
   uses l2-topology-attributes;
 }

... and a few other similar constructs in there.

As you can see the when expression is unconstrained when it comes to which 
network it refers to, which changes the semantics from "Augmentation parameters 
apply only for networks with L2 topology" as the authors are wishing for to 
"Augmentation parameters apply to all networks as soon as there is at least one 
with L2 topology".

Aside from RFC 8944, I also noticed very similar problems in RFC 9094, RFC 
8542, RFC 8294, RFC 8513 and RFC 8782. The list may be incomplete.

What do we do with the broken YANGs modules in these RFCs?

Since this seems to be a rather frequently occurring issue, are there any 
mitigation steps we should take in NETMOD, apart from strengthening the YANG 
Doctor review process?

What can we reasonably do to ensure all YANG Doctor reviews catch these valid, 
but unintended XPath expressions before publication?

Best Regards,
/Jan Lindblad

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Jan Lindblad (jlindbla)]

Kent, Balazs,
I don’t see a specific need for timestamps, so I can accept your arguments 
against it. Just add a sentence about it somewhere into the draft. It can be an 
appendix.
OK with me.
A timestamp could be added in the future if it is really important enough.

LastModified is drop-dead simple to do and achieves equivalency, no more 
justification is needed.

The same rules apply:

- ETag is a MUST, LastModified is a MAY
- root-node is a MUST, inner-nodes is a MAY

I'm perfectly fine with this. Since we are in agreement maybe I should just 
stop here.

Since I noted that I haven't done a good job at explaining how the ETag 
mechanism works, let me take the example below and explain how this situation 
is avoided using ETags.

I also realized that servers supporting Last-Modified in deeper levels than 
just the root can do the same thing as I explain for ETags below.

f this isn't obvious, here's an example:
1. Client A sends an edit to the server If-Unmodified-Since t0. Successful. 
Receives a Last-Modified timestamp t1.
2. Client B sends a an edit to the server. Last-Modified timestamp on server is 
now t2.
3. Client A sends an edit to the server without If-Unmodified-Since. It just 
sets one tiny little leaf off in one corner. Successful. Received a 
Last-Modified timestamp t3.
4. Client A sends an edit to the server If-Unmodified-Since t3. Successful, but 
clobbers Client B's edit, leading to a misconfiguration, which opens a security 
hole.

This is because the If-Unmodified-Since uses less than or equal in its test. 
The ETag mechanism is not susceptible to this issue, as it uses an equality 
test.

I don't think this example is valid.   Skipping past the obvious programming 
error, the equivalency you're trying to make applies to Etags too.

1. Client A sends an edit to the server If-Match e0. Successful. Receives a 
ETag e1.
2. Client B sends a an edit to the server. ETag on server is now e2.
3. Client A sends an edit to the server without If-Match. It just sets one tiny 
little leaf off in one corner. Successful. Received a ETag e3.
4. Client A sends an edit to the server If-Match e3. Successful, but clobbers 
Client B's edit, leading to a misconfiguration, which opens a security hole.

Here's the same example again in some greater detail.

1. Client A edits server:/{eQ}ifs/{eR}interface[name="1/1/1"]{eZ}/... where 
{eX} means that the client asks the server to confirm the ETag value X sits at 
the path to the left before committing. Success. Server returns new ETag eB on 
/ (the root), /ifs and interface 1/1/1.
2. Client B edits server:/acls[name="intf 1/1/1"]/... and server sets ETag eF 
on / and /acl intf 1/1/1.
3. Client A edits server:/users/user[name="joe"]/password without any ETag 
check. Server sets eY on / and /users.
4. Client A edits server:/{eY}acls[name="intf 1/1/1"]{eB}/... . Check eB fails 
(server has eF), edit aborted.

Best Regards,
/Jan

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] The "resolve-system" parameter in the new "with-system" I-D

[Jan Lindblad (jlindbla)]

Kent, WG,

> [As a contributor]
> 
> This message regards the value of the "resolve-system” parameter defined in 
> the latest “with-system” draft.
> 
> The "resolve-system” parameter is defined in its own optional-to-implement 
> module.  The question is if the WG believes the parameter is valuable or if 
> the module should be removed from the draft before adoption call?

I believe the resolve-system parameter has value in certain use cases. In 
particular I think the flag matches common expectations from the RESTCONF 
community, where a complete understanding of the server's configuration is 
rarely desired, and where injecting multiple, disjunct pieces of configuration 
is perceived as complicated by some.

To model the resolve-system flag as an optional capability is the best trade 
off in my opinion. For some device types it doesn't make sense to implement 
this flag, while for other device types, this might become the typical client 
behavior.

Best Regards,
/jan

> The "resolve-system” parameter is a convenience function, enabling clients to 
> NOT have “manually” copy/paste referenced system-defined nodes into 
> .  Instead, by including this parameter in , , 
> or equivalents, the client requests the server to itself copy/paste the 
> missing system nodes into . 
> 
> It is true that this work began with a goal of never having to copy/paste 
> system-defined nodes into .   The concern wasn’t about *how* the 
> referenced system-defined nodes came to be in , but *if* they needed 
> to be in  at all.   But now that the current draft says referenced 
> system-nodes MUST be in , the only remaining question regards *how* 
> they came to be in .  
> 
> Yes, there is convenience in using the “resolve-system” parameter, but there 
> is also some implementation complexity.   Ultimately, the question is, is the 
> convenience worth the complexity?   Thoughts?
> 
> Thanks,
> Kent
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Use XML namespaces in YANG document examples

[Jan Lindblad (jlindbla)]

Just to add to the complexity here, it's not only about identityrefs.

People (including IETF) have also defined types that use qname:s inside YANG 
strings, which the servers and clients would have to recognize and treat 
properly in order to interoperate well.

module ietf-yang-types {
...
  typedef xpath1.0 {
type string;
description
 "This type represents an XPATH 1.0 expression.

  When a schema node is defined that uses this type, the
  description of the schema node MUST specify the XPath
  context in which the XPath expression is evaluated.";
reference
 "XPATH: XML Path Language (XPath) Version 1.0";
  }


/jan

On 14 Feb 2022, at 10:05, Ladislav Lhotka 
mailto:ladislav.lho...@nic.cz>> wrote:

Andy Bierman mailto:a...@yumaworks.com>> writes:

On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de>
 wrote:

I agree that this should not go forward as is.

The XML representation of YANG instance data does indeed use QNames in
element values and hence applications must be able to resolve XML
namespace prefixes. If this is not clear enough in RFC 7950, then we
need to address the lack of clarity where it belongs to be addressed.

If we were to add a warning to all (past and) future YANG modules to
help implementors who did not read RFC 7950, then the warning should
be concise ("Applications using the XML representation of YANG
instance data must be able to resolve XML namespace prefixes."). My
preference, though, is to assume that implementors read RFC 7950 when
they are not sure how to implement the prefixes correctly.


It seems clear that this is not an issue specific to a particular YANG
module,
so the fix needs to be an errata against RFC 7950.
The text in question is probably limited to the first paragraph (first
sentence).

9.10.3 .
Lexical Representation

  An identityref is lexically represented as the referred identity's
  qualified name as defined in [XML-NAMES
].  If
the prefix is not
  present, the namespace of the identityref is the default namespace
  in effect on the element that contains the identityref value.



The problem is that XML-NAMES only applies to elements and attributes (not
string node content).

I looked into XSLT 2.0, sec. 5.1 [1], hoping that we could use it as a model, 
but it became clear to me that we have a bigger problem: equality of 
identityref values isn't properly defined in YANG. We resolved this in YANG 1.1 
for identityrefs appearing in XPath expressions by adding the functions 
"derived-from" and "derived-from-or-self", but the problem still persists e.g. 
when comparing identityref values serving as list keys (sec. 9.1 in RFC 7950 
doesn't help here).

Lada

[1] https://www.w3.org/TR/xslt20/#qname


I do not know the proper replacement text for the first sentence, but it
seems maybe
a specific definition of the expanded name for identityref:

  The expanded name for an identityref value consists of a namespace name
equal
  to a module namespace (defined in 5.3) and a local name equal to an
identity identifier.
  The reffered identity is defined within the module bound to the module
namespace
  value.



/js



Andy



On Sat, Feb 12, 2022 at 12:54:18PM +, tom petch wrote:
Going back to the original issue and so top-posting.

NSF Monitoring Interface YANG Data Model
is on the IESG Telechat  17feb2022.

It contains the text - not an easy read unless you are an XML expert -
"In order for the XML
  data to be used correctly, the prefix (i.e., the characters before
  the colon or 'nsfmi' in the example) in the content of the element
  that uses the "identityref" type (e.g., /i2nsf-event/i2nsf-system-
  detection-alarm/alarm-category/) in the YANG module described in this
  document MUST be the same as the namespace prefix (i.e., 'nsfmi' in
  the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
  monitoring.  Therefore, XML software MUST be chosen that makes the
  namespace prefix information available."

This is the result of discussions between IANA and the XML directorate,
which I have seen copied to the WG list, and seems to me to be in direct
contradiction of the consensus of the NETMOD WG list as shown in the
discussions this month on this thread over the DHCP I-D and a separate
thread on the I2NSF I-D in January and is likely to be a source of
confusion for the future.

NSF-Facing Interface YANG Data Model
is on the same Telechat but I do not see the same text.

I would like an AD to throw a flag, in the shape of a DISCUSS so I am
copying Robert.

My take is that the text should not be included in any I-D based on the
consensus of the NETMOD WG (as I perceive it).  One suggestion was that it
needed an update to RFC7950 to make it justified.

(Also, my rant of 2022, these late stage non-WG interventions should not

Re: [netmod] system configuration sync mechanism

[Jan Lindblad (jlindbla)]

Hi,

Sorry for getting late into this already unwieldy thread. Similar discussions 
have been flaring up regularly for as long as this work group has existed, and 
we have never been able to put it to final rest. At the heart of the issue is 
the age old division between "unpredictable" and "lazy" managed systems 
(NETCONF servers).

Unpredictable systems: systems that modify and extend their running 
configuration spontaneously (outside standards)
Lazy systems: systems that treat running as sacred scriptures of the gods 
(operator community and management systems)

There are NETCONF servers out there of both types (and across the spectrum in 
between), with huge implementation investments and future aspirations. Nothing 
is going to remove either approach from the market any time soon. My point is 
that when new protocol extensions are presented, such as the system datastore, 
their implications need to be evaluated for both categories of systems.

There has been a large number of point questions discussed in this thread, and 
I don't envy the draft authors to try to make sense of it all. An interim call, 
as suggested by Jason, may be the best answer, if the draft team can put 
together a material with decision points to cover.

Jason made several important points that I'd like to underscore imho:

One of the pretty fundamental issues IMO is whether we want good ol' standard 
 to always be valid (including for an offline client or tool to be 
able to validate instance data retrieved from a server against the YANG models).

I find this an essential concept for running. Much depends on this tenet.

I agree there can be dynamically added system config (e.g. create a new qos 
policy, and some queue list entries are automatically created inside that 
policy).

This is the defining trait of "unpredictable" systems, and there are many of 
those. There are also many "lazy" systems, which would never allow this.

Best Regards,
/jan



TL;DR defining typical "unpredictable" (U) and "lazy" (L) NETCONF server 
behavior.

+ Factory reset
U: creates a default user, scans the hardware and injects default line card 
configs in running
L: creates a default user, scans the hardware and injects default line card 
configs in running

+ Insert new line card
U: creates a default config for inserted line card and interfaces, maybe adds a 
suitable default speed leaf depending on hardware type
L: no change of running, but reflects insertion in operational and maybe with a 
notification

+ Configure parameters of interface on inserted line card
U: only changed parameters need to be written as running already has the 
interface
L: entire interface needs to be created in running with desired parameters

+ Remove that line card
U: removes the config for the ejected line card
L: no change of running, but operational now reflects the interface state as 
[hardware missing]

+ Reinsert the line card
U: creates a default config for inserted line card, maybe adds a suitable 
default speed leaf depending on hardware type
L: no change of running, but interface comes back on line as previously 
configured and operational now reflects the interface state as [up]

+ Reconfigure the interface type of existing interface
U: rejected
L: accepted, but operational state now reflects the interface state as 
[hardware mismatch]

+ Reconfigure the name of an interface
U: rejected
L: accepted if the name could be valid for this device, but operational state 
now reflects the interface state as [hardware missing]

+ Install backup
U: If the set of interfaces in the backup is a subset of currently present 
hardware, it is activated, otherwise rejected
L: accepted. If any hardware is currently missing as configured in the backup, 
their operational state is shown as [hardware missing]

A variant that falls between U and L might be a system that considers the 
insertion of a line card an "act of configuration". Hardware manipulation could 
be considered a kind of (so far proprietary) protocol with defined 
configuration semantics. The behavior of such a system might be exactly like a 
"lazy" system except in the "Configure parameters of interface on inserted line 
card" use case, where it behaves like an "unpredictable" system when there is 
no prior config for the card.

Thanks for reading the TLDR.
/jan


On 18 Aug 2021, at 01:34, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

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 
mailto:kent%2bi...@watsen.net>> wrote:

>IMO this draft overlaps the factory-default datastore.
>Unfortunately, RFC 8808 does not document NMDA, Appendix A3 details
>https://datatracker.ietf.org/doc/html/rfc8342#appendix-A.3
>It does not say if  datastore feeds into  or into 
>.
>It is not clear how  

Re: [netmod] Liaison statement to ORAN

[Jan Lindblad (jlindbla)]

Balázs,

+1
I think this is an important message to O-RAN, and I know similar ideas have 
been up for discussions in other SDOs as well. I think your proposed way of 
conveying the message is good.

Best Regards,
/jan


On 18 Nov 2020, at 09:09, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org>>
 wrote:

Hello,
In connection to the draft 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01 I propose to 
send a liaison statement from IETF Netmod to ORAN.

The issue: 3GPP is standardizing a good number of YANG modules as part of the 
3gpp TS 28.541 and 28.623 
(https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models).
ORAN plans to re-use this models, but possibly refine them in some ways. They 
are considering using deviations to do this.
E.g. change config=true schemas node to config=false. This creates problems as 
documented in 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1

-   Deviations by an SDO (standard defining organization) prevent 
implementations from reporting their own deviations for the same nodes.

-   Deviations by an SDO prevent implementations from conforming to the 
standards specified by both SDOs.


To avoid these problems I propose to send the following text to ORAN:

“IETF NETMOD working group requests ORAN to avoid using deviations as part of 
its specification. As documented in 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1
 the usage of deviations would prevent:

  *   Vendors to implement their own deviations for the same YANG schema nodes
  *   Vendors to claim conformance to both ORAN and 3GPP specifications which 
are in some cases used as a base for the ORAN YANG models

Note: These problems with deviations exists even if YANG modules are used 
without using YANG packages.
Regards Balazs

--
Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd.
Mobile: +36-70-330-7909  email: 
balazs.leng...@ericsson.com

___
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