SlideShare ist ein Scribd-Unternehmen logo
1 von 20
Downloaden Sie, um offline zu lesen
RFC 7951(JSON Encoding of Data Modeled with YANG)ベースの勉強資料です。
下線、ハイライトは個人的に重要そうなところ。斜体、#はメモ。
原文のMUST/REQUIRED/SHALL/SHOULD/MAY/OPTIONAL等の​RFC2119​用語は原文のまま残しています。
 MUST、REQUIRED、SHALL:絶対的な要求事項
 MUST NOT:絶対的な禁止事項
 SHOULD、RECOMMENDED:慎重に重要性を判断するべき要求事項
 SHOULD NOT、NOT RECOMMENDED:慎重に重要性を判断するべき禁止事項
 MAY、OPTIONAL:オプション。
間違っていたらコメントをお願いします。
元ネタ(RFC7951)
https://tools.ietf.org/html/rfc7951
Errata
https://www.rfc-editor.org/errata_search.php?rfc=7951
JSON Encoding of Data Modeled with YANG
Abstract
This document defines encoding rules for representing configuration data, state data,
parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined
using YANG as JavaScript Object Notation (JSON) text.
YANGで定義されたconfig data、state data、RPC、action、notificationをJSONで表現するエンコードルールを定義
する。
Table of Contents
Abstract 1
Table of Contents 1
1. Introduction 3
3. Properties of the JSON Encoding 3
4. Names and Namespaces 4
5. Encoding of YANG Data Node Instances 6
5.1. The "leaf" Data Node 7
5.2. The "container" Data Node 7
5.3. The "leaf-list" Data Node 8
5.4. The "list" Data Node 8
5.5. The "anydata" Data Node 9
5.6. The "anyxml" Data Node 10
5.7. Metadata Objects 10
6. Representing YANG Data Types in JSON Values 10
6.1. Numeric Types 11
6.2. The "string" Type 12
6.3. The "boolean" Type 12
6.4. The "enumeration" Type 12
6.5. The "bits" Type 13
1
6.6. The "binary" Type 13
6.7. The "leafref" Type 13
6.8. The "identityref" Type 14
6.9. The "empty" Type 14
6.10. The "union" Type 15
6.11. The "instance-identifier" Type 16
7. I-JSON Compliance 17
8. Security Considerations 17
Appendix A. A Complete Example 18
2
1. Introduction
The Network Configuration Protocol (NETCONF) [RFC6241] uses XML [XML] for encoding data in its
Content Layer. Other management protocols might want to use other encodings while still
benefiting from using YANG [RFC7950] as the data modeling language.
NETCONFはXMLを使用してコンテンツレイヤーのデータをエンコードする。NETCONF以外の管理プロトコルでは、YANGを使用す
るが、XML以外のエンコードを使用したい場合がある。
For example, the RESTCONF protocol [RESTCONF] supports two encodings: XML (media type
"application/yang.data+xml") and JavaScript Object Notation (JSON) (media type
"application/yang.data+json").
例えば、RESTCONFはXMLとJSONによるエンコードをサポートする。
● XML : media type "application/yang.data+xml"
● JSON : media type "application/yang.data+json"
The specification of the YANG 1.1 data modeling language [RFC7950] defines only XML encoding
of data trees, i.e., configuration data, state data, input/output parameters of Remote
Procedure Call (RPC) operations or actions, and notifications. The aim of this document is to
define rules for encoding the same data as JSON text [RFC7159].
YANG 1.1の仕様ではXMLエンコーディングのみを定義している。本ドキュメントでは、JSONでエンコードするためのルールを定
義する。
#JSONの最新RFC : ​https://tools.ietf.org/html/rfc8259
3. Properties of the JSON Encoding
This document defines JSON encoding for YANG data trees and their subtrees. It is always
assumed that the top-level structure in JSON-encoded data is an object.
YANGのJSONエンコーディングを定義する。JSONエンコーディングされたデータの最上位の構造はオブジェクトである。
#​https://tools.ietf.org/html/rfc8259
オブジェクト object = begin-object [ member *( value-separator member ) ]
end-object
メンバー member = string name-separator value
name-separator = ws %x3A ws ; : colon
begin-object = ws %x7B ws ; { left curly bracket
end-object = ws %x7D ws ; } right curly bracket
Instances of YANG data nodes (leafs, containers, leaf-lists, lists, anydata nodes, and anyxml
nodes) are encoded as members of a JSON object, i.e., name/value pairs. Section 4 defines how
the name part is formed, and the following sections deal with the value part. The encoding
rules are identical for all types of data trees, i.e., configuration data, state data,
parameters of RPC operations, actions, and notifications.
YANGデータノードのインスタンス(leaf、container、leaf-list、list、anydata、anyxml)は、JSONオブジェクトの
メンバー、つまりname/valueとしてエンコードされる。section 4ではnameの形式を定義する。それ以降のセクションでは、
valueを扱う。エンコードのルールは、全てのデータツリーで共通である。
3
With the exception of "anydata" encoding (Section 5.5), all rules in this document are also
applicable to YANG 1.0 [RFC6020].
anydataのエンコードを除き、全ての規則はYANG 1.0にも適用される。
Unlike XML element content, JSON values carry partial type information (number, string,
boolean). The JSON encoding is defined so that this information is never in conflict with the
data type of the corresponding YANG leaf or leaf-list.
XMK要素のコンテンツとは異なり、JSON valueには型情報(number、string、boolean)が含まれる。JSONエンコードは、
この情報がYANGのデータ型と競合しないように定義される。
With the exception of anyxml and schema-less anydata nodes, it is possible to map a
JSON-encoded data tree to XML encoding as defined in [RFC7950], and vice versa. However, such
conversions require the YANG data model to be available.
anyxmlおよびschema-less anydataを除き、JSONエンコードされたデータツリーをXMLエンコードにマップすること、およ
びその逆が可能である。ただし、それにはYANGが必要である。
In order to achieve maximum interoperability while allowing implementations to use a variety
of existing JSON parsers, the JSON encoding rules follow, as much as possible, the constraints
of the ​I-JSON (Internet JSON) restricted profile [RFC7493]​. Section 7 discusses I-JSON
conformance in more detail.
実装で様々なJSONパーサーを使用できるようにしながら相互運用性を実現するために、JSONエンコード規則は
I-JSON(Internet JSON)の制約に従う。Section 7でI-JSONへの準拠について述べる。
4. Names and Namespaces
A JSON object member name MUST be in one of the following forms:
JSONオブジェクトのメンバー名は、次のいずれかであること。
● simple​ - identical to the identifier of the corresponding YANG data node.
YANGの識別子と同じ。
● namespace-qualified​ - the data node identifier is prefixed with the name of the module
in which the data node is defined, separated from the data node identifier by the colon
character (":").
モジュールの名前をプレフィックスとし、YANGの識別子との間を”:”で区切る。
#XMLのnamespaceと同じような感じ。
#simple -> interface
#namespace-qualified -> ietf-interfaces:interface
The name of a module determines the namespace of all data node names defined in that module.
If a data node is defined in a submodule, then the namespace-qualified member name uses the
name of the main module to which the submodule belongs.
モジュール名は、モジュールで定義されている全てのデータノード名のnamespaceを決定する。データノードがサブモジュール
で定義されている場合、サブモジュールが属するメインモジュールの名前を使用する。
ABNF syntax [RFC5234] of a member name is shown in Figure 1, where the production for
"identifier" is defined in Section 14 of [RFC7950].
メンバー名のABNF構文をFigure 1に示す。”identifier”の規則はRFC7950 section 14参照。
4
member-name = [identifier ":"] identifier
RFC 7950 Section 14
identity-stmt = identity-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
*base-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
Figure 1: ABNF Production for a JSON Member Name
A namespace-qualified member name MUST be used for all members of a top-level JSON object and
then also whenever the namespaces of the data node and its parent node are different. ​In all
other cases, the simple form of the member name MUST be used.
namespace-qualifiedは、最上位のJSONオブジェクトの全てのメンバーに使用すること。また、親ノードのnamespaceと異
なるデータノードにも使用すること。それ以外の場合、simpleを使用すること。
#最上位、親ノードとnamespaceが異なる場合にnamespace-qualifiedが必要な理由は、モジュール名が特定できるようにす
るため。
For example, consider the following YANG module:
例えば、以下のYANGモジュールの場合、
module example-foomod {
namespace "http://example.com/foomod";
prefix "foomod";
container top { ​#最上位だからnamespace-qualified
leaf foo { ​#それ以外の場合だからsimple
type uint8;
}
}
}
If the data model consists only of this module, then the following is valid JSON-encoded
configuration data:
以下のようにJSONエンコードされる。
{
"example-foomod:top": { ​#最上位だからnamespace-qualified (module名:識別子)
"foo": 54 ​#それ以外の場合だからsimple(識別子のみ)
}
}
Note that the member of the top-level object uses the namespace-qualified name but the "foo"
leaf doesn't because it is defined in the same module as its parent container "top".
5
最上位オブジェクトのメンバーはnamespace-qualifiedを使用するが、”foo”はその親コンテナ”top”と同じモジュールで定
義されているため使用しない。
Now, assume that the container "top" is augmented from another module, "example-barmod":
コンテナ”top”が別のモジュール”example-barmod”からaugmentされていると仮定する。
#augmentの場合のnamespace-qualifiedに注意。
module example-barmod {
namespace "http://example.com/barmod";
prefix "barmod";
import example-foomod {
prefix "foomod";
}
augment "/foomod:top" {
leaf bar { ​#example-foomod:topにexample-barmod:barをaugmentする
type boolean;
}
}
}
Valid JSON-encoded configuration data containing both leafs may then look like this:
JSONエンコードは以下になる。
{
"example-foomod:top": { ​#最上位だからnamespace-qualified (module名:識別子)
"foo": 54, ​#それ以外の場合だからsimple(識別子のみ)
"example-barmod:bar": true ​#親ノードとnamespaceが異なるからnamespace-qualified (module名:識別子)
}
}
The name of the "bar" leaf is prefixed with the namespace identifier because its parent is
defined in a different module.
“bar”の名前には、親(”top”)が別のモジュールで定義されているため、namespaceがプレフィックスにつけられる。
Explicit namespace identifiers are sometimes needed when encoding values of the "identityref"
and "instance-identifier" types. The same form of namespace-qualified name as defined above
is then used. See Sections 6.8 and 6.11 for details.
"identityref"、"instance-identifier"をエンコードするとき、明示的にnamespaceが必要になる場合がある。上記と
同じnamespace-qualifiedが使用される。詳細はsection 6.8、6.11参照。
5. Encoding of YANG Data Node Instances
Every data node instance is encoded as a name/value pair where the name is formed from the
data node identifier using the rules of Section 4. The value depends on the category of the
data node, as explained in the following subsections.
全てのデータノードは、name/valueでエンコードされる。nameはsection 4のルールを使用してデータノードの識別子から生
成される。Valueは以降で説明するように、データノードのカテゴリによって異なる。
6
Character encoding MUST be UTF-8.
文字コードはUTF-8であること。
5.1. The "leaf" Data Node
A leaf instance is encoded as a name/value pair where the value can be a string, number,
literal "true" or "false", or the special array "[null]", depending on the type of the leaf
(see Section 6 for the type encoding rules).
leafはname/valueにエンコードされる。valueはleafのタイプに応じstring、number、true or false、[null]であ
る。タイプはsection 6参照。
Example: For the leaf node definition
leaf foo {
type uint8;
}
the following is a valid JSON-encoded instance:
"foo": 123
5.2. The "container" Data Node
A container instance is encoded as a name/object pair. The container's child data nodes are
encoded as members of the object.
コンテナはname/objectにエンコードされる。コンテナの子ノードは、オブジェクトのメンバーとしてエンコードされる。
Example: For the container definition
container bar {
leaf foo {
type uint8;
}
}
the following is a valid JSON-encoded instance:
"bar": {
"foo": 123
}
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
name-separator = ws %x3A ws ; : colon
begin-object = ws %x7B ws ; { left curly bracket
end-object = ws %x7D ws ; } right curly bracket
7
5.3. The "leaf-list" Data Node
A leaf-list is encoded as a name/array pair, and the array elements are values of some scalar
type, which can be a string, number, literal "true" or "false", or the special array "[null]",
depending on the type of the leaf-list (see Section 6 for the type encoding rules).
leaf-listはname/arrayにエンコードされ、配列の要素はleaf-listのタイプに応じてstring、number、true or
false、[null]のいずれかのスカラー型である。
The ordering of array elements follows the same rules as the ordering of XML elements
representing leaf-list entries in the XML encoding. Specifically, the "ordered-by" properties
(Section 7.7.7 in [RFC7950]) MUST be observed.
配列の要素の順序は、XMLエンコードのleaf-listのXMLエレメントと同じ規則に従う。具体的にはRFC7950の”orderd-by”プ
ロパティに従うこと。
Example: For the leaf-list definition
leaf-list foo {
type uint8;
}
the following is a valid JSON-encoded instance:
"foo": [123, 0]
array = begin-array [ value *( value-separator value ) ] end-array
value-separator = ws %x2C ws ; , comma
value = false / null / true / object / array / number / string
begin-array = ws %x5B ws ; [ left square bracket
end-array = ws %x5D ws ; ] right square bracket
5.4. The "list" Data Node
A list instance is encoded as a name/array pair, and the array elements are JSON objects.
listはname/arrayにエンコードされる。配列の要素はJSONオブジェクトである。
The ordering of array elements follows the same rules as the ordering of XML elements
representing list entries in the XML encoding. Specifically, the "ordered-by" properties
(Section 7.7.7 in [RFC7950]) MUST be observed.
配列の要素の順序は、XMLエンコードのleafのXMLエレメントと同じ規則に従う。具体的にはRFC7950の”orderd-by”プロパ
ティに従うこと。
Unlike the XML encoding, where list keys are required to precede any other siblings within a
list entry and appear in the order specified by the data model, ​the order of members in a
JSON-encoded list entry is arbitrary​ because JSON objects are fundamentally unordered
collections of members.
XMLエンコードではlist keyの位置は先頭だが、JSONエンコードでは順序は任意である。
8
Example: For the list definition
list bar {
key foo;
leaf foo {
type uint8;
}
leaf baz {
type string;
}
}
the following is a valid JSON-encoded instance:
"bar": [
{
"foo": 123, ​#list keyの順序任意
"baz": "zig"
},
{
"baz": "zag",
"foo": 0 ​#list keyの順序任意
}
]
5.5. The "anydata" Data Node
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 JSON-encoded instances to the XML encoding defined
in [RFC7950] may be impossible.
anydataはYANGのコンテナとして表される。anydataのデータモデルは実行時に認識される場合と認識されない場合がある。後
者の場合、JSONエンコードされたインスタンスをXMLエンコードに変換することは不可能かもしれない。
An anydata instance is encoded in the same way as a container, i.e., as a name/object pair.
The requirement that anydata content can be modeled by YANG implies the following rules for
the JSON text inside the object:
anydataインスタンスは、コンテナと同様にname/objectにエンコードされる。YANGでモデル化できるための要件は、オブ
ジェクト内のJSONが以下のルールであることを意味する。
● It is valid I-JSON [RFC7493].
I-JSON。
● All object member names satisfy the ABNF production in Figure 1.
全てのオブジェクトのメンバー名がFigure 1のABNFを満たす。
● Any JSON array contains either only unique scalar values (as a leaf-list; see Section
5.3) or only objects (as a list; see Section 5.4).
JSON arrayには一意なスカラー値(leaf-listの場合)またはオブジェクト(listの場合)のいずれかが含まれる。
● The "null" value is only allowed in the single-element array "[null]" corresponding to
the encoding of the "empty" type; see Section 6.9.
“null”は”empty”のエンコードに対応する”[null]”で表される。
9
Example: For the anydata definition
anydata data;
the following is a valid JSON-encoded instance:
"data": {
"ietf-notification:notification": {
"eventTime": "2014-07-29T13:43:01Z",
"example-event:event": {
"event-class": "fault",
"reporting-entity": {
"card": "Ethernet0"
},
"severity": "major"
}
}
}
5.6. The "anyxml" Data Node
An anyxml instance is encoded as a JSON name/value pair. The value MUST satisfy I-JSON
constraints.
anyxmlはname/valueにエンコードされる。ValueはI-JSON制約を満たすこと。
Example: For the anyxml definition
anyxml bar;
the following is a valid JSON-encoded instance:
"bar": [true, null, true]
5.7. Metadata Objects
Apart from instances of YANG data nodes, a JSON document MAY contain special object members
whose name starts with the "@" character (COMMERCIAL AT). Such members are used for special
purposes, such as encoding metadata [RFC7952]. The exact syntax and semantics of such members
are outside the scope of this document.
JSONには名前が”@”で始まるオブジェクトメンバーが含まれてよい。そのようなメンバーは、メタデータのエンコードのような目
的に使用される。そのようなメンバーの構文等はこのドキュメントのスコープ外である。
#​https://tools.ietf.org/html/rfc7952
6. Representing YANG Data Types in JSON Values
The type of the JSON 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.
10
leafまたはleaf-listのJSON valueタイプは、以降に規定されるようにデータノードタイプによって異なる。
6.1. Numeric Types
A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as
a JSON number.
"int8", "int16", "int32", "uint8", "uint16", or "uint32"はJSON numberで表される。
number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; .
digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; -
plus = %x2B ; +
zero = %x30 ; 0
A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose
content is the lexical representation of the corresponding YANG type as specified in Sections
9.2.1 and 9.3.1 of [RFC7950].
"int64", "uint64", or "decimal64"の値はRFC7950のsection 9.2.1、section 9.3.1のJSON Stringで表され
る。
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " quotation mark U+0022
%x5C / ;  reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; 
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
11
For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the
instance would have to be encoded as
Section 5.1のleaf “foo”のタイプがuint8ではなく、uint64だった場合、次のようにエンコードする必要がある。
uint8 "foo": 123
uint64 "foo": "123"
The special handling of 64-bit numbers follows from the I-JSON recommendation to encode
numbers exceeding the IEEE 754-2008 double-precision range [IEEE754-2008] as strings; see
Section 2.2 in [RFC7493].
64bitの数値はI-JSONの推奨に従い、IEEE754-2008の倍精度範囲を超える数値を文字列としてエンコードするためである。
RFC 7493 Section 2.2参照。
6.2. The "string" Type
A "string" value is represented as a JSON string, subject to JSON string encoding rules.
“string”はJSON stringで表される。
6.3. The "boolean" Type
A "boolean" value is represented as the corresponding JSON literal name "true" or "false".
“boolean”はJSON literalの”true” or “false”で表される。
6.4. The "enumeration" Type
An "enumeration" value is represented as a JSON string -- one of the names assigned by "enum"
statements in YANG.
“enumeration”はenum stmtの名前の一つがJSON stringとして表される。
The representation is identical to the lexical representation of the "enumeration" type in
XML; see Section 9.6 in [RFC7950].
XMLの”enumeration”と同じである。
leaf myenum {
type enumeration {
enum zero;
enum one;
enum seven {
value 7;
}
}
}
・XML
<myenum>seven</myenum>
・JSON
"myenum": "seven"
12
6.5. The "bits" Type
A "bits" value is represented as a JSON string -- a space-separated sequence of names of bits
that are set. The permitted bit names are assigned by "bit" statements in YANG.
“bits”はスペース区切りのビット名のシーケンスとして、JSON stringとして表される。ビット名はYANGのbit stmtで割り
当てられる。
The representation is identical to the lexical representation of the "bits" type; see Section
9.7 in [RFC7950].
XMLの”bits”と同じである。
typedef mybits-type {
type bits {
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
bit ten-mb-only {
position 2;
}
}
}
leaf mybits {
type mybits-type;
default "auto-sense-speed";
}
・XML
<mybits>disable-nagle ten-mb-only</mybits>
・JSON
"mybits": "disable-nagle ten-mb-only"
6.6. The "binary" Type
A "binary" value is represented as a JSON string -- base64 encoding of arbitrary binary data.
“binary”はバイナリデータのbase64エンコードとしてJSON stringで表される。
The representation is identical to the lexical representation of the "binary" type in XML; see
Section 9.8 in [RFC7950].
XMLの”binary”と同じである。
6.7. The "leafref" Type
A "leafref" value is represented using the same rules as the type of the leaf to which the
leafref value refers.
“leafref”はleafrefが参照するleafのタイプと同じ規則で表される。
13
6.8. The "identityref" Type
An "identityref" value is represented as a string -- the name of an identity. ​If the identity
is defined in a module other than the leaf node containing the identityref value, the
namespace-qualified form (Section 4) MUST be used.​ ​Otherwise, both the simple and
namespace-qualified forms are permitted.
“identityref”はidentityの名前としてstringで表される。identityが別モジュールで定義されている場合、
namespace-qualifiedを使用すること。それ以外の場合は、simpleとnamespace-qualifiedのどちらを使用してもよい。
For example, consider the following schematic module:
module example-mod {
...
import ietf-interfaces {
prefix if;
}
...
leaf type {
type identityref {
base "if:interface-type"; ​#interface-typeはietf-interfacesモジュールで定義されている
}
}
}
A valid instance of the "type" leaf is then encoded as follows:
"type": "iana-if-type:ethernetCsmacd"
The namespace identifier "iana-if-type" must be present in this case because the
"ethernetCsmacd" identity is not defined in the same module as the "type" leaf.
この例ではnamespace “iana-if-type”が必要である。”ethernetCsmacd” identityが”type” leafと同じモジュール
に存在しないため。
6.9. The "empty" Type
An "empty" value is represented as "[null]", i.e., an array with the "null" literal being its
only element. For the purposes of this document, "[null]" is considered an atomic scalar
value.
“empty”はnullリテラルを要素に持つ配列”[null]”として表される。本ドキュメントでは”[null]”はアトミックスカラー値
とみなす。
array = begin-array [ value *( value-separator value ) ] end-array
value = false / null / true / object / array / number / string
null = %x6e.75.6c.6c ; null
value-separator = ws %x2C ws ; , comma
begin-array = ws %x5B ws ; [ left square bracket
14
end-array = ws %x5D ws ; ] right square bracket
This encoding of the "empty" type was chosen instead of using simply "null" in order to
facilitate the use of empty leafs in common programming languages where the "null" value of a
member is treated as if the member is not present.
メンバーに”null”があることを、メンバーが存在しないとして扱うプログラミング言語でempty leafの使用を容易にするた
め、”null”を使用する代わりにこの”empty”のエンコードが採用された。
Example: For the leaf definition
leaf foo {
type empty;
}
a valid instance is
"foo": [null]
6.10. The "union" Type
A value of the "union" type is encoded as the value of any of the member types.
“union”はメンバーのtypeのいずれかとしてエンコードされる。
When validating a value of the "union" type, the type information conveyed by the JSON
encoding MUST also be taken into account. JSON syntax thus provides additional means for
resolving the member type of the union that are not available in XML encoding.
“union”の値を検証する場合、JSONエンコードのtype情報も考慮すること。JSONはXMLエンコードでは使用できなunionの
typeを解決するための追加の手段を提供する。
For example, consider the following YANG definition:
leaf bar {
type union {
type uint16;
type string;
}
}
In RESTCONF [RESTCONF], it is possible to set the value of "bar" in the following way when
using the "application/yang.data+xml" media type:
RESTCONFではmedia type ”application/yang.data+xml”を使用する場合、barの値を次のように設定できる。
<bar>13.5</bar>
because the value may be interpreted as a string, i.e., the second member type of the union.
When using the "application/yang.data+json" media type, however, this is an error:
15
値がunionの二番目のメンバーstringとして解釈される。しかし、media type “application/yang.data+json”を使用
すると下記はエラーになる。
"bar": 13.5
In this case, the JSON encoding indicates that the value is supposed to be a number rather
than a string, and it is not a valid "uint16" value.
JSONエンコードでは、値がstringではなく数値であることを想定しており、unit16ではない。
#13.5はstringではないのでnumberとして解釈される。13.5はuint16ではないのでエラー。
Conversely, the value of
"bar": "1"
is to be interpreted as a string.
6.11. The "instance-identifier" Type
An "instance-identifier" value is encoded as a string that is analogical to the lexical
representation in XML encoding; see Section 9.13.2 in [RFC7950]. However, the encoding of
namespaces in instance-identifier values follows the rules stated in Section 4, namely:
“instance-identifier”はXMLエンコードと同様のstringでエンコードされる。instance-identifierのnamespaceは
Section 4の規則に従う。
● The leftmost (top-level) data node name is always in the namespace-qualified form.
最上位のデータノード名はnamespace-qualifiedである。
● Any subsequent data node name is in the namespace-qualified form if the node is defined
in a module other than its parent node, and the simple form is used otherwise. This
rule also holds for node names appearing in predicates.
以降のデータノード名は、そのノードが親ノード以外のモジュールで定義されている場合namespace-qualified、そ
うでない場合はsimpleである。これはpredicateにも適用される。
For example,
/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip
#ietf-interfaces module : interfaces, interface, name
#ietf-ip module : ipv4, ip
is a valid instance-identifier value because the data nodes "interfaces", "interface", and
"name" are defined in the module "ietf-interfaces", whereas "ipv4" and "ip" are defined in
"ietf-ip".
データノード"interfaces", "interface", and "name"は、モジュール"ietf-interfaces"で定義され、"ipv4"
and "ip"はモジュール"ietf-ip"で定義される。
16
7. I-JSON Compliance
I-JSON [RFC7493] is a restricted profile of JSON that guarantees maximum interoperability for
protocols that use JSON in their messages, no matter what JSON encoders/decoders are used in
protocol implementations. The encoding defined in this document therefore observes the I-JSON
requirements and recommendations as closely as possible.
I-JSONはJSONの制限付きプロファイルであり、実装に使用されているJSONエンコーダー/デコーダーに関係なく、JSONを使用
するプロトコルの相互運用性を保証する。本ドキュメントで定義されるエンコーディングはI-JSONの要件と推奨事項に準拠す
る。
In particular, the following properties are guaranteed:
特に以下のプロパティが保証される。
● Character encoding is UTF-8.
UTF-8。
● Member names within the same JSON object are always unique.
JSONオブジェクト内のメンバー名は一意である。
● The order of JSON object members is never relied upon.
JSON objectのメンバーの順序に依存しない。
● Numbers of any type supported by YANG can be exchanged reliably. See Section 6.1 for
details.
YANGがサポートする全てのタイプの数値を変換できる。
The JSON encoding defined in this document deviates from I-JSON only in the representation of
the "binary" type. In order to remain compatible with XML encoding, the base64 encoding
scheme is used (Section 6.6), whilst I-JSON recommends base64url instead.
本ドキュメントのJSONエンコードは、”binary”タイプの表現のみがI-JSONから逸脱している。XMLエンコードとの互換性を確
保するために、base64エンコードが使用されるが、I-JSONではbase64urlを使用する。
#base64url
#​https://tools.ietf.org/html/rfc4648#section-5
8. Security Considerations
This document defines an alternative encoding for data modeled in the YANG data modeling
language. As such, it doesn't contribute any new security issues beyond those discussed in
Section 17 of [RFC7950].
本ドキュメントではYANGでモデリングされたデータのエンコード方法を定義する。そのため、RFC 7950 Section 17.
Security Considerations以外の問題は発生しない。
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 [RFC6241] or RESTCONF [RESTCONF]. If this is not the case, external
mechanisms, such as Public-Key Cryptography Standards (PKCS) #7 [RFC2315] or ​JSON Object
Signing and Encryption (JOSE) [RFC7515] [RFC7516]​, need to be considered.
本ドキュメントでは、YANGでモデリングされたデータの署名と暗号化のメカニズムを定義していない。通常の状況では、データの
セキュリティと整合性はNETCONFやRESTCONFなどの管理プロトコルによって保証される。そうでない場合、PKCSやJOSEなどの
メカニズムの検討が必要である。
17
JSON processing is rather different from XML, and JSON parsers may thus suffer from different
types of vulnerabilities than their XML 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.
JSONの処理はXMLとかなり異なるため、JSONパーサーはXMLパーサーと異なる種類の脆弱性の影響を受ける可能性がある。これ
らのセキュリティリスクを最小限に抑えるため、受信側のソフトウェアは本ドキュメントに準拠しないメッセージを拒否し、送信
者に適切なエラーメッセージを送信することが推奨される。
Appendix A. A Complete Example
The JSON document shown below represents the same data as the reply to the NETCONF <get>
request appearing in Appendix D of [RFC7223]. The data model is a combination of two YANG
modules: "ietf-interfaces" and "ex-vlan" (the latter is an example module from Appendix C of
[RFC7223]). The "if-mib" feature defined in the "ietf-interfaces" module is supported.
以下のJSONはRFC7223(A YANG Data Model for Interface Management) Appendix Dと同じデータを表している。
{ ​#オブジェクトから始まる
#container interfaces : name/object
#namespace-qualified : 最上位オブジェクト
"ietf-interfaces:interfaces": {
#list interface : name/array
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"enabled": false
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true,
"ex-vlan:vlan-tagging": true
},
{
"name": "eth1.10",
"type": "iana-if-type:l2vlan",
"enabled": true,
"ex-vlan:base-interface": "eth1",
#親と異なるモジュールのためnamespace-qualified
"ex-vlan:vlan-id": 10 },
{
"name": "lo1",
"type": "iana-if-type:softwareLoopback",
"enabled": true
}
]
},
#container interfaces-state : name/object
#namespace-qualified : 最上位オブジェクト
"ietf-interfaces:interfaces-state": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
#leaf admin-status(type enumeration) :up,down,testing
"admin-status": "down",
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:vlan="http://example.com/vlan">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>false</enabled>
</interface>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<vlan:vlan-tagging>true</vlan:vlan-tagging>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<enabled>true</enabled>
<vlan:base-interface>eth1</vlan:base-interface>
<vlan:vlan-id>10</vlan:vlan-id>
</interface>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<enabled>true</enabled>
</interface>
</interfaces>
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
>
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
18
"oper-status": "down",
"if-index": 2,
"phys-address": "00:01:02:03:04:05",
"statistics": {
"discontinuity-time":
"2013-04-01T03:00:00+00:00"
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"admin-status": "up",
"oper-status": "up",
"if-index": 7,
"phys-address": "00:01:02:03:04:06",
#leaf-list higher-layer-if(type interface-state-ref)
#typedef interface-state-ref {
# type leafref {
# path "/if:interfaces-state/if:interface/if:name";
# }
"higher-layer-if": [
"eth1.10"
],
"statistics": {
"discontinuity-time":
"2013-04-01T03:00:00+00:00"
}
},
{
"name": "eth1.10",
"type": "iana-if-type:l2vlan",
"admin-status": "up",
"oper-status": "up",
"if-index": 9,
"lower-layer-if": [
"eth1"
],
"statistics": {
"discontinuity-time":
"2013-04-01T03:00:00+00:00"
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"admin-status": "down",
"oper-status": "down",
"if-index": 8,
"phys-address": "00:01:02:03:04:07",
"statistics": {
"discontinuity-time":
"2013-04-01T03:00:00+00:00"
}
},
{
"name": "lo1",
"type": "iana-if-type:softwareLoopback",
"admin-status": "up",
"oper-status": "up",
"if-index": 1,
"statistics": {
"discontinuity-time":
"2013-04-01T03:00:00+00:00"
}
}
<admin-status>down</admin-status>
<oper-status>down</oper-status>
<if-index>2</if-index>
<phys-address>00:01:02:03:04:05</phys-address>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>7</if-index>
<phys-address>00:01:02:03:04:06</phys-address>
<higher-layer-if>eth1.10</higher-layer-if>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>9</if-index>
<lower-layer-if>eth1</lower-layer-if>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<!-- This interface is not configured -->
<interface>
<name>eth2</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
<if-index>8</if-index>
<phys-address>00:01:02:03:04:07</phys-address>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>1</if-index>
19
]
}
}
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
20

Weitere ähnliche Inhalte

Was ist angesagt?

OSS-DB Goldへの第一歩~実践!運用管理~
OSS-DB Goldへの第一歩~実践!運用管理~OSS-DB Goldへの第一歩~実践!運用管理~
OSS-DB Goldへの第一歩~実践!運用管理~Shigeru Hanada
 
Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.Ryota Watabe
 
Oracle Database In Lock
Oracle Database In LockOracle Database In Lock
Oracle Database In LockRyota Watabe
 
Linuxのsemaphoreとmutexを見る 
Linuxのsemaphoreとmutexを見る Linuxのsemaphoreとmutexを見る 
Linuxのsemaphoreとmutexを見る wata2ki
 
TypeScriptハンズオン第2回テキスト
TypeScriptハンズオン第2回テキストTypeScriptハンズオン第2回テキスト
TypeScriptハンズオン第2回テキストmizuky fujitani
 
[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう by SRA OSS, Inc. 日本支社 高塚遥
[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう  by SRA OSS, Inc. 日本支社 高塚遥[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう  by SRA OSS, Inc. 日本支社 高塚遥
[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう by SRA OSS, Inc. 日本支社 高塚遥Insight Technology, Inc.
 
データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)
データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)
データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)Kenta Oku
 
S2dao Seminar in tripodworks
S2dao Seminar in tripodworksS2dao Seminar in tripodworks
S2dao Seminar in tripodworkstripodworks
 
後期第六回ネットワークチーム講座資料
後期第六回ネットワークチーム講座資料後期第六回ネットワークチーム講座資料
後期第六回ネットワークチーム講座資料densan_teacher
 
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009Ryota Watabe
 
SAStruts Seminar In Tripodworks
SAStruts Seminar In TripodworksSAStruts Seminar In Tripodworks
SAStruts Seminar In Tripodworkstripodworks
 

Was ist angesagt? (12)

OSS-DB Goldへの第一歩~実践!運用管理~
OSS-DB Goldへの第一歩~実践!運用管理~OSS-DB Goldへの第一歩~実践!運用管理~
OSS-DB Goldへの第一歩~実践!運用管理~
 
Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.
 
Oracle Database In Lock
Oracle Database In LockOracle Database In Lock
Oracle Database In Lock
 
Linuxのsemaphoreとmutexを見る 
Linuxのsemaphoreとmutexを見る Linuxのsemaphoreとmutexを見る 
Linuxのsemaphoreとmutexを見る 
 
TypeScriptハンズオン第2回テキスト
TypeScriptハンズオン第2回テキストTypeScriptハンズオン第2回テキスト
TypeScriptハンズオン第2回テキスト
 
[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう by SRA OSS, Inc. 日本支社 高塚遥
[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう  by SRA OSS, Inc. 日本支社 高塚遥[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう  by SRA OSS, Inc. 日本支社 高塚遥
[db tech showcase Tokyo 2014] B26: PostgreSQLを拡張してみよう by SRA OSS, Inc. 日本支社 高塚遥
 
データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)
データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)
データベース03 - SQL(CREATE, INSERT, DELETE, UPDATEなど)
 
S2dao Seminar in tripodworks
S2dao Seminar in tripodworksS2dao Seminar in tripodworks
S2dao Seminar in tripodworks
 
後期第六回ネットワークチーム講座資料
後期第六回ネットワークチーム講座資料後期第六回ネットワークチーム講座資料
後期第六回ネットワークチーム講座資料
 
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
 
eZ Publishのextension開発チュートリアル
eZ Publishのextension開発チュートリアルeZ Publishのextension開発チュートリアル
eZ Publishのextension開発チュートリアル
 
SAStruts Seminar In Tripodworks
SAStruts Seminar In TripodworksSAStruts Seminar In Tripodworks
SAStruts Seminar In Tripodworks
 

Ähnlich wie RFC7951(JSON Encoding of Data Modeled with YANG)の勉強資料

セマンテックウェブとRDFDB
セマンテックウェブとRDFDBセマンテックウェブとRDFDB
セマンテックウェブとRDFDBHirosuke Asano
 
ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-
ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-
ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-uedayou
 
Knct-SG #1 Parser入門
Knct-SG #1 Parser入門Knct-SG #1 Parser入門
Knct-SG #1 Parser入門y1r96 Ueno
 
prmdのドキュメントが読みやすくなる話
prmdのドキュメントが読みやすくなる話prmdのドキュメントが読みやすくなる話
prmdのドキュメントが読みやすくなる話ota42y
 
Java オブジェクトの内部構造
Java オブジェクトの内部構造Java オブジェクトの内部構造
Java オブジェクトの内部構造Taku Miyakawa
 
RESTful Web API Design
RESTful Web API DesignRESTful Web API Design
RESTful Web API DesignAkinari Tsugo
 
Jsonデモの概要
Jsonデモの概要Jsonデモの概要
Jsonデモの概要Hiroki Ito
 
2011年度 生物データベース論 2日目 木構造データ
2011年度 生物データベース論 2日目 木構造データ2011年度 生物データベース論 2日目 木構造データ
2011年度 生物データベース論 2日目 木構造データTaro L. Saito
 
イマドキの現場で使えるJavaライブラリ事情
イマドキの現場で使えるJavaライブラリ事情イマドキの現場で使えるJavaライブラリ事情
イマドキの現場で使えるJavaライブラリ事情takezoe
 
いまさら聞けないJSONPのまとめ
いまさら聞けないJSONPのまとめいまさら聞けないJSONPのまとめ
いまさら聞けないJSONPのまとめYujiro Araki
 
Cookpad Summer Intern 2015 - Programming Paradigm
Cookpad Summer Intern 2015 - Programming ParadigmCookpad Summer Intern 2015 - Programming Paradigm
Cookpad Summer Intern 2015 - Programming ParadigmMinero Aoki
 
PHP基礎勉強会
PHP基礎勉強会PHP基礎勉強会
PHP基礎勉強会Yuji Otani
 
Kanazawa.js.Next
Kanazawa.js.NextKanazawa.js.Next
Kanazawa.js.Nextdynamis
 
いいパブッ!! - よくわかるEPUB 3
いいパブッ!! - よくわかるEPUB 3いいパブッ!! - よくわかるEPUB 3
いいパブッ!! - よくわかるEPUB 3Hiroshi Takase
 

Ähnlich wie RFC7951(JSON Encoding of Data Modeled with YANG)の勉強資料 (17)

セマンテックウェブとRDFDB
セマンテックウェブとRDFDBセマンテックウェブとRDFDB
セマンテックウェブとRDFDB
 
ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-
ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-
ふぉとぶらり+LODAC -iPhoneアプリでのSPARQLでの活用事例-
 
Knct-SG #1 Parser入門
Knct-SG #1 Parser入門Knct-SG #1 Parser入門
Knct-SG #1 Parser入門
 
prmdのドキュメントが読みやすくなる話
prmdのドキュメントが読みやすくなる話prmdのドキュメントが読みやすくなる話
prmdのドキュメントが読みやすくなる話
 
Java オブジェクトの内部構造
Java オブジェクトの内部構造Java オブジェクトの内部構造
Java オブジェクトの内部構造
 
RESTful Web API Design
RESTful Web API DesignRESTful Web API Design
RESTful Web API Design
 
MongoDB
MongoDBMongoDB
MongoDB
 
Jsonデモの概要
Jsonデモの概要Jsonデモの概要
Jsonデモの概要
 
2011年度 生物データベース論 2日目 木構造データ
2011年度 生物データベース論 2日目 木構造データ2011年度 生物データベース論 2日目 木構造データ
2011年度 生物データベース論 2日目 木構造データ
 
イマドキの現場で使えるJavaライブラリ事情
イマドキの現場で使えるJavaライブラリ事情イマドキの現場で使えるJavaライブラリ事情
イマドキの現場で使えるJavaライブラリ事情
 
いまさら聞けないJSONPのまとめ
いまさら聞けないJSONPのまとめいまさら聞けないJSONPのまとめ
いまさら聞けないJSONPのまとめ
 
Cookpad Summer Intern 2015 - Programming Paradigm
Cookpad Summer Intern 2015 - Programming ParadigmCookpad Summer Intern 2015 - Programming Paradigm
Cookpad Summer Intern 2015 - Programming Paradigm
 
DeclarativeSql
DeclarativeSqlDeclarativeSql
DeclarativeSql
 
PHP基礎勉強会
PHP基礎勉強会PHP基礎勉強会
PHP基礎勉強会
 
Kanazawa.js.Next
Kanazawa.js.NextKanazawa.js.Next
Kanazawa.js.Next
 
金魚本読書ノート JPA編
金魚本読書ノート JPA編金魚本読書ノート JPA編
金魚本読書ノート JPA編
 
いいパブッ!! - よくわかるEPUB 3
いいパブッ!! - よくわかるEPUB 3いいパブッ!! - よくわかるEPUB 3
いいパブッ!! - よくわかるEPUB 3
 

Mehr von Tetsuya Hasegawa

面白いセキュリティツール その2
面白いセキュリティツール その2面白いセキュリティツール その2
面白いセキュリティツール その2Tetsuya Hasegawa
 
RFC7589(NETCONF Protocol over TLS)の勉強資料
RFC7589(NETCONF Protocol over TLS)の勉強資料RFC7589(NETCONF Protocol over TLS)の勉強資料
RFC7589(NETCONF Protocol over TLS)の勉強資料Tetsuya Hasegawa
 
RFC8632(A YANG Data Model for Alarm Management)の勉強資料
RFC8632(A YANG Data Model for Alarm Management)の勉強資料RFC8632(A YANG Data Model for Alarm Management)の勉強資料
RFC8632(A YANG Data Model for Alarm Management)の勉強資料Tetsuya Hasegawa
 
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料Tetsuya Hasegawa
 
3GPP F1インターフェース(TS38.470-f50)の概要
3GPP F1インターフェース(TS38.470-f50)の概要3GPP F1インターフェース(TS38.470-f50)の概要
3GPP F1インターフェース(TS38.470-f50)の概要Tetsuya Hasegawa
 
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)Tetsuya Hasegawa
 
RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料
RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料
RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料Tetsuya Hasegawa
 
RFC6243(With-defaults Capability for NETCONF)の勉強資料
RFC6243(With-defaults Capability for NETCONF)の勉強資料RFC6243(With-defaults Capability for NETCONF)の勉強資料
RFC6243(With-defaults Capability for NETCONF)の勉強資料Tetsuya Hasegawa
 
RFC6241(Network Configuration Protocol (NETCONF))の勉強資料
RFC6241(Network Configuration Protocol (NETCONF))の勉強資料RFC6241(Network Configuration Protocol (NETCONF))の勉強資料
RFC6241(Network Configuration Protocol (NETCONF))の勉強資料Tetsuya Hasegawa
 
RFC5277(NETCONF Event Notifications)の勉強資料
RFC5277(NETCONF Event Notifications)の勉強資料RFC5277(NETCONF Event Notifications)の勉強資料
RFC5277(NETCONF Event Notifications)の勉強資料Tetsuya Hasegawa
 
5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向
5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向
5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向Tetsuya Hasegawa
 
MCPC第5回イノベーションチャレンジセミナーメモ
MCPC第5回イノベーションチャレンジセミナーメモMCPC第5回イノベーションチャレンジセミナーメモ
MCPC第5回イノベーションチャレンジセミナーメモTetsuya Hasegawa
 
面白いセキュリティツール
面白いセキュリティツール面白いセキュリティツール
面白いセキュリティツールTetsuya Hasegawa
 
3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめTetsuya Hasegawa
 
Infer:人工知能を使った静的コードチェック
Infer:人工知能を使った静的コードチェックInfer:人工知能を使った静的コードチェック
Infer:人工知能を使った静的コードチェックTetsuya Hasegawa
 
3GPP TR23.711-e00まとめ
3GPP TR23.711-e00まとめ3GPP TR23.711-e00まとめ
3GPP TR23.711-e00まとめTetsuya Hasegawa
 
3GPP TR38.801-e00まとめ
3GPP TR38.801-e00まとめ3GPP TR38.801-e00まとめ
3GPP TR38.801-e00まとめTetsuya Hasegawa
 
Web applicationpenetrationtest その5
Web applicationpenetrationtest その5Web applicationpenetrationtest その5
Web applicationpenetrationtest その5Tetsuya Hasegawa
 
Web applicationpenetrationtest その4
Web applicationpenetrationtest その4Web applicationpenetrationtest その4
Web applicationpenetrationtest その4Tetsuya Hasegawa
 

Mehr von Tetsuya Hasegawa (20)

面白いセキュリティツール その2
面白いセキュリティツール その2面白いセキュリティツール その2
面白いセキュリティツール その2
 
RFC7589(NETCONF Protocol over TLS)の勉強資料
RFC7589(NETCONF Protocol over TLS)の勉強資料RFC7589(NETCONF Protocol over TLS)の勉強資料
RFC7589(NETCONF Protocol over TLS)の勉強資料
 
RFC8632(A YANG Data Model for Alarm Management)の勉強資料
RFC8632(A YANG Data Model for Alarm Management)の勉強資料RFC8632(A YANG Data Model for Alarm Management)の勉強資料
RFC8632(A YANG Data Model for Alarm Management)の勉強資料
 
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
 
3GPP F1インターフェース(TS38.470-f50)の概要
3GPP F1インターフェース(TS38.470-f50)の概要3GPP F1インターフェース(TS38.470-f50)の概要
3GPP F1インターフェース(TS38.470-f50)の概要
 
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
 
RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料
RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料
RFC8071(NETCONF Call Home and RESTCONF Call Home)の勉強資料
 
RFC6243(With-defaults Capability for NETCONF)の勉強資料
RFC6243(With-defaults Capability for NETCONF)の勉強資料RFC6243(With-defaults Capability for NETCONF)の勉強資料
RFC6243(With-defaults Capability for NETCONF)の勉強資料
 
RFC6241(Network Configuration Protocol (NETCONF))の勉強資料
RFC6241(Network Configuration Protocol (NETCONF))の勉強資料RFC6241(Network Configuration Protocol (NETCONF))の勉強資料
RFC6241(Network Configuration Protocol (NETCONF))の勉強資料
 
RFC5277(NETCONF Event Notifications)の勉強資料
RFC5277(NETCONF Event Notifications)の勉強資料RFC5277(NETCONF Event Notifications)の勉強資料
RFC5277(NETCONF Event Notifications)の勉強資料
 
5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向
5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向
5Gを含む将来ネットワークにおけるAI活用に関する国際標準化動向
 
MCPC第5回イノベーションチャレンジセミナーメモ
MCPC第5回イノベーションチャレンジセミナーメモMCPC第5回イノベーションチャレンジセミナーメモ
MCPC第5回イノベーションチャレンジセミナーメモ
 
RFC5996(IKEv2)第2版
RFC5996(IKEv2)第2版RFC5996(IKEv2)第2版
RFC5996(IKEv2)第2版
 
面白いセキュリティツール
面白いセキュリティツール面白いセキュリティツール
面白いセキュリティツール
 
3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ
 
Infer:人工知能を使った静的コードチェック
Infer:人工知能を使った静的コードチェックInfer:人工知能を使った静的コードチェック
Infer:人工知能を使った静的コードチェック
 
3GPP TR23.711-e00まとめ
3GPP TR23.711-e00まとめ3GPP TR23.711-e00まとめ
3GPP TR23.711-e00まとめ
 
3GPP TR38.801-e00まとめ
3GPP TR38.801-e00まとめ3GPP TR38.801-e00まとめ
3GPP TR38.801-e00まとめ
 
Web applicationpenetrationtest その5
Web applicationpenetrationtest その5Web applicationpenetrationtest その5
Web applicationpenetrationtest その5
 
Web applicationpenetrationtest その4
Web applicationpenetrationtest その4Web applicationpenetrationtest その4
Web applicationpenetrationtest その4
 

RFC7951(JSON Encoding of Data Modeled with YANG)の勉強資料

  • 1. RFC 7951(JSON Encoding of Data Modeled with YANG)ベースの勉強資料です。 下線、ハイライトは個人的に重要そうなところ。斜体、#はメモ。 原文のMUST/REQUIRED/SHALL/SHOULD/MAY/OPTIONAL等の​RFC2119​用語は原文のまま残しています。  MUST、REQUIRED、SHALL:絶対的な要求事項  MUST NOT:絶対的な禁止事項  SHOULD、RECOMMENDED:慎重に重要性を判断するべき要求事項  SHOULD NOT、NOT RECOMMENDED:慎重に重要性を判断するべき禁止事項  MAY、OPTIONAL:オプション。 間違っていたらコメントをお願いします。 元ネタ(RFC7951) https://tools.ietf.org/html/rfc7951 Errata https://www.rfc-editor.org/errata_search.php?rfc=7951 JSON Encoding of Data Modeled with YANG Abstract This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. YANGで定義されたconfig data、state data、RPC、action、notificationをJSONで表現するエンコードルールを定義 する。 Table of Contents Abstract 1 Table of Contents 1 1. Introduction 3 3. Properties of the JSON Encoding 3 4. Names and Namespaces 4 5. Encoding of YANG Data Node Instances 6 5.1. The "leaf" Data Node 7 5.2. The "container" Data Node 7 5.3. The "leaf-list" Data Node 8 5.4. The "list" Data Node 8 5.5. The "anydata" Data Node 9 5.6. The "anyxml" Data Node 10 5.7. Metadata Objects 10 6. Representing YANG Data Types in JSON Values 10 6.1. Numeric Types 11 6.2. The "string" Type 12 6.3. The "boolean" Type 12 6.4. The "enumeration" Type 12 6.5. The "bits" Type 13 1
  • 2. 6.6. The "binary" Type 13 6.7. The "leafref" Type 13 6.8. The "identityref" Type 14 6.9. The "empty" Type 14 6.10. The "union" Type 15 6.11. The "instance-identifier" Type 16 7. I-JSON Compliance 17 8. Security Considerations 17 Appendix A. A Complete Example 18 2
  • 3. 1. Introduction The Network Configuration Protocol (NETCONF) [RFC6241] uses XML [XML] for encoding data in its Content Layer. Other management protocols might want to use other encodings while still benefiting from using YANG [RFC7950] as the data modeling language. NETCONFはXMLを使用してコンテンツレイヤーのデータをエンコードする。NETCONF以外の管理プロトコルでは、YANGを使用す るが、XML以外のエンコードを使用したい場合がある。 For example, the RESTCONF protocol [RESTCONF] supports two encodings: XML (media type "application/yang.data+xml") and JavaScript Object Notation (JSON) (media type "application/yang.data+json"). 例えば、RESTCONFはXMLとJSONによるエンコードをサポートする。 ● XML : media type "application/yang.data+xml" ● JSON : media type "application/yang.data+json" The specification of the YANG 1.1 data modeling language [RFC7950] defines only XML encoding of data trees, i.e., configuration data, state data, input/output parameters of Remote Procedure Call (RPC) operations or actions, and notifications. The aim of this document is to define rules for encoding the same data as JSON text [RFC7159]. YANG 1.1の仕様ではXMLエンコーディングのみを定義している。本ドキュメントでは、JSONでエンコードするためのルールを定 義する。 #JSONの最新RFC : ​https://tools.ietf.org/html/rfc8259 3. Properties of the JSON Encoding This document defines JSON encoding for YANG data trees and their subtrees. It is always assumed that the top-level structure in JSON-encoded data is an object. YANGのJSONエンコーディングを定義する。JSONエンコーディングされたデータの最上位の構造はオブジェクトである。 #​https://tools.ietf.org/html/rfc8259 オブジェクト object = begin-object [ member *( value-separator member ) ] end-object メンバー member = string name-separator value name-separator = ws %x3A ws ; : colon begin-object = ws %x7B ws ; { left curly bracket end-object = ws %x7D ws ; } right curly bracket Instances of YANG data nodes (leafs, containers, leaf-lists, lists, anydata nodes, and anyxml nodes) are encoded as members of a JSON object, i.e., name/value pairs. Section 4 defines how the name part is formed, and the following sections deal with the value part. The encoding rules are identical for all types of data trees, i.e., configuration data, state data, parameters of RPC operations, actions, and notifications. YANGデータノードのインスタンス(leaf、container、leaf-list、list、anydata、anyxml)は、JSONオブジェクトの メンバー、つまりname/valueとしてエンコードされる。section 4ではnameの形式を定義する。それ以降のセクションでは、 valueを扱う。エンコードのルールは、全てのデータツリーで共通である。 3
  • 4. With the exception of "anydata" encoding (Section 5.5), all rules in this document are also applicable to YANG 1.0 [RFC6020]. anydataのエンコードを除き、全ての規則はYANG 1.0にも適用される。 Unlike XML element content, JSON values carry partial type information (number, string, boolean). The JSON encoding is defined so that this information is never in conflict with the data type of the corresponding YANG leaf or leaf-list. XMK要素のコンテンツとは異なり、JSON valueには型情報(number、string、boolean)が含まれる。JSONエンコードは、 この情報がYANGのデータ型と競合しないように定義される。 With the exception of anyxml and schema-less anydata nodes, it is possible to map a JSON-encoded data tree to XML encoding as defined in [RFC7950], and vice versa. However, such conversions require the YANG data model to be available. anyxmlおよびschema-less anydataを除き、JSONエンコードされたデータツリーをXMLエンコードにマップすること、およ びその逆が可能である。ただし、それにはYANGが必要である。 In order to achieve maximum interoperability while allowing implementations to use a variety of existing JSON parsers, the JSON encoding rules follow, as much as possible, the constraints of the ​I-JSON (Internet JSON) restricted profile [RFC7493]​. Section 7 discusses I-JSON conformance in more detail. 実装で様々なJSONパーサーを使用できるようにしながら相互運用性を実現するために、JSONエンコード規則は I-JSON(Internet JSON)の制約に従う。Section 7でI-JSONへの準拠について述べる。 4. Names and Namespaces A JSON object member name MUST be in one of the following forms: JSONオブジェクトのメンバー名は、次のいずれかであること。 ● simple​ - identical to the identifier of the corresponding YANG data node. YANGの識別子と同じ。 ● namespace-qualified​ - the data node identifier is prefixed with the name of the module in which the data node is defined, separated from the data node identifier by the colon character (":"). モジュールの名前をプレフィックスとし、YANGの識別子との間を”:”で区切る。 #XMLのnamespaceと同じような感じ。 #simple -> interface #namespace-qualified -> ietf-interfaces:interface The name of a module determines the namespace of all data node names defined in that module. If a data node is defined in a submodule, then the namespace-qualified member name uses the name of the main module to which the submodule belongs. モジュール名は、モジュールで定義されている全てのデータノード名のnamespaceを決定する。データノードがサブモジュール で定義されている場合、サブモジュールが属するメインモジュールの名前を使用する。 ABNF syntax [RFC5234] of a member name is shown in Figure 1, where the production for "identifier" is defined in Section 14 of [RFC7950]. メンバー名のABNF構文をFigure 1に示す。”identifier”の規則はRFC7950 section 14参照。 4
  • 5. member-name = [identifier ":"] identifier RFC 7950 Section 14 identity-stmt = identity-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order *if-feature-stmt *base-stmt [status-stmt] [description-stmt] [reference-stmt] "}") stmtsep Figure 1: ABNF Production for a JSON Member Name A namespace-qualified member name MUST be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. ​In all other cases, the simple form of the member name MUST be used. namespace-qualifiedは、最上位のJSONオブジェクトの全てのメンバーに使用すること。また、親ノードのnamespaceと異 なるデータノードにも使用すること。それ以外の場合、simpleを使用すること。 #最上位、親ノードとnamespaceが異なる場合にnamespace-qualifiedが必要な理由は、モジュール名が特定できるようにす るため。 For example, consider the following YANG module: 例えば、以下のYANGモジュールの場合、 module example-foomod { namespace "http://example.com/foomod"; prefix "foomod"; container top { ​#最上位だからnamespace-qualified leaf foo { ​#それ以外の場合だからsimple type uint8; } } } If the data model consists only of this module, then the following is valid JSON-encoded configuration data: 以下のようにJSONエンコードされる。 { "example-foomod:top": { ​#最上位だからnamespace-qualified (module名:識別子) "foo": 54 ​#それ以外の場合だからsimple(識別子のみ) } } Note that the member of the top-level object uses the namespace-qualified name but the "foo" leaf doesn't because it is defined in the same module as its parent container "top". 5
  • 6. 最上位オブジェクトのメンバーはnamespace-qualifiedを使用するが、”foo”はその親コンテナ”top”と同じモジュールで定 義されているため使用しない。 Now, assume that the container "top" is augmented from another module, "example-barmod": コンテナ”top”が別のモジュール”example-barmod”からaugmentされていると仮定する。 #augmentの場合のnamespace-qualifiedに注意。 module example-barmod { namespace "http://example.com/barmod"; prefix "barmod"; import example-foomod { prefix "foomod"; } augment "/foomod:top" { leaf bar { ​#example-foomod:topにexample-barmod:barをaugmentする type boolean; } } } Valid JSON-encoded configuration data containing both leafs may then look like this: JSONエンコードは以下になる。 { "example-foomod:top": { ​#最上位だからnamespace-qualified (module名:識別子) "foo": 54, ​#それ以外の場合だからsimple(識別子のみ) "example-barmod:bar": true ​#親ノードとnamespaceが異なるからnamespace-qualified (module名:識別子) } } The name of the "bar" leaf is prefixed with the namespace identifier because its parent is defined in a different module. “bar”の名前には、親(”top”)が別のモジュールで定義されているため、namespaceがプレフィックスにつけられる。 Explicit namespace identifiers are sometimes needed when encoding values of the "identityref" and "instance-identifier" types. The same form of namespace-qualified name as defined above is then used. See Sections 6.8 and 6.11 for details. "identityref"、"instance-identifier"をエンコードするとき、明示的にnamespaceが必要になる場合がある。上記と 同じnamespace-qualifiedが使用される。詳細はsection 6.8、6.11参照。 5. Encoding of YANG Data Node Instances Every data node instance is encoded as a name/value pair where the name is formed from the data node identifier using the rules of Section 4. The value depends on the category of the data node, as explained in the following subsections. 全てのデータノードは、name/valueでエンコードされる。nameはsection 4のルールを使用してデータノードの識別子から生 成される。Valueは以降で説明するように、データノードのカテゴリによって異なる。 6
  • 7. Character encoding MUST be UTF-8. 文字コードはUTF-8であること。 5.1. The "leaf" Data Node A leaf instance is encoded as a name/value pair where the value can be a string, number, literal "true" or "false", or the special array "[null]", depending on the type of the leaf (see Section 6 for the type encoding rules). leafはname/valueにエンコードされる。valueはleafのタイプに応じstring、number、true or false、[null]であ る。タイプはsection 6参照。 Example: For the leaf node definition leaf foo { type uint8; } the following is a valid JSON-encoded instance: "foo": 123 5.2. The "container" Data Node A container instance is encoded as a name/object pair. The container's child data nodes are encoded as members of the object. コンテナはname/objectにエンコードされる。コンテナの子ノードは、オブジェクトのメンバーとしてエンコードされる。 Example: For the container definition container bar { leaf foo { type uint8; } } the following is a valid JSON-encoded instance: "bar": { "foo": 123 } object = begin-object [ member *( value-separator member ) ] end-object member = string name-separator value name-separator = ws %x3A ws ; : colon begin-object = ws %x7B ws ; { left curly bracket end-object = ws %x7D ws ; } right curly bracket 7
  • 8. 5.3. The "leaf-list" Data Node A leaf-list is encoded as a name/array pair, and the array elements are values of some scalar type, which can be a string, number, literal "true" or "false", or the special array "[null]", depending on the type of the leaf-list (see Section 6 for the type encoding rules). leaf-listはname/arrayにエンコードされ、配列の要素はleaf-listのタイプに応じてstring、number、true or false、[null]のいずれかのスカラー型である。 The ordering of array elements follows the same rules as the ordering of XML elements representing leaf-list entries in the XML encoding. Specifically, the "ordered-by" properties (Section 7.7.7 in [RFC7950]) MUST be observed. 配列の要素の順序は、XMLエンコードのleaf-listのXMLエレメントと同じ規則に従う。具体的にはRFC7950の”orderd-by”プ ロパティに従うこと。 Example: For the leaf-list definition leaf-list foo { type uint8; } the following is a valid JSON-encoded instance: "foo": [123, 0] array = begin-array [ value *( value-separator value ) ] end-array value-separator = ws %x2C ws ; , comma value = false / null / true / object / array / number / string begin-array = ws %x5B ws ; [ left square bracket end-array = ws %x5D ws ; ] right square bracket 5.4. The "list" Data Node A list instance is encoded as a name/array pair, and the array elements are JSON objects. listはname/arrayにエンコードされる。配列の要素はJSONオブジェクトである。 The ordering of array elements follows the same rules as the ordering of XML elements representing list entries in the XML encoding. Specifically, the "ordered-by" properties (Section 7.7.7 in [RFC7950]) MUST be observed. 配列の要素の順序は、XMLエンコードのleafのXMLエレメントと同じ規則に従う。具体的にはRFC7950の”orderd-by”プロパ ティに従うこと。 Unlike the XML encoding, where list keys are required to precede any other siblings within a list entry and appear in the order specified by the data model, ​the order of members in a JSON-encoded list entry is arbitrary​ because JSON objects are fundamentally unordered collections of members. XMLエンコードではlist keyの位置は先頭だが、JSONエンコードでは順序は任意である。 8
  • 9. Example: For the list definition list bar { key foo; leaf foo { type uint8; } leaf baz { type string; } } the following is a valid JSON-encoded instance: "bar": [ { "foo": 123, ​#list keyの順序任意 "baz": "zig" }, { "baz": "zag", "foo": 0 ​#list keyの順序任意 } ] 5.5. The "anydata" Data Node 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 JSON-encoded instances to the XML encoding defined in [RFC7950] may be impossible. anydataはYANGのコンテナとして表される。anydataのデータモデルは実行時に認識される場合と認識されない場合がある。後 者の場合、JSONエンコードされたインスタンスをXMLエンコードに変換することは不可能かもしれない。 An anydata instance is encoded in the same way as a container, i.e., as a name/object pair. The requirement that anydata content can be modeled by YANG implies the following rules for the JSON text inside the object: anydataインスタンスは、コンテナと同様にname/objectにエンコードされる。YANGでモデル化できるための要件は、オブ ジェクト内のJSONが以下のルールであることを意味する。 ● It is valid I-JSON [RFC7493]. I-JSON。 ● All object member names satisfy the ABNF production in Figure 1. 全てのオブジェクトのメンバー名がFigure 1のABNFを満たす。 ● Any JSON array contains either only unique scalar values (as a leaf-list; see Section 5.3) or only objects (as a list; see Section 5.4). JSON arrayには一意なスカラー値(leaf-listの場合)またはオブジェクト(listの場合)のいずれかが含まれる。 ● The "null" value is only allowed in the single-element array "[null]" corresponding to the encoding of the "empty" type; see Section 6.9. “null”は”empty”のエンコードに対応する”[null]”で表される。 9
  • 10. Example: For the anydata definition anydata data; the following is a valid JSON-encoded instance: "data": { "ietf-notification:notification": { "eventTime": "2014-07-29T13:43:01Z", "example-event:event": { "event-class": "fault", "reporting-entity": { "card": "Ethernet0" }, "severity": "major" } } } 5.6. The "anyxml" Data Node An anyxml instance is encoded as a JSON name/value pair. The value MUST satisfy I-JSON constraints. anyxmlはname/valueにエンコードされる。ValueはI-JSON制約を満たすこと。 Example: For the anyxml definition anyxml bar; the following is a valid JSON-encoded instance: "bar": [true, null, true] 5.7. Metadata Objects Apart from instances of YANG data nodes, a JSON document MAY contain special object members whose name starts with the "@" character (COMMERCIAL AT). Such members are used for special purposes, such as encoding metadata [RFC7952]. The exact syntax and semantics of such members are outside the scope of this document. JSONには名前が”@”で始まるオブジェクトメンバーが含まれてよい。そのようなメンバーは、メタデータのエンコードのような目 的に使用される。そのようなメンバーの構文等はこのドキュメントのスコープ外である。 #​https://tools.ietf.org/html/rfc7952 6. Representing YANG Data Types in JSON Values The type of the JSON 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. 10
  • 11. leafまたはleaf-listのJSON valueタイプは、以降に規定されるようにデータノードタイプによって異なる。 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. "int8", "int16", "int32", "uint8", "uint16", or "uint32"はJSON numberで表される。 number = [ minus ] int [ frac ] [ exp ] decimal-point = %x2E ; . digit1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E exp = e [ minus / plus ] 1*DIGIT frac = decimal-point 1*DIGIT int = zero / ( digit1-9 *DIGIT ) minus = %x2D ; - plus = %x2B ; + zero = %x30 ; 0 A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. "int64", "uint64", or "decimal64"の値はRFC7950のsection 9.2.1、section 9.3.1のJSON Stringで表され る。 string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 11
  • 12. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as Section 5.1のleaf “foo”のタイプがuint8ではなく、uint64だった場合、次のようにエンコードする必要がある。 uint8 "foo": 123 uint64 "foo": "123" The special handling of 64-bit numbers follows from the I-JSON recommendation to encode numbers exceeding the IEEE 754-2008 double-precision range [IEEE754-2008] as strings; see Section 2.2 in [RFC7493]. 64bitの数値はI-JSONの推奨に従い、IEEE754-2008の倍精度範囲を超える数値を文字列としてエンコードするためである。 RFC 7493 Section 2.2参照。 6.2. The "string" Type A "string" value is represented as a JSON string, subject to JSON string encoding rules. “string”はJSON stringで表される。 6.3. The "boolean" Type A "boolean" value is represented as the corresponding JSON literal name "true" or "false". “boolean”はJSON literalの”true” or “false”で表される。 6.4. The "enumeration" Type An "enumeration" value is represented as a JSON string -- one of the names assigned by "enum" statements in YANG. “enumeration”はenum stmtの名前の一つがJSON stringとして表される。 The representation is identical to the lexical representation of the "enumeration" type in XML; see Section 9.6 in [RFC7950]. XMLの”enumeration”と同じである。 leaf myenum { type enumeration { enum zero; enum one; enum seven { value 7; } } } ・XML <myenum>seven</myenum> ・JSON "myenum": "seven" 12
  • 13. 6.5. The "bits" Type A "bits" value is represented as a JSON string -- a space-separated sequence of names of bits that are set. The permitted bit names are assigned by "bit" statements in YANG. “bits”はスペース区切りのビット名のシーケンスとして、JSON stringとして表される。ビット名はYANGのbit stmtで割り 当てられる。 The representation is identical to the lexical representation of the "bits" type; see Section 9.7 in [RFC7950]. XMLの”bits”と同じである。 typedef mybits-type { type bits { bit disable-nagle { position 0; } bit auto-sense-speed { position 1; } bit ten-mb-only { position 2; } } } leaf mybits { type mybits-type; default "auto-sense-speed"; } ・XML <mybits>disable-nagle ten-mb-only</mybits> ・JSON "mybits": "disable-nagle ten-mb-only" 6.6. The "binary" Type A "binary" value is represented as a JSON string -- base64 encoding of arbitrary binary data. “binary”はバイナリデータのbase64エンコードとしてJSON stringで表される。 The representation is identical to the lexical representation of the "binary" type in XML; see Section 9.8 in [RFC7950]. XMLの”binary”と同じである。 6.7. The "leafref" Type A "leafref" value is represented using the same rules as the type of the leaf to which the leafref value refers. “leafref”はleafrefが参照するleafのタイプと同じ規則で表される。 13
  • 14. 6.8. The "identityref" Type An "identityref" value is represented as a string -- the name of an identity. ​If the identity is defined in a module other than the leaf node containing the identityref value, the namespace-qualified form (Section 4) MUST be used.​ ​Otherwise, both the simple and namespace-qualified forms are permitted. “identityref”はidentityの名前としてstringで表される。identityが別モジュールで定義されている場合、 namespace-qualifiedを使用すること。それ以外の場合は、simpleとnamespace-qualifiedのどちらを使用してもよい。 For example, consider the following schematic module: module example-mod { ... import ietf-interfaces { prefix if; } ... leaf type { type identityref { base "if:interface-type"; ​#interface-typeはietf-interfacesモジュールで定義されている } } } A valid instance of the "type" leaf is then encoded as follows: "type": "iana-if-type:ethernetCsmacd" The namespace identifier "iana-if-type" must be present in this case because the "ethernetCsmacd" identity is not defined in the same module as the "type" leaf. この例ではnamespace “iana-if-type”が必要である。”ethernetCsmacd” identityが”type” leafと同じモジュール に存在しないため。 6.9. The "empty" Type An "empty" value is represented as "[null]", i.e., an array with the "null" literal being its only element. For the purposes of this document, "[null]" is considered an atomic scalar value. “empty”はnullリテラルを要素に持つ配列”[null]”として表される。本ドキュメントでは”[null]”はアトミックスカラー値 とみなす。 array = begin-array [ value *( value-separator value ) ] end-array value = false / null / true / object / array / number / string null = %x6e.75.6c.6c ; null value-separator = ws %x2C ws ; , comma begin-array = ws %x5B ws ; [ left square bracket 14
  • 15. end-array = ws %x5D ws ; ] right square bracket This encoding of the "empty" type was chosen instead of using simply "null" in order to facilitate the use of empty leafs in common programming languages where the "null" value of a member is treated as if the member is not present. メンバーに”null”があることを、メンバーが存在しないとして扱うプログラミング言語でempty leafの使用を容易にするた め、”null”を使用する代わりにこの”empty”のエンコードが採用された。 Example: For the leaf definition leaf foo { type empty; } a valid instance is "foo": [null] 6.10. The "union" Type A value of the "union" type is encoded as the value of any of the member types. “union”はメンバーのtypeのいずれかとしてエンコードされる。 When validating a value of the "union" type, the type information conveyed by the JSON encoding MUST also be taken into account. JSON syntax thus provides additional means for resolving the member type of the union that are not available in XML encoding. “union”の値を検証する場合、JSONエンコードのtype情報も考慮すること。JSONはXMLエンコードでは使用できなunionの typeを解決するための追加の手段を提供する。 For example, consider the following YANG definition: leaf bar { type union { type uint16; type string; } } In RESTCONF [RESTCONF], it is possible to set the value of "bar" in the following way when using the "application/yang.data+xml" media type: RESTCONFではmedia type ”application/yang.data+xml”を使用する場合、barの値を次のように設定できる。 <bar>13.5</bar> because the value may be interpreted as a string, i.e., the second member type of the union. When using the "application/yang.data+json" media type, however, this is an error: 15
  • 16. 値がunionの二番目のメンバーstringとして解釈される。しかし、media type “application/yang.data+json”を使用 すると下記はエラーになる。 "bar": 13.5 In this case, the JSON encoding indicates that the value is supposed to be a number rather than a string, and it is not a valid "uint16" value. JSONエンコードでは、値がstringではなく数値であることを想定しており、unit16ではない。 #13.5はstringではないのでnumberとして解釈される。13.5はuint16ではないのでエラー。 Conversely, the value of "bar": "1" is to be interpreted as a string. 6.11. The "instance-identifier" Type An "instance-identifier" value is encoded as a string that is analogical to the lexical representation in XML encoding; see Section 9.13.2 in [RFC7950]. However, the encoding of namespaces in instance-identifier values follows the rules stated in Section 4, namely: “instance-identifier”はXMLエンコードと同様のstringでエンコードされる。instance-identifierのnamespaceは Section 4の規則に従う。 ● The leftmost (top-level) data node name is always in the namespace-qualified form. 最上位のデータノード名はnamespace-qualifiedである。 ● Any subsequent data node name is in the namespace-qualified form if the node is defined in a module other than its parent node, and the simple form is used otherwise. This rule also holds for node names appearing in predicates. 以降のデータノード名は、そのノードが親ノード以外のモジュールで定義されている場合namespace-qualified、そ うでない場合はsimpleである。これはpredicateにも適用される。 For example, /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip #ietf-interfaces module : interfaces, interface, name #ietf-ip module : ipv4, ip is a valid instance-identifier value because the data nodes "interfaces", "interface", and "name" are defined in the module "ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". データノード"interfaces", "interface", and "name"は、モジュール"ietf-interfaces"で定義され、"ipv4" and "ip"はモジュール"ietf-ip"で定義される。 16
  • 17. 7. I-JSON Compliance I-JSON [RFC7493] is a restricted profile of JSON that guarantees maximum interoperability for protocols that use JSON in their messages, no matter what JSON encoders/decoders are used in protocol implementations. The encoding defined in this document therefore observes the I-JSON requirements and recommendations as closely as possible. I-JSONはJSONの制限付きプロファイルであり、実装に使用されているJSONエンコーダー/デコーダーに関係なく、JSONを使用 するプロトコルの相互運用性を保証する。本ドキュメントで定義されるエンコーディングはI-JSONの要件と推奨事項に準拠す る。 In particular, the following properties are guaranteed: 特に以下のプロパティが保証される。 ● Character encoding is UTF-8. UTF-8。 ● Member names within the same JSON object are always unique. JSONオブジェクト内のメンバー名は一意である。 ● The order of JSON object members is never relied upon. JSON objectのメンバーの順序に依存しない。 ● Numbers of any type supported by YANG can be exchanged reliably. See Section 6.1 for details. YANGがサポートする全てのタイプの数値を変換できる。 The JSON encoding defined in this document deviates from I-JSON only in the representation of the "binary" type. In order to remain compatible with XML encoding, the base64 encoding scheme is used (Section 6.6), whilst I-JSON recommends base64url instead. 本ドキュメントのJSONエンコードは、”binary”タイプの表現のみがI-JSONから逸脱している。XMLエンコードとの互換性を確 保するために、base64エンコードが使用されるが、I-JSONではbase64urlを使用する。 #base64url #​https://tools.ietf.org/html/rfc4648#section-5 8. Security Considerations This document defines an alternative encoding for data modeled in the YANG data modeling language. As such, it doesn't contribute any new security issues beyond those discussed in Section 17 of [RFC7950]. 本ドキュメントではYANGでモデリングされたデータのエンコード方法を定義する。そのため、RFC 7950 Section 17. Security Considerations以外の問題は発生しない。 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 [RFC6241] or RESTCONF [RESTCONF]. If this is not the case, external mechanisms, such as Public-Key Cryptography Standards (PKCS) #7 [RFC2315] or ​JSON Object Signing and Encryption (JOSE) [RFC7515] [RFC7516]​, need to be considered. 本ドキュメントでは、YANGでモデリングされたデータの署名と暗号化のメカニズムを定義していない。通常の状況では、データの セキュリティと整合性はNETCONFやRESTCONFなどの管理プロトコルによって保証される。そうでない場合、PKCSやJOSEなどの メカニズムの検討が必要である。 17
  • 18. JSON processing is rather different from XML, and JSON parsers may thus suffer from different types of vulnerabilities than their XML 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. JSONの処理はXMLとかなり異なるため、JSONパーサーはXMLパーサーと異なる種類の脆弱性の影響を受ける可能性がある。これ らのセキュリティリスクを最小限に抑えるため、受信側のソフトウェアは本ドキュメントに準拠しないメッセージを拒否し、送信 者に適切なエラーメッセージを送信することが推奨される。 Appendix A. A Complete Example The JSON document shown below represents the same data as the reply to the NETCONF <get> request appearing in Appendix D of [RFC7223]. The data model is a combination of two YANG modules: "ietf-interfaces" and "ex-vlan" (the latter is an example module from Appendix C of [RFC7223]). The "if-mib" feature defined in the "ietf-interfaces" module is supported. 以下のJSONはRFC7223(A YANG Data Model for Interface Management) Appendix Dと同じデータを表している。 { ​#オブジェクトから始まる #container interfaces : name/object #namespace-qualified : 最上位オブジェクト "ietf-interfaces:interfaces": { #list interface : name/array "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", "enabled": false }, { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", "enabled": true, "ex-vlan:vlan-tagging": true }, { "name": "eth1.10", "type": "iana-if-type:l2vlan", "enabled": true, "ex-vlan:base-interface": "eth1", #親と異なるモジュールのためnamespace-qualified "ex-vlan:vlan-id": 10 }, { "name": "lo1", "type": "iana-if-type:softwareLoopback", "enabled": true } ] }, #container interfaces-state : name/object #namespace-qualified : 最上位オブジェクト "ietf-interfaces:interfaces-state": { "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", #leaf admin-status(type enumeration) :up,down,testing "admin-status": "down", <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:vlan="http://example.com/vlan"> <interface> <name>eth0</name> <type>ianaift:ethernetCsmacd</type> <enabled>false</enabled> </interface> <interface> <name>eth1</name> <type>ianaift:ethernetCsmacd</type> <enabled>true</enabled> <vlan:vlan-tagging>true</vlan:vlan-tagging> </interface> <interface> <name>eth1.10</name> <type>ianaift:l2vlan</type> <enabled>true</enabled> <vlan:base-interface>eth1</vlan:base-interface> <vlan:vlan-id>10</vlan:vlan-id> </interface> <interface> <name>lo1</name> <type>ianaift:softwareLoopback</type> <enabled>true</enabled> </interface> </interfaces> <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" > <interface> <name>eth0</name> <type>ianaift:ethernetCsmacd</type> 18
  • 19. "oper-status": "down", "if-index": 2, "phys-address": "00:01:02:03:04:05", "statistics": { "discontinuity-time": "2013-04-01T03:00:00+00:00" } }, { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", "admin-status": "up", "oper-status": "up", "if-index": 7, "phys-address": "00:01:02:03:04:06", #leaf-list higher-layer-if(type interface-state-ref) #typedef interface-state-ref { # type leafref { # path "/if:interfaces-state/if:interface/if:name"; # } "higher-layer-if": [ "eth1.10" ], "statistics": { "discontinuity-time": "2013-04-01T03:00:00+00:00" } }, { "name": "eth1.10", "type": "iana-if-type:l2vlan", "admin-status": "up", "oper-status": "up", "if-index": 9, "lower-layer-if": [ "eth1" ], "statistics": { "discontinuity-time": "2013-04-01T03:00:00+00:00" } }, { "name": "eth2", "type": "iana-if-type:ethernetCsmacd", "admin-status": "down", "oper-status": "down", "if-index": 8, "phys-address": "00:01:02:03:04:07", "statistics": { "discontinuity-time": "2013-04-01T03:00:00+00:00" } }, { "name": "lo1", "type": "iana-if-type:softwareLoopback", "admin-status": "up", "oper-status": "up", "if-index": 1, "statistics": { "discontinuity-time": "2013-04-01T03:00:00+00:00" } } <admin-status>down</admin-status> <oper-status>down</oper-status> <if-index>2</if-index> <phys-address>00:01:02:03:04:05</phys-address> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> </interface> <interface> <name>eth1</name> <type>ianaift:ethernetCsmacd</type> <admin-status>up</admin-status> <oper-status>up</oper-status> <if-index>7</if-index> <phys-address>00:01:02:03:04:06</phys-address> <higher-layer-if>eth1.10</higher-layer-if> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> </interface> <interface> <name>eth1.10</name> <type>ianaift:l2vlan</type> <admin-status>up</admin-status> <oper-status>up</oper-status> <if-index>9</if-index> <lower-layer-if>eth1</lower-layer-if> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> </interface> <!-- This interface is not configured --> <interface> <name>eth2</name> <type>ianaift:ethernetCsmacd</type> <admin-status>down</admin-status> <oper-status>down</oper-status> <if-index>8</if-index> <phys-address>00:01:02:03:04:07</phys-address> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> </interface> <interface> <name>lo1</name> <type>ianaift:softwareLoopback</type> <admin-status>up</admin-status> <oper-status>up</oper-status> <if-index>1</if-index> 19