diff --git a/.authors.txt b/.authors.txt index c3c6010..8f4d87f 100644 --- a/.authors.txt +++ b/.authors.txt @@ -1,4 +1,7 @@ - - Watsen Networks + + ACME, Inc. +
+ foo@acme.com +
diff --git a/.github/workflows/gen_author_list.sh b/.github/workflows/gen_author_list.sh index 5ce13d3..8aad0f2 100755 --- a/.github/workflows/gen_author_list.sh +++ b/.github/workflows/gen_author_list.sh @@ -46,20 +46,18 @@ sorted_xml_authors() { # output authors as an XML element for a in $AUTHORS; do - if [ $a == "kent" ]; then - #echo "skipping author 'kent'" - #exit 1 # let's see if we can't first this - continue - fi - FULL_NAME=`grep $a $0 | awk -F'"' '{print $2}'` ORGANIZATION=`grep $a $0 | awk -F'"' '{print $4}'` FIRST_NAME=`echo $FULL_NAME | awk '{print $1}'` LAST_NAME=`echo $FULL_NAME | awk '{print $2}'` FIRST_INITIAL=${FIRST_NAME:0:1} + EMAIL=`grep $a $0 | awk -F'"' '{print $6}'` echo "" echo " $ORGANIZATION" + echo "
" + echo " $EMAIL" + echo "
" echo "" done } @@ -79,4 +77,4 @@ main "$@" #### AUTHOR INFO #### -#kwatsen: "Kent Watsen" "Watsen Networks" +#kwatsen: "Kent Watsen" "Watsen Networks" "kent+ietf@watsen.net" diff --git a/.github/workflows/gen_index_html.sh b/.github/workflows/gen_index_html.sh index e8cf6ae..f396cb0 100644 --- a/.github/workflows/gen_index_html.sh +++ b/.github/workflows/gen_index_html.sh @@ -9,7 +9,7 @@ for d in */; do dd=`echo $d | sed 's#/$##'` echo "$dd $DATE" >> sort.txt done -SORTED=`sort -r -k 1 sort.txt | awk '{print $1}'` +SORTED=`sort -r -k 2 sort.txt | awk '{print $1}'` # create the index.html file echo "" > index.html @@ -20,7 +20,7 @@ echo " tr.bg:nth-child(odd) {background-color: #f2f2f2}" >> index.html echo " tr.bg:nth-child(even) {background-color: white}" >> index.html echo " th.bg {background-color: #A0A0A0; color: white;}" >> index.html echo " th.bg,td.bg {padding: 15px; text-align: left; vertical-align: top;}" >> index.html -echo " td.fg {text-align: right; vertical-align: bottom;}" >> index.html +echo " td.fg {text-align: right; vertical-align: bottom; white-space: nowrap;}" >> index.html echo " " >> index.html echo " " >> index.html echo "" >> index.html @@ -32,25 +32,37 @@ echo "" >> index.html echo " " >> index.html echo " " >> index.html echo " " >> index.html -echo " " >> index.html +echo " " >> index.html echo " " >> index.html echo " " >> index.html echo " " >> index.html -for d in $SORTED; do +for branch in $SORTED; do echo " " >> index.html - NUMBER=`grep NUMBER $d/metadata.txt | awk '{print $2}'` - TITLE=`grep TITLE $d/metadata.txt | awk '{for (i=2; i$DATE" >> index.html - echo " " >> index.html - echo " " >> index.html + NUMBER=`grep NUMBER $branch/metadata.txt | awk '{print $2}'` + TITLE=`grep TITLE $branch/metadata.txt | awk '{for (i=2; i$DATE" >> index.html - echo " " >> index.html + if [ $branch = "main" ]; then + echo " " >> index.html + else + echo " " >> index.html + fi + + if [ $branch = "main" ]; then + echo " " >> index.html + else + echo " " >> index.html + fi + + echo " " >> index.html - if [ $d = "main" ]; then - echo " " >> index.html + if [ $branch = "main" ]; then + echo " " >> index.html else - echo " " >> index.html + echo " " >> index.html fi echo " " >> index.html done diff --git a/.github/workflows/pull_request_updated.yml b/.github/workflows/pull_request_updated.yml index c4a1bcd..dcaf6c0 100644 --- a/.github/workflows/pull_request_updated.yml +++ b/.github/workflows/pull_request_updated.yml @@ -171,9 +171,11 @@ jobs: # stash some metadata - name: Stash some metadata run: | + echo "${{github.event.pull_request}}" echo "NUMBER: ${{github.event.pull_request.number}}" > mysite/${{github.head_ref}}/metadata.txt echo "TITLE: ${{github.event.pull_request.title}}" >> mysite/${{github.head_ref}}/metadata.txt echo "DATE: $(date +%Y-%m-%dT%H:%M:%SZ)" >> mysite/${{github.head_ref}}/metadata.txt + echo "BASE: ${{github.base_ref}}" >> mysite/${{github.head_ref}}/metadata.txt # delete the artifacts - uses: geekyeggo/delete-artifact@v5 diff --git a/.gitignore b/.gitignore index b27c168..fea7d79 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,3 @@ draft-yn-netmod-rfc7950bis-* +draft-yn-netmod-yang-xml-* +draft-yn-netmod-yang-proto-* diff --git a/Makefile b/Makefile index 1e5abe2..8faaaf1 100644 --- a/Makefile +++ b/Makefile @@ -62,6 +62,7 @@ clean: done clean_draft: + -rm -f $(draft)-[0-9][0-9].v2v3.xml -rm -f $(draft)-[0-9][0-9].xml -rm -f $(draft)-[0-9][0-9].txt -rm -f $(draft)-[0-9][0-9].html diff --git a/designs/creating-xml-yang-doc.md b/designs/creating-xml-yang-doc.md new file mode 100644 index 0000000..67724da --- /dev/null +++ b/designs/creating-xml-yang-doc.md @@ -0,0 +1,7 @@ +# Creating the "xml-yang" Document + + - copy overall structure from RFC 7951 + - name "yang-xml" since 7951's doc was originally called "yang-json" + - for each section: + - copy/edit text from RFC 7951 + - move/edit text from RFC 7950 diff --git a/draft-yn-netmod-rfc7950bis.xml b/draft-yn-netmod-rfc7950bis.xml index ade7875..7874485 100644 --- a/draft-yn-netmod-rfc7950bis.xml +++ b/draft-yn-netmod-rfc7950bis.xml @@ -34,17 +34,18 @@ INSERT_TEXT_FROM_FILE(.authors.txt) incompatibilities from YANG version 1.0 - This document is developed on GitHub (). + This document is developed on GitHub (). If you wish to contribute, please consider opening a pull request (PR). Please see the - README - file for details. + README file for details. +
@@ -86,10 +87,10 @@ INSERT_TEXT_FROM_FILE(.experts.txt) This document is effectively the same as RFC 7950 with two notable distinctions:
    -
  1. The "XML Encodings" sections have been removed. More specifically, - the information has been moved to .
    2. -
  2. The "NETCONF Operations" sections have been removed. More specifically, - the information has been moved to .
    3. +
  3. The "XML Encodings" sections have been removed. The information + has been moved to .
    4. +
  4. (Not Done Yet!) The NETCONF-specific sections have been removed. + The information has been moved to .
@@ -418,11 +419,19 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - XML Encoding Example: + XML Encoding Example (see Section 5.1 in for details):
my.example.com +]]> + +
+ JSON Encoding Example (see for details): +
+ +
@@ -443,13 +452,25 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - XML Encoding Example: + XML Encoding Example (see Section 5.3 in for details):
high.example.com low.example.com everywhere.example.com +]]> + +
+ JSON Encoding Example (see for details): +
+ +
@@ -477,7 +498,8 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - XML Encoding Example: + XML Encoding Example (see Section 5.2 in + for details):
Good morning +]]> + +
+ JSON Encoding Example (see for details): +
+ +
@@ -517,7 +551,7 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - XML Encoding Example: + XML Encoding Example (see Section 5.4 in for details):
Rapun Zell tower +]]> + +
+ JSON Encoding Example (see for details): +
+ +
@@ -685,8 +743,7 @@ INSERT_TEXT_FROM_FILE(.experts.txt) union Choice of member types - The "type" statement is covered in - . + The "type" statement is covered in .
YANG can define derived types from base types using the "typedef" @@ -709,7 +766,7 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - XML Encoding Example: + XML Encoding Example (see Section 5.1 in for details):
- The "typedef" statement is covered in - . + JSON Encoding Example (see for details): +
+ + + +
+ The "typedef" statement is covered in .
Groups of nodes can be assembled into reusable collections using the @@ -747,7 +811,8 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - XML Encoding Example: + XML Encoding Example (see Section 5.1 in + and Section 5.2 in ):
830 +]]> + +
+ JSON Encoding Example (see for details): +
+ +
@@ -790,8 +868,7 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - The "grouping" statement is covered in - . + The "grouping" statement is covered in .
YANG allows the data model to segregate incompatible nodes into distinct @@ -846,8 +923,18 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]> - The "choice" statement is covered in - . + JSON Encoding Example: +
+ + + +
+ The "choice" statement is covered in .
YANG allows a module to insert additional nodes into data models, including @@ -879,8 +966,7 @@ INSERT_TEXT_FROM_FILE(.experts.txt) "class" is not "wheel". If a module augments another module, the XML elements that are added to the encoding are in the namespace of the augmenting module. For example, if the - above augmentation were in a module with prefix "other", the XML would look - like: + above augmentation were in a module called "my-example" with prefix "other": XML Encoding Example:
@@ -894,8 +980,20 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]>
- The "augment" statement is covered in - . + JSON Encoding Example: +
+ + + +
+ The "augment" statement is covered in .
YANG allows the definition of operations. The operations' names, input @@ -1146,12 +1244,10 @@ INSERT_TEXT_FROM_FILE(.experts.txt) more than one top-level node. Each top-level data node in a module defines a separate hierarchy. Models that have multiple top&nbhy;level nodes are sometimes convenient and are supported by YANG. -
- NETCONF is capable of carrying any XML content as the payload in the - <config> and <data> elements. The top-level nodes of YANG - modules are encoded as child elements, in any order, within these - elements. This encapsulation guarantees that the corresponding NETCONF - messages are always well-formed XML documents. +
+ The top-level nodes of YANG modules are encoded as top-level + namespace-qualified elements, in any order. This encapsulation + guarantees that the corresponding encodings are always well-formed. For example, an instance of:
@@ -1167,27 +1263,25 @@ INSERT_TEXT_FROM_FILE(.experts.txt) ]]>
- could be encoded in NETCONF as: + could be encoded in XML as:
- - - - - - - - - - - - - - + + ... + + + ... + +]]> + +
+ or be encoded in JSON as: +
+ +
@@ -3124,22 +3218,6 @@ INSERT_TEXT_FROM_FILE(.experts.txt) "choice", "anydata", and "anyxml" statements can be used to define child nodes to the container.
-
- A container node is encoded as an XML element. The element's local name is - the container's identifier, and its namespace is the module's XML namespace - (see - ). - The container's child nodes are encoded as subelements to the container - element. If the container defines RPC or action input or output parameters, - these subelements are encoded in the same order as they are defined within the - "container" statement. Otherwise, the subelements are encoded in any - order. - Any whitespace between the subelements to the container is insignificant, - i.e., an implementation MAY insert whitespace characters between - subelements. - If a non-presence container does not have any child nodes, the container - may or may not be present in the XML encoding. -
Containers can be created, deleted, replaced, and modified through <edit‑config> by using the "operation" attribute (see Section 7.2 @@ -3374,15 +3452,6 @@ INSERT_TEXT_FROM_FILE(.experts.txt) This constraint is enforced according to the rules in .
-
- A leaf node is encoded as an XML element. The element's local name is the - leaf's identifier, and its namespace is the module's XML namespace (see - ). - The value of the leaf node is encoded to XML according to the type and is - sent as character data in the element. - See - for an example. -
When a NETCONF server processes an <edit‑config> request, the elements of procedure for the leaf node are as follows: @@ -3660,21 +3729,6 @@ INSERT_TEXT_FROM_FILE(.experts.txt) for details.
-
- A leaf-list node is encoded as a series of XML elements. Each element's - local name is the leaf-list's identifier, and its namespace is the module's - XML namespace (see - ). - The value of each leaf-list entry is encoded to XML according to the type - and is sent as character data in the element. - The XML elements representing leaf-list entries MUST appear in the order - specified by the user if the leaf-list is "ordered-by user"; otherwise, the - order is implementation dependent. The XML elements representing leaf-list - entries MAY be interleaved with elements for siblings of the leaf-list, unless - the leaf-list defines RPC or action input or output parameters. - See - for an example. -
Leaf-list entries can be created and deleted, but not modified, through <edit‑config>, by using the "operation" attribute in the leaf-list @@ -4041,28 +4095,6 @@ INSERT_TEXT_FROM_FILE(.experts.txt) "choice", "anydata", and "anyxml" statements can be used to define child nodes to the list.
-
- A list is encoded as a series of XML elements, one for each entry in the - list. Each element's local name is the list's identifier, and its namespace is - the module's XML namespace (see - ). There is no XML element surrounding the list as - a whole. - The list's key nodes are encoded as subelements to the list's identifier - element, in the same order as they are defined within the "key" statement. - The rest of the list's child nodes are encoded as subelements to the list - element, after the keys. If the list defines RPC or action input or output - parameters, the subelements are encoded in the same order as they are defined - within the "list" statement. Otherwise, the subelements are encoded in any - order. - Any whitespace between the subelements to the list entry is insignificant, - i.e., an implementation MAY insert whitespace characters between - subelements. - The XML elements representing list entries MUST appear in the order - specified by the user if the list is "ordered-by user"; otherwise, the order - is implementation dependent. The XML elements representing list entries MAY be - interleaved with elements for siblings of the list, unless the list defines - RPC or action input or output parameters. -
List entries can be created, deleted, replaced, and modified through <edit‑config> by using the "operation" attribute in the list's XML @@ -4585,8 +4617,8 @@ INSERT_TEXT_FROM_FILE(.experts.txt) The constraint is further enforced according to the rules in .
-
- The choice and case nodes are not visible in XML. +
+ The choice and case nodes are not visible in encodings. The child nodes of the selected "case" statement MUST be encoded in the same order as they are defined in the "case" statement if they are part of an RPC or action input or output parameter definition. Otherwise, the subelements @@ -4715,13 +4747,6 @@ INSERT_TEXT_FROM_FILE(.experts.txt) 0..1
-
- An anydata node is encoded as an XML element. The element's local name is - the anydata's identifier, and its namespace is the module's XML namespace (see - - ). The value of the anydata node is a set of nodes, - which are encoded as XML subelements to the anydata element. -
An anydata node is treated as an opaque chunk of data. This data can be modified in its entirety only. @@ -4849,15 +4874,6 @@ INSERT_TEXT_FROM_FILE(.experts.txt) 0..1
-
- An anyxml node is encoded as an XML element. The element's local name is - the anyxml's identifier, and its namespace is the module's XML namespace (see - ). The value of the anyxml node is encoded as XML - content of this element. - Note that any XML prefixes used in the encoding are local to each instance - encoding. This means that the same XML may be encoded differently by different - implementations. -
An anyxml node is treated as an opaque chunk of data. This data can be modified in its entirety only. @@ -5126,9 +5142,9 @@ INSERT_TEXT_FROM_FILE(.experts.txt)
-
+
Each node in the grouping is encoded as if it was defined inline, even if - it is imported from another module with another XML namespace. + it is imported from another module with another namespace.
To use the "endpoint" grouping defined in @@ -6031,9 +6047,9 @@ INSERT_TEXT_FROM_FILE(.experts.txt) 0..1
-
- All data nodes defined in the "augment" statement are defined as XML - elements in the XML namespace of the module where the "augment" is +
+ All data nodes defined in the "augment" statement are defined as + elements in the namespace of the module where the "augment" is specified. When a node is augmented, the augmenting child nodes are encoded as subelements to the augmented node, in any order. @@ -10673,7 +10689,8 @@ WSP = SP / HTAB value="REC-xpath20-20101214"/> - + + diff --git a/draft-yn-netmod-yang-proto.xml b/draft-yn-netmod-yang-proto.xml index 71f324d..79873f5 100644 --- a/draft-yn-netmod-yang-proto.xml +++ b/draft-yn-netmod-yang-proto.xml @@ -33,17 +33,18 @@ INSERT_TEXT_FROM_FILE(.authors.txt) language in both backwards-compatible and backwards-incompatible ways. - This document is developed on GitHub (). + This document is developed on GitHub (). If you wish to contribute, please consider opening a pull request (PR). Please see the - README - file for details. + README file for details. +
diff --git a/draft-yn-netmod-yang-xml.xml b/draft-yn-netmod-yang-xml.xml index da5c000..5e4ab8c 100644 --- a/draft-yn-netmod-yang-xml.xml +++ b/draft-yn-netmod-yang-xml.xml @@ -30,17 +30,18 @@ INSERT_TEXT_FROM_FILE(.authors.txt) operations or actions, and notifications defined using XML. - This document is developed on GitHub (). + This document is developed on GitHub (). If you wish to contribute, please consider opening a pull request (PR). Please see the - README - file for details. + README file for details. +
@@ -119,8 +120,9 @@ INSERT_TEXT_FROM_FILE(.experts.txt) or set using the "xmlns" attribute in the element. The "xmlns" attribute may either set the XML default namespace or - define and use a prefix for the namespace. For instance, the following - two XML documents are the same. + define and use a prefix for the namespace. Note that the same XML + may be encoded differently by different implementations. For instance, + the following two XML documents are the same. Document 1:
@@ -213,7 +215,6 @@ module example-barmod { Valid XML-encoded configuration data containing both leafs may then look like this: -
-
- TBD -
+ +
+ A leaf node is encoded as an XML element. The element's local name + is the leaf's identifier, and its namespace is the module's XML + namespace (see ). + The value of the leaf node is encoded to XML according to the + type (see for type encoding rules) and is + sent as character data in the element. + Example: For the leaf node definition +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +123 +]]> + +
+
+
- TBD -
+ A container node is encoded as an XML element. The element's local name is + the container's identifier, and its namespace is the module's XML namespace + (see ). + The container's child nodes are encoded as subelements to the container + element. If the container defines RPC or action input or output parameters, + these subelements are encoded in the same order as they are defined within the + "container" statement. Otherwise, the subelements are encoded in any + order. + Any whitespace between the subelements to the container is insignificant, + i.e., an implementation MAY insert whitespace characters between + subelements. + If a non-presence container does not have any child nodes, the container + may or may not be present in the XML encoding. + Example: For the container definition +
+ + + +
+ the following is valid XML-encoded instance data: +
+ + + 123 + + + +]]> + +
+ Note that, the example above sets presence container "baz", + which is encoded as an empty XML element, since it has no descendants. +
+
- TBD -
+ A leaf-list node is encoded as a series of XML elements. Each element's + local name is the leaf-list's identifier, and its namespace is the module's + XML namespace (see ). There is no XML element + surrounding the leaf-list as a whole. + The value of each leaf-list entry is encoded to XML according to the type + and is sent as character data in the element (see for + type encoding rules). + The XML elements representing leaf-list entries MUST appear in the order + specified by the user if the leaf-list is "ordered-by user"; otherwise, the + order is implementation dependent. The XML elements representing leaf-list + entries MAY be interleaved with elements for siblings of the leaf-list, unless + the leaf-list defines RPC or action input or output parameters. + Example: For the leaf-list definition +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +123 +0 +]]> + +
+
+
- TBD -
+ A list is encoded as a series of XML elements, one for each entry in the + list. Each element's local name is the list's identifier, and its namespace is + the module's XML namespace (see ). There is no XML + element surrounding the list as a whole. + The list's key nodes are encoded as subelements to the list's identifier + element, in the same order as they are defined within the "key" statement. + The rest of the list's child nodes are encoded as subelements to the list + element, after the keys. If the list defines RPC or action input or output + parameters, the subelements are encoded in the same order as they are defined + within the "list" statement. Otherwise, the subelements are encoded in any + order. + Any whitespace between the subelements to the list entry is insignificant, + i.e., an implementation MAY insert whitespace characters between + subelements. + The XML elements representing list entries MUST appear in the order + specified by the user if the list is "ordered-by user"; otherwise, the order + is implementation dependent. The XML elements representing list entries MAY be + interleaved with elements for siblings of the list, unless the list defines + RPC or action input or output parameters. + Example: For the list definition +
+ + + +
+ the following is a valid XML-encoded instance: +
+ + + 123 + zig + + + 456 + zag + +]]> + +
+
+
- TBD -
+ An anydata node is encoded as an XML element. The element's local name is + the anydata's identifier, and its namespace is the module's XML namespace (see + ). The value of the anydata node is a set of nodes, + which are encoded as XML subelements to the anydata element. + The anydata data node serves as a container for an arbitrary set of + nodes that otherwise appear as normal YANG-modeled data. A data + model for anydata content may or may not be known at runtime. In the + latter case, converting XML-encoded instances to other encodings, such + as JSON may be impossible. + Example: For the anydata definition +
+ + + +
+ the following is a valid XML-encoded instance: +
+ + + + 2014-07-29T13:43:01Z + + fault + + Ethernet0 + + major + + + +]]> + +
+
+
- TBD -
+ An anyxml node is encoded the same as an anydata node. Please see + for how the anydata node is encoded. +
+
- TBD -
-
-
+ Apart from instances of YANG data nodes, XML elements MAY contain + XML attributes for special purposes, such as encoding metadata + . The exact syntax and semantics of such + members are outside the scope of this document. +
+ +
+ +
+ + The type of the XML value in an instance of the leaf or leaf-list + data node depends on the type of that data node, as specified in the + following subsections. +
- TBD -
+ All numeric types (int8, int16, int32, uint8, uint16, uint32, + int64, uint64, and decimal64) are represented as a text value + conforming the to lexical representation for the type described + in and + . + Example: For the "int16" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +4711 +-123 +0xf00f +-0xf +052 +-052 +]]> + +
+
+
- TBD -
+ A "string" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "string" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +This string is all on one line. +This string is: + - on more than one line. + - contains tab characters. + +]]> + +
+
+
- TBD -
+ A "boolean" value is represented as the corresponding + literal name "true" or "false". + Example: For the "boolean" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +true +false +]]> + +
+ +
- TBD -
+ An "enumeration" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "enumeration" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +one +two +three +]]> + +
+ +
- TBD -
+ A "bits" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "bits" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +zero +zero one +zero one two +]]> + +
+ +
- TBD -
+ A "binary" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "binary" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +SGVsbG8gQm9iCg== +SGVsbG8gQWxpY2UK +]]> + +
+ +
- TBD -
+ A "leafref" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "leafref" type +
+ + + +
+ the following is valid XML-encoded instance data: +
+ +up + +eth0 +eth1 +eth2 + +red +green +blue +]]> + +
+ +
- TBD -
+ A "identityref" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "identityref" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +aes +blowfish +]]> + +
+ Note that, the example above uses the default namespace, + and hence the identities are not prefixed. + +
- TBD -
+ An "empty" value is represented as an empty XML element. + Example: For the "empty" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ + +]]> + +
+ +
- TBD -
+ A "union" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "union" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +16 +32 +64 +unbounded +]]> + +
+ +
- TBD -
- + A "instance-identifier" value is represented as character data conforming + the to lexical representation for the type described in + . + Example: For the "instance-identifier" type +
+ + + +
+ the following is a valid XML-encoded instance: +
+ +/ex:system/ex:services/ex:ssh +/ex:system/ex:services/ex:ssh/ex:port +/ex:system/ex:user[ex:name='fred'] +/ex:system/ex:user[ex:name='fred']/ex:type +/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80'] +/ex:system/ex:service[ex:name='foo'][ex:enabled=''] +/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] +/ex:stats/ex:port[3] +]]> + +
+ + + +
- This document registers one capability identifier URN from the "Network - Configuration Protocol (NETCONF) Capability URNs" registry: + None.
+
- This document defines a language with which to write and read descriptions of - management information. The language itself has no security impact on the - Internet. + This document defines an encoding for data modeled in the + YANG data modeling language. As such, it doesn't contribute any new + security issues beyond those discussed in . + + This document defines no mechanisms for signing and encrypting data + modeled with YANG. Under normal circumstances, data security and + integrity are guaranteed by the management protocol in use, such as + NETCONF or RESTCONF . + If this is not the case, external mechanisms, such as Public-Key + Cryptography Standards (PKCS) #7 , + need to be considered. + + XML processing is rather different from JSON, and XML parsers may + thus suffer from different types of vulnerabilities than their JSON + counterparts. To minimize these new security risks, software on the + receiving side SHOULD reject all messages that do not comply with the + rules of this document and reply with an appropriate error message to + the sender. +
+ @@ -309,7 +840,7 @@ module example-barmod { - + Extensible Markup Language (XML) 1.0 (Fifth Edition) @@ -333,11 +865,16 @@ module example-barmod { + + + +
- Substantial text in this document was copied from . The - authors wish to thank Ladislav Lhotka for authoring RFC 7951. + Substantial amounts of text in this document was copied from + and . The authors wish to thank Martin Björklund and + Ladislav Lhotka for authoring RFC 7950 and RFC 7951, respectively.
UpdatedPull RequestBranch NameMerge OperationFormatsActions
$TITLE (#$NUMBER)$d
rfc7950bis: html / text / xml
yang-xml: html / text / xml
yang-proto: html / text / xml
N/A, since this is the \"main\" branch (last updated by #$NUMBER: $TITLE).#$NUMBER: $TITLEN/A, since this is the \"main\" branch.Branch \"$branch\" merges into branch \"$BASE\".
rfc7950bis: html / text / xml
yang-xml: html / text / xml
yang-proto: html / text / xml
rfc7950bis: Diff with RFC7950
Diff with Datatracker
yang-xml:Diff with Datatracker
yang-proto:Diff with Datatracker
rfc7950bis: Diff with RFC7950
Diff with Datatracker
yang-xml:Diff with Datatracker
yang-proto:Diff with Datatracker
rfc7950bis: Diff with Main
yang-xml: Diff with Main
yang-proto: Diff with Main
rfc7950bis: Diff with Base
yang-xml: Diff with Base
yang-proto: Diff with Base