不同于以往章节基于 CLI 的 low-level 的 NetDevOps 开发，在第九章节，我们介绍了 NETCONF 协议与 RESTCONF 协议，二者都是基于 YANG 的一种网络配置管理协议，赋予了网络设备 high-level 的API，这是基于模型的网络可编程能力的实现，是通往未来的网络可编程之路。

通过 YANG 模型对网络设备的配置进行建模描述，通过 YANG 模型的数据对于网络运维进行描述，通过 NETCONF 或者 RESTCONF 协议去进行配置管理。
这种方式有明显的优点，它的逻辑更加清晰完备，数据更加结构化、格式化，无二义性，幂等性，事务性等等，更加适合网络自动化开发。

但是它也有着明显的缺点，这些缺点大都不是因为这种模式落后，而是相对于环境和人而言。

目前网络设备对 NETCONF 协议和 YANG 的支持越来越多，但是历史原因很多网络设备并不支持，另外一些国内的网络设备也并不支持，且厂商之间在 YANG 模型上差异很大，且覆盖的配置项相对于 CLI 仍然有限，不同软件版本和型号的Yang 存在差异，相比之下，cli更加稳定。

netconf 和 yang 这些概念和方式更倾向于网络自动化开发层面，对于传统网络工程师， 这些“新兴”技术门槛过高，且与传统网络工程师的运维思路（基于 CLI 的面向过程的运维思路）不符，它是一种基于数据模型的数据驱动的运维思路。这也导致 NETCONF 协议 与 YANG 被广泛使用在相对单一的网络局部，主要用于厂商自己内部的 SDN 控制器、网管软件对网络设备的管理。

另外，RESTCONF 协议相对 NETCONF 协议，在使用上借助 RESTful API 的一些理念，从规划上而言，使用更轻便，但是由于起步较晚，参考文档比较少，官方案例也偏少，且实现的功能整体是 NETCONF 的一个子集，无论是在厂商内部还是在 NetDevOps 领域都未被广发使用，且在安全性上也有一定风险，笔者并不是特别看好，RESTCONF 如果想进一步普及，更加任重道远。


在netconf和yang层面笔者也一直有着非常矛盾的思想，用之弃之？


可能在获取数据层面用之，构建一个抽象层，支持众多采集方式，充分利用netconf和yang减少结构数据的获取成本，且在这个过程不必过分纠结 yang的统一，甚至不需要理解yang 文件的解读。


在配置推送层面，弃之，转而使用更加稳定覆盖面积更广，网工更容易接受的cli，在之上基于jinja2封装一个iac。


这也是笔者在目前阶段的一点不成熟的看法。