2.1 起因：一套新的要求
在2002年网络运维人员和协议开发者举办的一次研讨会上，运维人员认为IETF的研发并没有真正满足网络管理的要求。“2002年IAB网络管理研讨会概述”（RFC 3535）记录了这次讨论的结果，作为未来IETF网络管理相关工作的指导。
研讨会确定了一份相关技术清单（现有的或正在开发中的）及其优缺点。其中包括简单网管协议（SNMP）和命令行界面（CLI）。正如在第一章“网络管理世界必须改变。你为什么要关心这件事？”中所述，SNMP协议并不适合配置，但非常适用于监控，而CLI是一个非常脆弱的应用编程接口（API）。由于当时没有公开资料明确地记录运维人员需求，需要他们标明标准中没有充分满足的需求。分组会议产生了以下运维人员需求清单（引自RFC 3535）：
运维人员需求，摘自“2002年IAB网络管理研讨会概述”（RFC 3535）
1. 从运维人员的角度来看，易用性是任何网管技术的关键要求。
2. 必须明确区分配置数据、描述运行状态的数据和统计数据。有些设备很难确定哪些参数是管理员配置的，哪些是通过路由协议等其他机制获得的。
3. 要求能够分别从设备中获取配置数据、运行状态数据和统计数据，并能够在设备之间进行比较。
4. 需要使运维人员能够将注意力集中于整个网络的配置，而不是单个设备的配置。
5. 支持跨多个设备的配置事务将大大简化网络配置管理。
6. 给定配置A和配置B，应该可以在对网络和系统的状态变化和影响最小化的情况下生成从A到B所需的操作，重要的是要尽量减少配置变化带来的影响。
7. 转储和恢复配置的机制是运维人员所需要的原始操作。需要从/向设备中拉取/推送配置的标准。
8. 超时及链路两端的配置一致性检查须简单易行，以确定两个配置之间的更改以及配置是否一致。
9. 全网配置通常存储在中央主数据库中，并通过生成CLI命令序列或完整的配置文件转化为可以推送给设备的格式。尽管不同运维人员使用的模式非常相似，网络配置并没有通用的数据库模式。有必要对这些全网配置数据库模式的共同部分进行提取、记录和标准化。
10. 使用文本处理工具如diff等，以及版本管理工具如RCS或CVS等来处理配置非常理想，这意味着设备不应该随意地对访问控制列表等数据重新排序。
11. 管理接口上访问控制所需要的粒度需要与运行要求相匹配。典型的要求是基于角色的访问控制模型和最低权限原则，即只给予用户执行任务所需的最低权限。
12. 必须能够对不同设备之间的访问控制列表进行一致性检查。
13. 重要的是要区分配置的分布和激活某项配置。设备应该能够保留多个配置。
14. SNMP访问控制是面向数据的，而CLI访问控制通常是面向命令（任务）的。根据管理功能的不同，有时面向数据或面向任务的访问控制更有意义。因此，需要同时支持面向数据和面向任务的访问控制。
研讨会的成果集中在当前的问题上，观察合理而直接，包括支持事务、回滚、低开销以及保存和恢复设备配置数据的能力。许多观察结果使我们可以洞悉运维人员在现有网络管理解决方案中所遇到的问题，例如：缺乏对设备功能的全面覆盖，以及区分配置数据和其他类型数据的能力。
运维人员提出的一些要求包括新管理系统的易用性。这种易用性包括管理整个网络的能力，而不仅仅是管理网络中的设备。此外，设备的配置状态、操作状态和统计信息之间应该有明显的区别。配置状态是显式配置的所有内容（例如，手动分配给网络接口的IP地址），操作状态是从与其他设备交互获悉的状态（例如，从动态主机配置协议（DHCP）服务器获得的IP地址），统计信息是设备获得的使用情况和错误计数器。此外，需求中还提到应该可以暂存配置、在提交之前验证配置以及在失败的情况下回滚先前的配置。
必须指出的是，即使该文档的日期为2003年，其要求和建议仍然非常有效。每个参与自动化的协议设计者都应阅读本文档，甚至应定期重新阅读。这是在本书中包含上述14个需求的主要原因。
根据上述运维人员需求，NETCONF工作组[1]于同年成立，并创建了NETwork CONFiguration（NETCONF）协议。该协议定义了一个简单的机制，网络管理应用程序充当客户端，可以在充当服务器的设备上进行调用操作。NETCONF规范（RFC 4741）定义了一小套操作，想方设法地避免对这些操作中携带的数据提出任何要求，而允许协议携带任何数据。这种“数据模型无关”的方法允许独立定义数据模型。
NETCONF协议缺乏定义数据模型的方法，因此无法用于基于标准的工作。现有的数据建模语言，例如：XML模式定义（XSD）[https://tools.ietf.org/html/rfc6244#ref-W3CXSD][2]和文档模式定义语言（DSDL; ISODSDL）[3]，由于和域没有自然关联而被弃用。定义XML文档中一个显著的问题是定义以XML编码的数据模型或协议。NETCONF操作的使用提出了对数据内容的要求，这些要求不能与XSD和RELAX NG之类的模式语言解决的静态文档问题域共享。
2007年和2008年，IETF Operations and Management领域和Application领域讨论了NETCONF数据建模语言的问题。随后成立了NETMOD工作组[4]。由于NETCONF是用来操作基于YANG的设备的最初协议，因此最初以“NETCONF modeling”命名，最近的章程更新将其修改为“Network modeling”，以强调如今多种协议都可以使用YANG模块这一事实。
考虑到运维人员的要求已有15年的历史了，看起来以数据模型为驱动的管理范式似乎需要很长时间才能起步。这是一个公平的观点，但是必须注意，与非管理协议相比，采用和部署新的管理协议需要更长的时间。例如，指定一个新的路由协议（想想分段路由）[5]并将其部署到生产中可能要花费几年时间，但是对于管理协议（想想IPFIX[6]或NETCONF）来说，生命周期更长达十年。原因很简单：理想的情况下，新的管理协议必须在所有新旧设备上得到支持，这是新网络管理系统开始过渡到新管理模式之前的先决条件。然而，如今基于YANG / NETCONF的数据模型驱动的管理已成为行业中的一种成熟趋势。