Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

Symbols  A  C  D  E  I  J  K  L  M  N  O  P  R  S  T  W  X

 

Symbols

<bad-element> tag (NETCONF)    
usage guidelines
<candidate/> tag (NETCONF)    
usage guidelines    
changing configuration
locking configuration
replacing entire configuration
requesting configuration
unlocking configuration
<capabilities> tag (NETCONF)    
usage guidelines
<capability> tag (NETCONF)    
usage guidelines
<close-session/> tag (NETCONF)    
usage guidelines
<commit> tag (NETCONF)    
usage guidelines    
regular commit
<config> tag (NETCONF)    
usage guidelines
<configuration> tag (SRC XML)
<copy-config> tag (NETCONF)    
usage guidelines
<data> tag (NETCONF)    
usage guidelines
<default-operation> tag (NETCONF)    
usage guidelines    
deleting configuration
general
replacing configuration
<discard-changes> tag (NETCONF)    
usage guidelines
<edit-config> tag (NETCONF)    
usage guidelines
<error-info> tag (NETCONF)    
usage guidelines
<error-message> tag (NETCONF)    
usage guidelines
<error-path> tag (NETCONF)    
usage guidelines
<error-severity> tag (NETCONF)    
usage guidelines
<filter> tag (NETCONF)    
usage guidelines
<get-config> tag (NETCONF)    
usage guidelines    
all objects of type
complete configuration
hierarchy level
identifiers only
multiple elements
overview
single object
specific children
<hello> tag (NETCONF)    
usage guidelines
<kill-session> tag (NETCONF)    
usage guidelines
<lock> tag (NETCONF)    
usage guidelines
<ok/> tag (NETCONF)    
usage guidelines
<output> tag (SRC XML)
<rpc-error> tag (NETCONF)    
usage guidelines
<rpc-reply> tag (NETCONF)    
usage guidelines
<rpc> tag (NETCONF)    
usage guidelines
<session-id> tag (NETCONF)    
usage guidelines    
initializing session
terminating session
<source> tag (NETCONF)    
usage guidelines    
replacing entire configuration
requesting configuration
<target> tag (NETCONF)    
usage guidelines    
changing configuration
locking configuration
replacing entire configuration
unlocking configuration
<unlock> tag (NETCONF)    
usage guidelines
<url> tag (NETCONF)    
usage guidelines    
changing configuration
replacing entire configuration
]]>]]> character sequence (NETCONF)    
usage guidelines
 

A

access    
protocols for NETCONF
attributes    
NETCONF tags    
For usage guidelines, see names of individual attributes
in <rpc> echoed in <rpc-reply>
SRC XML tags    
For usage guidelines, see names of individual attributes
authentication    
NETCONF
 

C

child tags (XML).     See tags (XML)    
commands    
mapping options to SRC XML tags    
fixed-form
variable-form
comments    
NETCONF and XML
compatibility    
between NETCONF server and application
configuration    
changing    
NETCONF (overview)
committing    
immediately (NETCONF)
creating    
element only if new (NETCONF)
deleting    
hierarchy level (NETCONF)
multiple values from leaf (NETCONF)
object (NETCONF)
overview (NETCONF)
single option (NETCONF)
discarding changes    
NETCONF
displaying    
candidate (NETCONF)
entire (NETCONF)
hierarchy level (NETCONF)
identifiers (NETCONF)
multiple elements at once (NETCONF)
objects of specific type (NETCONF)
overview (NETCONF)
single object (NETCONF)
specific children of object (NETCONF)
loading    
as a data stream (NETCONF)
as data in a file (NETCONF)
default mode for NETCONF
locking    
NETCONF
merging current and new    
NETCONF
modifying    
NETCONF
NETCONF operations on
replacing    
entire (NETCONF)
single element (NETCONF)
rolling back to previous    
NETCONF
statements.     See configuration statements    
unlocking    
NETCONF
verifying    
NETCONF
configuration statements    
deleting    
NETCONF
mapping to Junos XML tags    
multiple options on one line
mapping to SRC XML tags    
hierarchy level or container tag
identifiers
keywords
leaf statements
multiple values for an option
conventions    
NETCONF    
for client to comply with
notice icons
text
create (NETCONF 'operation' attribute)    1
usage guidelines
customer support    1
contacting JTAC
 

D

default mode for NETCONF configuration changes
delete (NETCONF 'operation' attribute)    1
usage guidelines
display xml command    
usage guidelines
Document Object Model.     See DOM    
document type definition.     See DTD    
documentation    
comments on
DOM
DTD    
defined
separate for each SRC software module
 

E

entity references, predefined (SRC XML)
error messages    
from NETCONF server
examples, Junos XML    
mapping of configuration statement to tag    
multiple options on multiple lines
multiple options on single line
examples, NETCONF    
creating configuration elements
deleting    
fixed-form option
hierarchy level
single configuration object
value from list of multiple values
merging in new configuration data
providing configuration data    
in a file
in a stream
replacing configuration elements
requesting    
all objects of a type
identifiers only
one configuration level
one configuration object
specific children of object
session
terminating session
examples, SRC XML    
mapping of configuration statement to tag    
hierarchy levels
identifier
leaf statement with keyword and value
leaf statement with keyword only
multiple predefined values for option
multiple user-defined values for option
Extensible Markup Language.     See XML    
 

I

identifiers    
SRC XML mapping
 

J

Junos XML tags    
mapping    
configuration, multiple multioption lines
 

K

keyword in configuration statement, SRC XML mapping
 

L

leaf statement    
SRC XML mapping
 

M

manuals    
comments on
 

N

namespaces.     See XML, namespaces    
NETCONF API    
comments, treatment of
conventions
overview
server.     See NETCONF server    
session.     See NETCONF session    
tags    
For usage guidelines, see names of individual tags
white space, treatment of
NETCONF server    
classes of responses emitted
closing connection to
connecting to
error message from
establishing session with
overview
parsing output from
sending request to
verifying compatibility with application
warning from
NETCONF session    
authentication and security
brief overview
ending
establishing
example
terminating another
NETCONF tags    
For usage guidelines, see names of individual tags
notational conventions
newline character in XML tag sequences
no-change mode (NETCONF)
notice icons
 

O

operation attribute (SRC XML with NETCONF)    1
usage guidelines    
creating element
deleting element
replacing element
operational mode, CLI    
SRC XML mapping    
for requests
for responses
options in configuration statements, SRC XML mapping
output from NETCONF server, parsing
 

P

predefined entity references (SRC XML)
prerequisites    
NETCONF API
 

R

replace (NETCONF 'operation' attribute)    1
usage guidelines
replace mode (NETCONF)
request tags (XML).     See tags (XML)    
response tags (XML).     See tags (XML)    
routers    
configuration.     See configuration    
 

S

SAX (Simple API for XML)
sdx:changed-localtime attribute (SRC XML)    
usage guidelines
sdx:changed-seconds attribute (SRC XML)    
usage guidelines
security    
NETCONF session
session, NETCONF.     See NETCONF session    
Simple API for XML.     See SAX    
software versions    
compatibility between NETCONF client and server
space character in XML tag sequences
SRC XML API    
overview
predefined entity references
tags.     See SRC XML tags    
SRC XML tags    
<configuration>    1
attributes in
<output>
displaying CLI output as
mapping    
command options, fixed-form
command options, variable
configuration, hierarchy level
configuration, identifier
configuration, multivalue leaf
configuration, single-value leaf
notational conventions
ssh service    
NETCONF access protocol
support, technical     See technical support    
 

T

tags (XML)    
NETCONF    
For usage guidelines, see names of individual tags
request    
children of
defined
NETCONF
SRC XML
response    
<rpc-reply> as container for
children of
defined
NETCONF
SRC XML
SRC XML     See SRC XML tags    
white space in and around
technical support    
contacting JTAC
text conventions defined
 

W

warning    
from NETCONF server
white space in XML tag sequences
 

X

XML    
namespaces    1
defined for operational response tags
overview
tags.     See tags (XML)    
xmlns attribute    
<configuration> tag    
usage guidelines
NETCONF    
usage guidelines
SRC XML operational responses    
usage guidelines

Changing Individual Configuration Elements

Although the NETCONF server by default merges new configuration data into the existing candidate configuration, a client application can also replace, create, or delete individual configuration elements (hierarchy levels or configuration objects). The same basic tag elements are emitted for all operations—the <edit-config>, <target>, and either <config> or <url> tag elements, plus the <candidate/> tag, in an <rpc> tag element:


<rpc>
    <edit-config>
        <target>
            <candidate/>
        </target>

    <!- - EITHER - ->
        <config>
            <configuration>
                <!- - tag elements representing the configuration elements to change - ->
            </configuration>
        </config>
    <!- - OR - ->
        <url>
            <!- - location specifier for file containing changes - ->
        </url>

    </edit-config>
</rpc>
]]>]]>

Within the <config> tag element or in the file named by the <url> tag element, the application defines a configuration element by including the tag elements representing all levels of the configuration hierarchy from the root (represented by the <configuration> tag element) down to the immediate parent level for the element. To represent the element, the application includes its container tag element. The child tag elements included within the container tag element depend on the operation, and are described in the following sections.

For more information about the tag elements that represent configuration statements, see Mapping Configuration Statements to SRC XML Tag Elements. For information about the tag elements for a specific configuration element, see the SRC XML API Configuration Reference.

The NETCONF server indicates that it changed the configuration in the requested way by enclosing the <ok/> tag in the <rpc-reply> tag element:


<rpc-reply xmlns="URN" xmlns:sdx="URL">
    <ok/>
</rpc-reply>
]]>]]>

For more information, see the following sections:

Merging Configuration Elements

To merge configuration elements (hierarchy levels or configuration objects) into the candidate configuration, a client application emits the basic tag elements described in Changing Individual Configuration Elements.

To represent each element to merge (either within the <config> tag element or in the file named by the <url> tag element), the application includes the tag elements representing its parent hierarchy levels and its container tag element, as described in Changing Individual Configuration Elements. Within the container tag, the application includes each of the element’s identifier tag elements (if it has them) and the tag element for each child to add or for which to set a different value. In the following, the identifier tag element is called <name>:


<configuration>
    <!- - opening tags for each parent of the element - ->
        <element>
         <name>identifier</name>
            <!- - - child tag elements to add or change - ->
        </element>
    <!- - closing tags for each parent of the element - ->
</configuration>

The NETCONF server merges the new configuration element according to the rules specified in Setting the Default Mode for Incorporating New Configuration Data. As described in that section, the application can explicitly specify merge mode by including the <default-operation>tag element with the value merge in the <edit-config> tag element.

The following example shows how to merge information for a new interface called eth1 into the [edit interfaces] hierarchy level in the candidate configuration:

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <configuration>
        <interfaces>
          <interface>
            <name>eth1</name>
              <unit>
                <name>0</name>
                <family>
                  <inet>
                    <address>10.0.0.1/8</address>
                  </inet>
                </family>
            </unit>
          </interface>
        </interfaces>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=” URL” >
  <ok/>
</rpc-reply>
]]>]]>

Replacing Configuration Elements

To replace configuration elements (hierarchy levels or configuration objects) in the candidate configuration, a client application emits the basic tag elements described in Changing Individual Configuration Elements.

To represent the new definition for each configuration element being replaced (either within the <config> tag element or in the file named by the <url> tag element), the application emits the tag elements representing its parent hierarchy levels and its container tag element, as described in Changing Individual Configuration Elements. Within the container tag, the application includes each of the element’s identifier tag elements (if it has them) and all child tag elements (with values if appropriate) that are being defined for the new version of the element. In the following, the identifier tag element is called <name>. The application includes the operation="replace" attribute in the opening container tag:


<configuration>
    <!- - opening tags for each parent of the element - ->
      <container-tag operation="replace">
        <name>identifier</name>
          <!- - other child tag elements - ->
      </container-tag>
    <!- - closing tags for each parent of the element - ->
</configuration>

The NETCONF server removes the existing element that has the specified identifiers and inserts the new element.

The application can also replace all objects in the configuration in one operation. For instructions, see Replacing the Entire Candidate Configuration.

The following example shows how to grant new permissions for the object named operator at the [edit system login class] hierarchy level.

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <configuration>
        <system>
          <login>
            <class operation=” replace” >
              <name>operator</name>
              <permissions>configure</permissions>
              <permissions>admin-control</permissions>
            </class>
          </login>
        </system>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <ok/>
</rpc-reply>
]]>]]>

Creating New Configuration Elements

To create configuration elements (hierarchy levels or configuration objects) in the candidate configuration only if the elements do not already exist, a client application emits the basic tag elements described in Changing Individual Configuration Elements.

To represent each configuration element being created (either within the <config>tag element or in the file named by the <url>tag element), the application emits the tag elements representing its parent hierarchy levels and its container tag element, as described in Changing Individual Configuration Elements. Within the container tag, the application includes each of the element’s identifier tag elements (if it has them) and all child tag elements (with values if appropriate) that are being defined for the element. In the following, the identifier tag element is called <name>. The application includes the operation="create" attribute in the opening container tag:


<configuration>
    <!- - opening tags for each parent of the element - ->
      <element operation="create">
            <name>identifier</name> <!- - if the element has an identifier - ->
            <!- - other child tag elements - ->
      </element>
    <!- - closing tags for each parent of the element - ->
</configuration>

The NETCONF server adds the new element to the candidate configuration only if there is no existing element of that name (for a hierarchy level) or with the same identifiers (for a configuration object).

The following example shows how to add a user to a C Series Controller if it is not already configured:

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <configuration>
        <system>
          <login>
            <user operation=” create” >
              <name>camryn</name>
              <class>super-user</class>
            </user>
          </login>
        </system>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <ok/>
</rpc-reply>
]]>]]>

Deleting Configuration Elements

To delete a configuration element (hierarchy level or configuration object) from the candidate configuration, a client application emits the basic tag elements described in Changing Individual Configuration Elements. It also emits the <default-operation> tag element with the value none to change the default mode to no-change.


<rpc>
    <edit-config>
        <target>
            <candidate/>
        </target>
        <default-operation>none</default-operation>

   <!- - EITHER - ->
        <config>
            <configuration>
                <!- - tag elements representing the configuration elements to delete - ->
            </configuration>
        </config>
   <!- - OR - ->
        <url>
            <!- - location specifier for file containing elements to delete - ->
        </url>

    </edit-config>
</rpc>
]]>]]>

In no-change mode, existing configuration elements remain unchanged unless the corresponding element in the new configuration has the operation="delete" attribute in its opening tag. This mode prevents the NETCONF server from creating parent hierarchy levels for an element that is being deleted. We recommend that the only operation performed in no-change mode be deletion. When merging, replacing, or creating configuration elements, client applications use merge mode.

To represent each configuration element being deleted (either within the <config> tag element or in the file named by the <url> tag element), the application emits the tag elements representing its parent hierarchy levels, as described in Changing Individual Configuration Elements. The tag element in which the operation="delete" attribute is included depends on the element type, as described in the following sections:

Deleting a Hierarchy Level or Container Object

To delete a hierarchy level and all of its children (or a container object that has children but no identifier), a client application includes the operation="delete" attribute in the empty tag that represents the level:


<configuration>
    <!- - opening tags for each parent level - ->
      <level-to-delete operation="delete"/>
    <!- - closing tags for each parent level - ->
</configuration>

We recommend that the application set the default mode to no-change by including the <default-operation> tag element with the value none, as described in Deleting Configuration Elements. For more information about hierarchy levels and container objects, see Mapping for Hierarchy Levels and Container Statements.

The following example shows how to remove the [edit system services netconf] hierarchy level of the candidate configuration:

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <config>
      <configuration>
        <system>
          <services>
            <netconf operation=” delete” />
          </services>
        </system>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <ok/>
</rpc-reply>
]]>]]>

Deleting a Configuration Object That Has an Identifier

To delete a configuration object that has an identifier, a client application includes the operation="delete" attribute in the container tag element for the object. Inside the container tag element, it includes the identifier tag element only, not any tag elements that represent other characteristics. In the following, the identifier tag element is called <name>:


<configuration>
    <!- - opening tags for each parent of the object - ->
      <object operation="delete">
        <name>identifier</name>
      </object>
    <!- - closing tags for each parent of the object - ->
</configuration>

Note: The delete attribute appears in the opening container tag, not in the identifier tag element. The presence of the identifier tag element results in the removal of the specified object, not in the removal of the entire hierarchy level represented by the container tag element.

We recommend that the application set the default mode to no-change by including the <default-operation> tag element with the value none, as described in Deleting Configuration Elements. For more information about identifiers, see Mapping for Objects That Have an Identifier.

The following example shows how to remove the user object barbara from the [edit system login user] hierarchy level in the candidate configuration:

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <config>
      <configuration>
        <system>
          <login>
            <user operation=” delete” >
              <name>barbara</name>
            </user>
          </login>
        </system>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <ok/>
</rpc-reply>
]]>]]>

Deleting a Single-Value or Fixed-Form Option from a Configuration Object

To delete from a configuration object either a fixed-form option or an option that takes just one value, a client application includes the operation="delete" attribute in the tag element for the option. In the following, the identifier tag element for the object is called <name>. (For information about deleting an option that can take multiple values, see Deleting Values from a Multivalue Option of a Configuration Object.)


<configuration>
    <!- - opening tags for each parent of the object - ->
        <object>
          <name>identifier</name>
            <option1 operation="delete">
            <option2 operation="delete">
            <!- - tag elements for other options to delete - ->
        </object>
    <!- - closing tags for each parent of the object - ->
</configuration>

We recommend that the application set the default mode to no-change by including the <default-operation> tag element with the value none, as described in Deleting Configuration Elements. For more information about options, see Mapping for Single-Value and Fixed-Form Leaf Statements.

The following example shows how to remove the fixed-form stand-alone option at the [edit system ldap server] hierarchy level:

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <config>
      <configuration>
        <system>
          <ldap>
            <server>
              <stand-alone operation=” delete” />
            </server>
          </ldap>
        </system>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <ok/>
</rpc-reply>
]]>]]>

Deleting Values from a Multivalue Option of a Configuration Object

As described in Mapping for Leaf Statements with Multiple Values, some configuration objects are leaf statements that have multiple values. In the formatted ASCII CLI representation, the values are enclosed in square brackets following the name of the object:

object [value1 value2 value3 ...];

The XML representation does not use a parent tag for the object, but instead uses a separate instance of the object tag element for each value. In the following, the identifier tag element is called <name>:


<parent-object>
    <name>identifier</name>
    <object>value1</object>
    <object>value2</object>
    <object>value3</object>
</parent-object>

To remove one or more values for such an object, a client application includes the operation="delete" attribute in the opening tag for each value. It does not include tag elements that represent values to be retained. The identifier tag element in the following is called <name>:


<configuration>
    <!- - opening tags for each parent of the parent object - ->
      <parent-object>
        <name>identifier</name>
        <object operation="delete">value1</object>
        <object operation="delete">value2</object>
      </parent-object>
    <!- - closing tags for each parent of the parent object - ->
</configuration>

We recommend that the application set the default mode to no-change by including the <default-operation> tag element with the value none, as described in Deleting Configuration Elements. For more information about leaf statements with multiple values, see Mapping for Leaf Statements with Multiple Values.

The following example shows how to remove two of the permissions granted to the user-accounts login class:

Client Application

NETCONF Server

<rpc>
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <config>
      <configuration>
        <system>
          <login>
            <class>
              <name>user-accounts</name>
              <permissions operation=” delete” >configure</permissions>
              <permissions operation=” delete” >control</permissions>
            </class>
          </login>
        </system>
      </configuration>
    </config>
  </edit-config>
</rpc>
]]>]]>

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <ok/>
</rpc-reply>
]]>]]>

Modified: 2016-06-02