Netconf linux ��� ���

NETCONF. Начало

Некоторые слышали, а некоторые даже уверены, что есть «простой протокол управления сетями«, больше известный как SNMP (Simple Network Management Protocol).
Но мне почти не встречались люди, знающие про NETCONF, который, как надеются его создатели, станет заменой SNMP.

Что же он из себя представляет? Это аналог SNMP? Это эволюция управления? Или это тупиковая ветвь?

Коротко о NETCONF

Итак, NETCONF — это Network Configuration Protocol (ага, слова «simple» (простой) нет, видимо, в этом его проблема). Разрабатывается он IETF NETCONF Working Group. Его «жизнь» началась в декабре 2006 с RFC 4741, а в июне 2011 выкатили RFC 6241.
Появился он из недр компании Juniper, а еще точнее является допиленным напильником Junos XML API.

Чем плох SNMP?

И правда, зачем изобретать NETCONF? Ведь SNMP еще вполне «свежий» протокол, появившийся в конце 80х (SNMPv1 в 1988). Для сравнения: telnet разрабатывался в 1969 году, а им до сих пор пользуются. Даже придумали SNMPv3 с шифрованием.

И все же, в 2002 была встреча Internet Architecture Board (IAB) Network Management Workshop, результатом которой стал RFC 3535. В частности в нем перечислены плюсы и минусы технологий управления сетями (пункт 2) и в т.ч. SNMP (пункт 2.1).

Перечислю несколько самых явных на мой взгляд минусов SNMP:

• В большинстве реализаций в качестве транспортного протокола применяется UDP. Если что-то где по пути потерялось, ну, что поделать.
• Можно записывать/считывать только одно определенное значение за один раз. Нельзя послать несколько значений в одной транзакции.
• Нет возможности откатов/бэкапов конфигурации: snmp set делает изменение сразу в активной конфигурации.
• Ограничения в SMI (например, длины некоторых полей).
• Зоопарк MIB даже у одного вендора, даже в одном типе устройств, например, коммутаторов.
• Бывают задержки с поддержкой новых фич в старых MIB. Например, CISCO-BGP-MIB, насколько мне известно, до сих пор не знает про IPv6.

Препарируем NETCONF

По-моему, протокол очень простой, а RFC очень хорошо написан.

Концептуально NETCONF выглядит так:

В качестве транспорта в данный момент определено 4 варианта:

• SSH
• SOAP
• BEEP
• TLS

Операции «оборачиваются» в RPC запросы, представленные в XML.

Определены следующие базовые операции:

get > , get-config > , edit-config > , copy-config > , delete-config > , lock > , unlock > , close-session > , kill-session > .

Применяется клиент-серверная модель работы протокола. Установленную сессию можно держать сколько угодно долго (пока будет связность и пока «жив» «сервер»).

При установке соединения клиент и сервер обмениваются поддерживаемыми параметрами (с помощью RPC уведомлений).

Что же мы можем? А мы можем, например:

• открывать несколько сессий
• работать с разными конфигурациями (например: running или startup)
• запрашивать конфигурацию и состояние одним запросом с поиском
• производить конфигурацию нескольких параметров одним запросом
• получать результаты операций в виде ответов (rpc-reply)
• делать commit и rollback (применение и откат конфигураций)

Думаю, проще всего понять работу с NETCONF на примере.

Пример работы NETCONF на Juniper

set system services netconf ssh

И попробуем подключиться:

После ввода пароля (или проверки ключа) получаем hello от «сервера»:

hello >
capabilities >
capability > urn:ietf:params:xml:ns:netconf:base:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file capability >
capability > xml.juniper.net/netconf/junos/1.0 capability >
capability > xml.juniper.net/dmi/system/1.0 capability >
capabilities >
session-id > 666 session-id >
hello >
]] > ]] >

* This source code was highlighted with Source Code Highlighter .

Сервер сообщил нам списком своих capability (возможностей).
Про зомби — это шутка, встречается в Junos такое иногда. Например, есть еще скрытая команда, показывающая хайку:

В ответ на hello клиент должен ответить своим hello со списком своих capability, например, такими же:

hello >
capabilities >
capability > urn:ietf:params:xml:ns:netconf:base:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 capability >
capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file capability >
capability > xml.juniper.net/netconf/junos/1.0 capability >
capability > xml.juniper.net/dmi/system/1.0 capability >
capabilities >
hello >
]] > ]] >

* This source code was highlighted with Source Code Highlighter .

Всё. Теперь можно работать с сервером. Например, спросить часть текущей конфигурации:

rpc message-id =»100″ xmlns =»urn:ietf:params:xml:ns:netconf:base:1.0″ >
get-config >
source >
running/>
source >
filter type =»subtree» >
configuration >
protocols/>
configuration >
filter >
get-config >
rpc >

* This source code was highlighted with Source Code Highlighter .

На что получим ответ:

rpc-reply message-id =»100″ xmlns:junos =»http://xml.juniper.net/junos/11.2R5/junos» >
configuration junos:commit-seconds =»1311003260″ junos:commit-localtime =»2012-06-06 11:21:40 UTC» junos:commit-user =»test» >
protocols >
SKIPPED
protocols >
configuration >
rpc-reply >

* This source code was highlighted with Source Code Highlighter .

message-id=«100», указанный в запросе, сохраняется и в ответе. Т.о. можно различать разные ответы, которые могут быть получены в разном порядке.

Кроме rpc-reply можно словить rpc-error, когда произошла ошибка при обработке запроса от клиента. Пример из RFC:

rpc-reply message-id =»110″ xmlns =»urn:ietf:params:xml:ns:netconf:base:1.0″ >
rpc-error >
error-type > rpc error-type >
error-tag > missing-attribute error-tag >
error-severity > error error-severity >
error-info >
bad-attribute > message-id bad-attribute >
bad-element > rpc bad-element >
error-info >
rpc-error >
rpc-reply >

* This source code was highlighted with Source Code Highlighter .

В случае же удачно выполненного запроса, не требующего вывода (например, команды), сервер отвечает OK, например:

rpc-reply message-id =»201″ xmlns =»urn:ietf:params:xml:ns:netconf:base:1.0″ >
ok/>
rpc-reply >

* This source code was highlighted with Source Code Highlighter .

Чтобы закончить работу, мы должны закрыть сессию:

rpc message-id =»100500″ xmlns =»urn:ietf:params:xml:ns:netconf:base:1.0″ >
close-session/>
rpc >

* This source code was highlighted with Source Code Highlighter .

Где работает NETCONF?

Ходят слухи, что на устройствах Juniper, Brocade, Cisco, Huawei и некоторых других.

Не так всё прекрасно. Отлично документированный и поддерживаемый NETCONF я встречал только на Juniper. К сожалению, на Huawei его не испытывал, т.к. не было необходимости, а в случае с Brocade не было подопытных. Но Cisco…

О работе NETCONF на линейке Catalyst как минимум до 15 версии IOS:

• Ответы на запросы очень сильно пожирают CPU. running-config c XML форматированием можно ждать минут 5 при загрузке CPU под 100%.
• get состояния реализован не по RFC (sic!): в ответ к, например, «show int status» Cisco всегда добавляет полный running-config.
• Нет XML схем и выдача иногда странным образом обрезается. Например, на запрос «sh run int vlan777» Cisco отвечает так:

xml version =»1.0″ encoding =»UTF-8″ ? > rpc-reply message-id =»101″ xmlns =» urn:ietf:params:netconf:base:1 . 0 &# 60 ;/ cmd > a > cli-config-data > cmd > !
cmd > nterface Vlan777
cmd > description TEST
cmd > ip address 192.168.0.1 255.255.255.0
cmd > cli-config-data > data > rpc-reply > ]] > ]] >

* This source code was highlighted with Source Code Highlighter .

Куда-то пропала первая буква в слове «Interface».

По-моему, реализация Cisco скорее для галочки, нежели для работы.

Источник

• netconf

This used to be the main page for netconf, but it now serves mostly posterity. The main content has moved here.

I’ve made some sort of mission statement, if you’re wondering what I am up to. There are also slides from a recent talk online.

Initial brainstorming

These are features/aspects I (madduck) want netconf to address. Feel free to add your thoughts, please give your name when you add content.

no more ifconfig, all iproute. Note that iproute is not on BSD or Hurd, so we need an abstraction layer. See here.

stateless (if at all possible)! => listen on netlink socket rtnetlink(7) so kernel informs us of its state (address add/remove, link up/down. ). Also see media status stuff and operstates.

modules/plugin based, so tools can install configuration methods

C/shell based.

resolv.conf management, a la resolvconf

integrated guessnet-like configuration detection

integrate well with wireless-tools/wpasupplicant (see plugins)

openvpn integration (see plugins)

determine SMTP smarthost, extract from DHCP if available

determine NTP servers, extract from DHCP if available

same for other protocols where it makes sense

proxy configuration: http/ftp/socks[45], extract from DHCP if available

control socket or other means for easy integration with higher level tools (think hal, desktop tools)

policy-controlled user access, so users can ifup/ifdown certain configurations

100% backwards compatible, read /etc/network/interfaces, even if we might switch to a different primary file or even ./interfaces.d/
wildcards for interfaces in /etc/network/interfaces

integrate functionality from zeroconf (crossover cable connection)

integrate well with bridge-utils, so that interfaces that are part of a bridge get added to the bridge again when they are taken down and brought up again — elho
integrate bonding

fallback to some kind of arp-based mechanism for automatic IP config when DHCP/BOOTP fails/isn’t available. http://advogato.org/person/etbe/diary/108.html. madduck: this is what zeroconf does, it makes no sense to do it another way since you netconf has no idea about which IP network it is attached to.

Missing functionality in ifupdown

(also see my FOSDEM 2007 talk)

• iface aliases
• ipv4/ipv6 not interlinked
• automatic configuration and laptops just weird
• sysctl integration

Wishlist

• get APT mirror from DHCP
• TODO

please provide a way (e.g. modular enough design) to handle non-Linux kernels (was in reaction to the above listen on netlink socket so kernel informs us of its state) — CyrilBrulebois

Be able to auto-detect restores from s2disk/s2ram and change network settings accordingly (handle being in a different environment than were suspended in) — ?BenjaminSeidenberg

Be able to handle much more dynamic and ridiculous routing settings that just a default gateway. — mentor

look at zugschluss’ ifupdown-scripts-zg

Источник

Network Configuration Protocol

Summary

[Note: This is not official documentation for the NETCONF protocol. Refer to the actual RFC specifications for authoritative documentation.]

The Network Configuration Protocol (NETCONF) provides operators and application developers with a standard framework and a set of standard Remote Procedure Call (RPC) methods to manipulate the configuration of a network device.

It is designed to be a replacement for Command Line Interface (CLI) based programmatic interfaces, such as Perl + Expect over Secure Shell (SSH). The CLI is also used by humans, which increases the complexity and reduces the predictability of the API for real application usage.

NETCONF is usually transported over the SSH protocol, using the ‘netconf’ sub-system (similar to the ‘sftp’ sub-system). and in many ways it mimics the native proprietary CLI over SSH interface available in the device. However, it uses structured schema-driven data, and provides detailed structured error return information, which the CLI cannot provide.

The device configuration data, and the protocol itself, are encoded with the Extensible Markup Language (XML). Standard XML tools such as XML Path Language (XPath) are used to provide retrieval of a particular subset configuration data. All NETCONF messages are encoded in XML within XML Namespaces. The protocol messages usually contain user data in a different namespace than the NETCONF protocol PDUs.

All NETCONF devices must allow the configuration data to be locked, edited, saved, and unlocked. In addition, all modifications to the configuration data must be saved across a reboot in non-volatile storage.

The protocol (and sometimes even the configuration data) is conceptually partitioned, based on a ‘capability’. These capabilities are given unique identifiers and advertised by the server when the client starts a NETCONF session.

A capability can be thought of as an ‘API contract’ between the server and the client. It represents a set of functionality that cannot be diminished by other capabilities. They can be nested (i.e., one capability required in order to support another) but they are always additive.

There are a core set of operations that must always be supported by the server. To use any additional optional operations, the client should make sure that the server supports the capability associated with that operation.

Base Protocol

The Network Configuration Protocol is defined in RFC 4741, and was published as a Proposed Standard in December 2006, by the NETCONF Working Group within the Internet Engineering Task Force (IETF).

NETCONF is a session-based network management protocol, which uses XML-encoded remote procedure calls (RPCs) and configuration data to manage network devices.

The mandatory transport protocol for NETCONF is The Secure Shell Transport Layer Protocol (SSH), and the details for implementing this transport mapping are defined in RFC 4742. The default TCP port assigned for this mapping is 830. A NETCONF server implementation must listen for connections to the ‘netconf’ subsystem on this port.

A server may optionally support additional transport mappings. RFC 4743 defines mappings to the Simple Object Access Protocol (SOAP). Two different transport protocols are supported for SOAP. The Blocks Extensible Exchange Protocol (BEEP) mapping, called ‘SOAP over BEEP’, is defined in RFC 4227. The default TCP port for this mapping is 833. The Hypertext Transfer Protocol (HTTP) mapping is defined by BEEP. NETCONF servers must provide secure HTTP (HTTPS), by running HTTP over the Transport Layer Security Protocol (TLS). . The default TCP port for this mapping is 832.

The NETCONF protocol can also be run directly over BEEP. This mapping is defined in RFC 4744. The default TCP port for this mapping is 831.

The IANA port assignments for NETCONF can be summarized in /etc/services format as follows:

The XSD in RFC 4741 defining the NETCONF protocol has been converted to a YANG module, called ietf-netconf.yang.

NETCONF Sessions

All NETCONF operations are carried out within a session, which is tied to the transport layer connection. There is no standard security model for NETCONF yet, but it is assumed that a session represents a particular user with some set of access rights (assigned by an administrator). The NETCONF server is required to authenticate the entity requesting a session before processing any requests from the client.

NETCONF messages are encoded in XML, using the UTF-8 character set. For SSH, a special message termination sequence of 6 characters is used to provide message framing:

Session Initiation For Clients

The client must initiate the connection and session establishment in NETCONF. The mandatory (and most implemented) transport is SSH, so a client must open an SSH2 connection to the netconf sub-system to reach the NETCONF server, as shown in the following command line example:

The server should sent its hello message right away, and the client should do the same. The following example shows the entire message that a client is required to send:

At this point the server should be waiting for requests to process. The server should sent an for each request. The client can add as many XML attributes to the element as desired, and the server will return all those attributes in the element. The message-id attribute is required by the protocol, although this is not really needed.

Configuration Databases

The NETCONF protocol contains several standard operations which operate on one or more conceptual configuration databases. For example, the parameter for the operation specifies which database to edit.

Configuration databases are represented (in XML) within NETCONF operations as either an empty element identifying a standard database, or a element identifying a non-standard (possibly offline) database.

There are 3 standard conceptual configuration databases

This database represents the entire active configuration currently within the device. It is the only mandatory standard database.

Unless the server supports the :candidate capability, the server must allow this database to be edited directly. Otherwise, the server is not required to support changing this database directly. If it does support it, then the :writable-running capability will be advertised by the server to indicate this support.

The database is also used to contain all the conceptual state information currently available on the device. This can be confusing, but operations such as , which operate on the database can retrieve status information and statistics, in addition to configuration parameters. The operation can be used instead of to retrieve only the configuration data.

This database is available if the :candidate capability is supported by the server. It is a global scratchpad database that is used to collect edits via 1 or more operations. A client can build up a set of changes which may or may not be validated by the server, until explicitly committed to the running configuration, all at once.

Unlike the database, any changes made to the database do not take effect right away within the network device.

When ready, the client can use the operation to activate the changes embodied in the database, and make them part of the configuration.

After a successful operation, the database and the database have the same configuration contents. This special condition is important because a operation on the database cannot be granted otherwise. It does not matter which session makes any changes to the database. If it is different than the database, then it cannot be locked.

Since this is a global database, the client should use the operation to remove any unwanted changes, if the operation is not used. This will clean out the database without activating any changes that it may contain, and prevent the next client using this global database from making unintended changes. Care must be taken (e.g., use locks) to make sure multiple sessions do not make any database edits at the same time.

Server platforms which support the :candidate capability usually do not also support the :writable-running capability, since mixing direct edits to would defeat the purpose of using this scratchpad database to collect and validate changes before applying them.

This database is available if the :startup capability is supported by the server. It represents the configuration to use upon the next reboot of the device.

If present, then the server will not automatically save changes to the database in non-volatile storage. Instead, a operation is needed to overwrite the contents of the database with the current configuration.

If not present, then the server will automatically update its non-volatile storage any time the running configuration is modified. In either case, the server is required to maintain non-volatile storage of the running configuration, and be able to restore a running configuration after a reboot.

Protocol Operations

Once a NETCONF session is established, the client knows which capabilities the server supports. The client then can send RPC method requests and receive RPC replies from the server. The server’s request queue is serialized, so requests will be processed in the order received.

Most operations are designed to select one or two specific configuration databases, but there are also two general operations for ending NETCONF sessions.

The following table summarizes the set of protocol operations, and shows which capabilities must be supported by the server (see next section) in order for a client to use the operation.

Operation	Usage	Description
close-session	:base	Terminate this session
commit	:base AND :candidate	Commit the contents of the configuration database to the configuration database
copy-config	:base	Copy a configuration database
create-subscription	:notification	Create a NETCONF notification subscription
delete-config	:base	Delete a configuration database
discard-changes	:base AND :candidate	Clear all changes from the configuration database and make it match the configuration database
edit-config	:base	Modify a configuration database
get	:base	Retrieve data from the running configuration database and/or device statistics
get-config	:base	Retrieve data from the running configuration database
kill-session	:base	Terminate another session
lock	:base	Lock a configuration database so only my session can write
unlock	:base	Unlock a configuration database so any session can write
validate	:base AND :validate	Validate the entire contents of a configuration database

Editing the Configuration

Before using the NETCONF edit operations, the client must determine which database to use as the target by examining the capabilities sent by the server during session establishment.

Once the target of the edit operation is determined, the client needs to determine the ‘activate’ operation that will be needed for the configuration changes to take effect.

After the ‘target’ and ‘activate function’ are determined, the client needs to determine how the activated configuration changes are saved in non-volatile storage.

Candidate Configuration Example

A basic NETCONF edit transaction if the candidate database is the target can be described with the following set of RPC transactions:

1. lock database
2. lock database
3. edit database
4. commit database
5. unlock database
6. unlock database

Here is an XML example of this PDU sequence. Note that step 3 can be done multiple times, in arbitrary fashion, since none of the changes take effect until step 4.

Running + Startup Configuration Example

A basic NETCONF edit transaction where the database is the target, and the changes need to be explicitly saved to the database, can be described with the following set of RPC transactions:

1. lock database
2. lock database
3. edit database
4. copy database to database
5. unlock database
6. unlock database

Here is an XML example of this PDU sequence. Note that step 3 must be done carefully, since the changes will take effect right away.

Protocol Capabilities

Many features and mechanisms within the NETCONF protocol do not apply to every use case or every device. Optional mechanisms are given URI handles, which are sent by the server during the NETCONF message exchange, during session initialization.

For example, if a server allows the running configuration to be edited directly, then it will include the following element in its message:

Each capability is also given a human-readable name, which is used throughout the documentation, instead of the URI representation. By convention, a colon character is pre-pended to the name to indicate it is a capability identifier.

The NETCONF protocol itself has a capability URI assignment, which is used in the message exchange to ensure both peers are using the same version of the protocol. The client and server each send the following capability URI during this exchange. For the client, this is the only capability sent. The server will also include elements for each optional capability supported, if any.

Although the base protocol is not optional, and not really a capability, it is given the following name in this document, for consistency and future-proofing.

Standard Capabilities

The following table summarizes the standard capabilities which a server may choose to support.

The server supports the database. It will allow this special database to be locked, edited, saved, and unlocked. The server will also support the and basic operations.

For servers that support the :candidate capability, this additional capability will also be advertised if the server supports the ‘confirmed commit’ feature. This special mode requires a server to send two RPC method requests instead of one, to save any changes to the database. If the second request does not arrive within a specified time interval, the server will automatically revert the running configuration to the previous version.

The server will accept requests (besides while notification delivery is active. The :notification capability must also be present if this capability is advertised.

The server supports the basic notification delivery mechanisms defined in RFC 5277, e.g., the operation will be accepted by the server. Unless the :interleave capability is also supported, only the operation must be supported by the server while notification delivery is active.

The server supports the

operations, defined in RFC 5717. This allows multiple independent clients to each write to a different part of the configuration at the same time.

The server supports the ‘rollback-on-error’ value for the parameter to the operation. If any error occurs during the requested edit operation, then the target database (usually the running configuration) will be left unaffected. This provides an ‘all-or-nothing’ edit mode for a single request.

The server supports the database. It will allow the running configuration to be copied to this special database. It can also be locked, and unlocked, but a server is not required to allow it to be edited.

The server supports the parameter value form to specify protocol operation source and target parameters. The capability URI for this feature will indicate which schemes (e.g., file, https, sftp) that the server supports within a particular URL value. The ‘file’ scheme allows for editable local configuration databases. The other schemes allow for remote storage of configuration databases.

The server supports the operation. When this operation is requested on a target database, the server will perform some amount of parameter validation and referential integrity checking. Since the standard does not define exactly what must be validated by this operation, a client cannot really rely on it for anything useful.

This operation is used to validate a complete database. There is no standard way to validate a single edit request against a target database, however a non-standard set-option for the operation called test-only has been defined for this purpose.

The server allows the client to change the running configuration directly. Either this capability or the :candidate capability will be supported by the server, but usually not both.

The server fully supports the XPath 1.0 specification for filtered retrieval of configuration and other database contents. The ‘type’ attribute within the parameter for and operations may be set to ‘xpath’. The ‘select’ attribute (which contains the XPath expression) will also be supported by the server.

A server may support partial XPath retrieval filtering, but it cannot advertise the :xpath capability unless the entire XPath 1.0 specification is supported.

Notifications

NETCONF has a notification delivery mechanism, defined in RFC 5277.

The operation is used to setup session-specific filtering and optional buffered notification delivery parameters. These parameters cannot be modified after notification delivery has started on a particular session. The only way to stop live notification delivery is to terminate the session, usually with the operation.

The NETCONF notification definitions are divided into 2 namespaces, one for the top-level element, and the other for some initial notification content, such as the event.

These definitions have been converted to YANG, named nc-notifications.yang and notifications.yang.

Completed RFC Specifications

RFC 4741

Defines the NETCONF protocol RPC layer and operations layer.

Status: Proposed Standard RFC, mandatory-to-implement

RFC 4742

Defines the NETCONF-over-SSH transport mapping.

Status: Proposed Standard RFC, mandatory-to-implement

RFC 4743

Defines the NETCONF-over-SOAP transport mapping.

Status: Proposed Standard RFC, optional-to-implement

RFC 4744

Defines the NETCONF-over-BEEP transport mapping.

Status: Proposed Standard RFC, optional-to-implement

RFC 5277

Defines the NETCONF notification delivery mechanisms.

Status: Proposed Standard RFC, optional-to-implement

RFC 5381

Documents some NETCONF-over-SOAP implementation experience.

Status: Informational RFC, nothing-to-implement

RFC 5539

Defines the NETCONF-over-TLS transport mapping.

Status: Proposed Standard RFC, optional-to-implement

RFC 5717

Defines a partial database locking mechanism (based on instance-identifier or XPath expressions) for the NETCONF protocol.

Status: Proposed Standard RFC, optional-to-implement

RFC 6022

Defines a server monitoring data model and schema retrieval mechanism for the NETCONF protocol.

Status: Proposed Standard RFC, optional-to-implement

RFC 6241

Defines a minor update to the NETCONF protocol.

Status: Proposed Standard RFC, mandatory-to-implement

RFC 6242

Defines a minor update to the NETCONF protocol over Secure Shell document.

Status: Proposed Standard RFC, mandatory-to-implement

RFC 6243

Defines a mechanism to control the filtering of leaf objects containing the ‘default’ value, during NETCONF retrieval operations.

Status: Proposed Standard RFC, optional-to-implement

RFC 6470

Defines some NETCONF notification events for the NETCONF notification stream.

Status: Proposed Standard RFC, optional-to-implement

RFC 6536

Defines an access control model for all forms of NETCONF content.

Status: Proposed Standard RFC, optional-to-implement

Standards Work in Progress

RFC4743 and RFC4744 to Historic status

This is a document to remove the SOAP and BEEP transport mappings from the NETCONF standards.

Intended Status: Informational RFC, nothing-to-implement

NETCONF Over TLS (RFC 5539-bis)

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539.

Intended Status: Proposed Standard RFC, optional-to-implement

Additional NETCONF Resources

Copyright © 2008 — 2020, Andy Bierman, All Rights Reserved.

Источник