Re: [netmod] system configuration sync mechanism

[maqiufang (A)]

Hi, Kent:

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Wednesday, June 30, 2021 6:51 AM
To: maqiufang (A) 
Cc: netc...@ietf.org; netmod@ietf.org
Subject: Re: system configuration sync mechanism

[CC-ing NETMOD, as I think this discussion belongs on that list...please 
consider removing NETCONF in your reply]
[Qiufang Ma] Thanks, accepted.-:)

Hi Qiufang,



Hi, Kent:
Thanks for kicking off some discussion around this draft. Please see my reply 
inline.

I'm interested in this work, as it seems as if the  datastore was left 
out of the NMDA work.


1) I wish there were more examples, especially for "resource-independent” 
configuration.  I understand well enough "resource-dependent" (dynamic) 
configuration, but am unclear about what all "resource-independent” entails.  
By example, JUNOS has a concept called “JUNOS defaults”, which is effectively 
read-only and hidden-by-default configuration that, most times, must be 
referenced in order to take effect.   For instance, check the examples halfway 
down this page: https://nextheader.net/2016/06/10/junos-defaults-group.  Is 
this similar to what you have in mind?
[Qiufang Ma]  Yes. Physical-resource-independent system configuration is 
generated when the device is powered on and has nothing to do with the physical 
resource. Loopback interface may be the most common 
physical-resource-independent system configuration. To my knowledge, many 
vendors ((e.g., Huawei NE40E and Cisco IOS XR) will provide several predefined 
user groups and/or task groups which are used for authentication, authorization 
and accounting (AAA) services. Since these configurations are provided by the 
device/system, they could  be treated as system configuration. I think your  
information about the predefined hidden configuration group which contains 
preconfigured values should also be treated the same.
More examples about system configurations would be worked on and added in  the 
next version of the draft.:)

Right, the loopback interface is a common example but, more generally, I think 
"resource-independent” configuration might fall into exactly two categories:

1) config that is “applied” immediately
- ex: interfaces/lo0/unit 0/family [ inet inet6 ]
- ex: system/login/password/minimum-length=6
- ex: system/ports/console-type=vt100
- ex: system/syslog/archive-size=256k;
- ex: 
chassis/cluster/fabric-monitoring/heartbeat-interval=1000;
- ex: security/zones/security-zone/junos-host;
- ex: security/alg/sip/inactive-media-timeout=120;

2) config that is “applied” only after being referenced by other 
config (e.g., ACLs)
- ex: applications/ftp/…
- ex: applications/tftp/...
- ex: applications/smtp/…
- ex: utm/custom-objects/Adult_Material/...
- ex: utm/custom-objects/Religion/...
- ex: utm/custom-objects/Gambling/…
[Qiufang Ma] I don’t quite understand this kind of configuration, could you 
please expand? Do you mean that the predefined configurations  for a certain 
application(e.g., ftp) will not take effect until being referenced/enabled? I 
am wondering if these configuration will present in the (which 
contains all the configuration actually used by the device) before they’re 
referenced.

It would be good if we could determine if there are any other 
"resource-independent” configuration categories here.
[Qiufang Ma] Do you think there exists conditional system configuration(if the 
preceding configurations you mentioned above is not)? For example, if SSH is 
enabled on a device, SSH-related keys are automatically generated. Such 
configurations are generated at the moment when a special functionality is 
enabled.

As for "resource-dependent” configuration, I wonder how this is supposed to 
work…more specifically, I wonder to what extent the IETF needs to care how if 
works (perhaps the same could be said for "resource-independent” configuration 
too).  For instance, in JUNOS, there exists a config-template that is 
automatically applied to any user-defined interface, such as:

junos-default-profile {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-underlying-interface-unit" {
family inet;
family inet6;
}
}
}
}
Notably, RFC 8342 mentions templates as something that might be expanded when 
converting  to .  Actually, knowing that it is  
that is subject to validation, it seems that much (if not all) of  
should be consumed when converting  to  - agreed?
[Qiufang Ma] Do you mean that   should include the system 
configuration which is generated due to the expansion of templates?  I notice 
that RFC8342 says in 

[netmod] Secdir last call review of draft-ietf-netmod-nmda-diff-09

[Alexey Melnikov via Datatracker]

Reviewer: Alexey Melnikov
Review result: Has Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines an RPC operation to compare management
datastores that comply with the NMDA architecture.
The Security Considerations talks about a couple of issues specific to
the new operation:
1) sensitivity of the new "compare" operation and how access control rights
to access it should be restricted.
2) performance considerations of running "compare" and
how it can lead to Denial-of-Service, if the number of requests allowed
in any given time interval is not restricted.
I can't think of other security issues raised by this document that are
missing from it.

Nits:

In Section 6:

>   The same request in RESTCONF (using JSON format):
>
>   POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
>   Host: example.com
>   Content-Type: application/yang-data+json
>   Accept: application/yang-d

Please insert an empty line after the HTTP request header and before the
following payload, or your example is not syntactically valid.

Also, I don't "application/yang-d" in the list of registered media types on
. Did I miss it?

>   { "ietf-nmda-compare:input" {
>  "source" : "ietf-datastores:operational",
>  "target" : "ietf-datastores:intended",
>  "report-origin" : null,
>  "xpath-filter" : "/ietf-interfaces:interfaces"
>  }
>   }
>
>   The same response in RESTCONF (using JSON format):
>
>  HTTP/1.1 200 OK
>  Date: Thu, 26 Jan 2019 20:56:30 GMT
>  Server: example-server
>  Content-Type: application/yang-d

Similar to the above, you need an empty line inserted here.

>  { "ietf-nmda-compare:output" : {
>  "differences" : {
>"ietf-yang-patch:yang-patch" : {
>  "patch-id" : "interface status",
>  "comment" : "diff between intended (source) and operational",
>  "edit" : [
>{
>  "edit-id" : "1",
>  "operation" : "replace",
>  "target" : "/ietf-interfaces:interface=eth0/enabled",
>  "value" : {
> "ietf-interfaces:interface/enabled" : "false"
>  },
>  "source-value" : {
> "ietf-interfaces:interface/enabled" : "true",
> "@ietf-interfaces:interface/enabled" : {
>   "ietf-origin:origin" : "ietf-origin:learned"
> }
>   }
>},
>{
>  "edit-id" : "2",
>  "operation" : "create",
>  "target" : "/ietf-interfaces:interface=eth0/description",
>  "value" : {
> "ietf-interface:interface/description" : "ip interface"
>  }
>}
>  ]
>}
>  }
>}
>  }

Best Regards,
Alexey


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

Re: [netmod] comments on draft-ietf-netmod-yang-module-versioning-02

[Juergen Schoenwaelder]

On Wed, Jun 30, 2021 at 02:57:46PM -0700, Andy Bierman wrote:
> 
> The only extension that is really useful is "revision-or-derived".
> But I agree with all the concerns originally raised by Martin wrt/
> this should be a real-statement instead of an extension.
> This is the way import-by-revision should have worked from the start.
> 
> The draft contains some reasonable updates to YANG and YANG Guidelines
> wrt/ updating a module.. They would be appropriate for a new YANG language
> version.
> 

+1

/js

-- 
Juergen Schoenwaelder   Jacobs 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