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

Complying with XML and NETCONF Conventions

A client application must comply with XML and NETCONF conventions. Each request from the client application must be a well-formed XML document; that is, it must obey the structural rules defined in the NETCONF and SRC XML DTDs for the kind of information encoded in the request. The client application must emit tag elements in the required order and only in the legal contexts. Compliant applications are easier to maintain in the event of changes to the SRC software or NETCONF API.

Similarly, each response from the NETCONF server constitutes a well-formed XML document. (The NETCONF server obeys XML and NETCONF conventions.) The following sections describe NETCONF conventions:

Request and Response Tag Elements

A request tag element is one generated by a client application to request information about a C Series Controller’s current status or configuration, or to change the configuration. A request tag element corresponds to a CLI operational or configuration command. It can occur only within an <rpc> tag element. For information about the<rpc> tag element, see Sending a Request to the NETCONF Server.

A response tag element represents the NETCONF server’s reply to a request tag element and occurs only within an <rpc-reply> tag element. For information about the <rpc-reply> tag element, see Parsing the NETCONF Server Response.

The following example represents an exchange in which a client application emits the <get-interfaces> request tag element and the NETCONF server returns the <output> response tag element.

Note: This example, like all others in this guide, shows each tag element on a separate line, in the tag streams emitted by both the client application and NETCONF server. In practice, a client application does not need to include newline characters between tag elements, because the server automatically discards such white space. For further discussion, see Spaces, Newline Characters, and Other White Space.

For information about the ]]>]]> character sequence, see Generating Well-Formed XML Documents. For information about the attributes in the opening <rpc-reply> tag, see Parsing the NETCONF Server Response. For information about the xmlns attribute in the opening <output> tag, see Requesting Operational Information.

Client Application

NETCONF Server

<rpc>
  <get-interfaces>
    <interface-name>eth0</interface-name>
  </get-interfaces>
</rpc>
]]>]]>

 

 

<rpc-reply xmlns=”URN” xmlns:sdx=”URL” >
  <interface-information xmlns=” URL” >
    <!-- children of <interface-information> -->
  </interface-information>
</rpc-reply>
]]>]]>

Child Tag Elements of a Request Tag Element

Some request tag elements contain child tag elements. For configuration requests, each child tag element represents a configuration element (hierarchy level or configuration object). For operational requests, each child tag element represents one of the options you provide on the command line when issuing the equivalent CLI command.

Some requests have mandatory child tag elements. To make a request successfully, a client application must emit the mandatory tag elements within the request tag element’s opening and closing tags. If any of the children are themselves container tag elements, the opening tag for each must occur before any of the tag elements it contains, and the closing tag must occur before the opening tag for another tag element at its hierarchy level.

In most cases, the client application can emit children that occur at the same level within a container tag element in any order. The important exception is a configuration element that has an identifier tag element, which distinguishes the configuration element from other elements of its type. The identifier tag element must be the first child tag element in the container tag element. Most frequently, the identifier tag element specifies the name of the configuration element and is called <name>. For more information, see Mapping for Objects That Have an Identifier.

Child Tag Elements of a Response Tag Element

The child tag elements of a response tag element represent the individual data items returned by the NETCONF server for a particular request. The children can be either individual tag elements (empty tags or tag element triples) or container tag elements that enclose their own child tag elements. For some container tag elements, the NETCONF server returns the children in alphabetical order. For other elements, the children appear in the order in which they were created in the configuration.

The set of child tag elements that can occur in a response or within a container tag element is subject to change in later releases of the SRC XML API. Client applications must not rely on the presence or absence of a particular tag element in the NETCONF server’s output, or on the ordering of child tag elements within a response tag element. For the most robust operation, include logic in the client application that handles the absence of expected tag elements or the presence of unexpected ones as gracefully as possible.

Spaces, Newline Characters, and Other White Space

As dictated by the XML specification, the NETCONF server ignores white space (spaces, tabs, newline characters, and other characters that represent white space) that occurs between tag elements in the tag stream generated by a client application. Client applications can, but do not need to, include white space between tag elements. However, they must not insert white space within an opening or closing tag. If they include white space in the contents of a tag element that they are submitting as a change to the candidate configuration, the NETCONF server preserves the white space in the configuration database.

In its responses, the NETCONF server includes white space between tag elements to enhance the readability of responses that are saved to a file: it uses newline characters to put each tag element on its own line, and spaces to indent child tag elements to the right compared to their parents. A client application can ignore or discard the white space, particularly if it does not store responses for later review by human users. However, it must not depend on the presence or absence of white space in any particular location when parsing the tag stream.

For more information about white space in XML documents, see the XML specification from the World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, at http://www.w3.org/TR/REC-xml.

XML Comments

Client applications and the NETCONF server can insert XML comments at any point between tag elements in the tag stream they generate, but not within tag elements. Client applications must handle comments in output from the NETCONF server gracefully but must not depend on their content. Client applications also cannot use comments to convey information to the NETCONF server, because the server automatically discards any comments it receives.

XML comments are enclosed within the strings <!-- and -->, and cannot contain the string -- (two hyphens). For more details about comments, see the XML specification at http://www.w3.org/TR/REC-xml.

The following is an example of an XML comment:

<!- - This is a comment. Please ignore it. - ->

Predefined Entity References

By XML convention, there are two contexts in which certain characters cannot appear in their regular form:

  • In the string that appears between opening and closing tags (the contents of the tag element)
  • In the string value assigned to an attribute of an opening tag

When including a disallowed character in either context, client applications must substitute the equivalent predefined entity reference, which is a string of characters that represents the disallowed character. Because the NETCONF server uses the same predefined entity references in its response tag elements, the client application must be able to convert them to actual characters when processing response tag elements.

Table 3 summarizes the mapping between disallowed characters and predefined entity references for strings that appear between the opening and closing tags of a tag element.

Table 3: Predefined Entity Reference Substitutions for Tag Content Values

Disallowed Character

Predefined Entity Reference

& (ampersand)

&amp;

> (greater-than sign)

&gt;

< (less-than sign)

&lt;

Table 4 summarizes the mapping between disallowed characters and predefined entity references for attribute values.

Table 4: Predefined Entity Reference Substitutions for Attribute Values

Disallowed Character

Predefined Entity Reference

& (ampersand)

&amp;

' (apostrophe)

&apos;

> (greater-than sign)

&gt;

< (less-than sign)

&lt;

" (quotation mark)

&quot;

As an example, suppose that the following string is the value contained by the <condition> tag element:

if (a<b && b>c) return "Peer’s not responding"

The <condition> tag element looks like this (it appears on two lines for legibility only):


<condition>if (a&lt;b &amp;&amp; b&gt;c) return "Peer’s not \
    responding"</condition>

Similarly, if the value for the <example> tag element’s heading attribute is Peer’s "age" <> 40, the opening tag looks like this:

<example heading="Peer&apos;s &quot;age&quot; &lt;&gt; 40">

Modified: 2016-06-02