diff --git a/.github/workflows/gen_index_html.sh b/.github/workflows/gen_index_html.sh index 4e4c988..ba15f5c 100644 --- a/.github/workflows/gen_index_html.sh +++ b/.github/workflows/gen_index_html.sh @@ -60,7 +60,7 @@ for branch in $SORTED; do echo "
html / text / xml
" >> index.html if [ $branch = "main" ]; then - echo " Diff with RFC7950 " >> index.html + echo " Diff with RFC7950
Diff with Datatracker " >> index.html else echo " Diff with Main " >> index.html fi diff --git a/.github/workflows/pull_request_updated.yml b/.github/workflows/pull_request_updated.yml index 7bd00f3..52dc1af 100644 --- a/.github/workflows/pull_request_updated.yml +++ b/.github/workflows/pull_request_updated.yml @@ -6,6 +6,7 @@ on: jobs: add_checklist: + name: Add Checklist runs-on: ubuntu-latest if: github.event.action == 'opened' steps: @@ -86,7 +87,7 @@ jobs: } - name: Test summary line for changes run: | - echo "${{env.SUMMARY_LINE}}" | grep -qF "0 flaws (~~), 3 warnings (==), 7 comments (--)" || { + echo "${{env.SUMMARY_LINE}}" | grep -qF "0 flaws (~~), 3 warnings (==), 6 comments (--)" || { echo "::error::Idnits summary line different - examine why (fix workflow if needed)" exit 1 } @@ -124,10 +125,28 @@ jobs: # fi # + ensure_checklist_complete: + name: Ensure Checklist Complete + runs-on: ubuntu-latest + steps: + - name: Ensure Checklist Complete + uses: peter-evans/find-comment@v4 + id: fc + with: + issue-number: ${{github.event.number}} + comment-author: 'github-actions[bot]' + body-includes: 'All of the following must be verified before merging to `main`.' + - run: | + if ${{ contains(steps.fc.outputs.comment-body, '[ ] Updated') }} ; then + echo "All checklist items must be selected." + exit 1 + fi + + update_github_pages: name: Update the GitHub Page runs-on: ubuntu-latest - needs: [xml2rfc, idnits_v2] + needs: xml2rfc permissions: pages: write id-token: write diff --git a/draft-yn-netmod-yang2.xml b/draft-yn-netmod-yang2.xml index d60a901..a888644 100644 --- a/draft-yn-netmod-yang2.xml +++ b/draft-yn-netmod-yang2.xml @@ -13,7 +13,7 @@ - + The YANG 2.0 Data Modeling Language @@ -64,9 +64,8 @@ configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF Remote Procedure Calls, and NETCONF notifications . Since the publication of YANG version 1 , YANG has been used or proposed to be -used for other protocols (e.g., RESTCONF and -the Constrained Application Protocol (CoAP) Management Interface (CoMI) -). Further, encodings other than XML have been +used for other protocols (e.g., RESTCONF and +CORECONF ). Further, encodings other than XML have been proposed (e.g., JSON ). @@ -78,7 +77,7 @@ the data. Other protocols and encodings are possible but are out of scope for this specification. -In terms of developing YANG data models, +In terms of developing YANG data models, provides some guidelines and recommendations. @@ -312,7 +311,7 @@ The following changes have been done to the NETCONF mapping:
  • A server advertises support for YANG 1.1 modules by using -ietf‑yang-library instead of listing +ietf‑yang-library instead of listing them as capabilities in the <hello> message.
    • @@ -321,12 +320,11 @@ them as capabilities in the <hello> message.
    Key Words - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and -"OPTIONAL" in this document are to be interpreted as described in -BCP 14 . - + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described + in BCP 14 + when, and only when, they appear in all capitals, as shown here.
    Terminology @@ -1723,7 +1721,7 @@ unique URI . A NETCONF client or serve during XML encoding of data. -XML namespaces for modules published in RFC streams +XML namespaces for modules published in RFC streams MUST be assigned by IANA; see Section 14 in . @@ -1923,7 +1921,7 @@ specifications. A NETCONF server MUST announce the modules it implements (see ) by implementing the YANG module "ietf‑yang‑library" defined in - and listing all implemented modules in + and listing all implemented modules in the "/modules‑state/module" list. @@ -1972,7 +1970,7 @@ If a server implements a module A that imports a module C without specifying the revision date of module C and the server does not implement C (e.g., if C only defines some typedefs), the server MUST list module C in the "/modules‑state/module" list from -"ietf‑yang‑library" , and it MUST set +"ietf‑yang‑library" , and it MUST set the leaf "conformance‑type" to "import" for this module. @@ -2787,7 +2785,7 @@ substatements that holds detailed module information. The module name is an identifier (see ). -Names of modules published in RFC streams +Names of modules published in RFC streams MUST be assigned by IANA; see Section 14 in . @@ -3286,7 +3284,7 @@ chronological order.
    Usage Example - The following example relies on . + The following example relies on . ). -Names of submodules published in RFC streams MUST be +Names of submodules published in RFC streams MUST be assigned by IANA; see Section 14 in . @@ -13371,128 +13369,17 @@ compromised. References Normative References - - - Key words for use in RFCs to Indicate Requirement Levels - - - - In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. - - - - - - - - - UTF-8, a transformation format of ISO 10646 - - - - ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. - - - - - - - - - Uniform Resource Identifier (URI): Generic Syntax - - - - - - A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] - - - - - - - - - The Base16, Base32, and Base64 Data Encodings - - - - This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] - - - - - - - - Augmented BNF for Syntax Specifications: ABNF - - - - - Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] - - - - - - - - - NETCONF Event Notifications - - - - - This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK] - - - - - - - - Network Configuration Protocol (NETCONF) - - - - - - - The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] - - - - - - - - Case-Sensitive String Support in ABNF - - - - This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. - - - - - - - - - YANG Module Library - - - - - - This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. - - - - - + + + + + + + + + + + Extensible Markup Language (XML) 1.0 (Fifth Edition) @@ -13505,6 +13392,7 @@ compromised. + Namespaces in XML 1.0 (Third Edition) @@ -13527,6 +13415,7 @@ compromised. + XML Schema Part 2: Datatypes Second Edition @@ -13540,6 +13429,7 @@ compromised. + XML Path Language (XPath) Version 1.0 @@ -13553,6 +13443,7 @@ compromised. + Information Technology - Universal Multiple-Octet Coded Character Set (UCS) @@ -13564,8 +13455,10 @@ compromised. + Informative References + IEEE Standard for Floating-Point Arithmetic @@ -13577,154 +13470,19 @@ compromised. - - - Structure of Management Information Version 2 (SMIv2) - - - - - - It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] - - - - - - - - - Textual Conventions for SMIv2 - - - - - - It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] - - - - - - - - - SMIng - Next Generation Structure of Management Information - - - - - This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community. - - - - - - - - The RFC Series and RFC Editor - - - Internet Architecture Board - - - - This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community. - - - - - - - - YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) - - - - YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] - - - - - - - - Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules - - - - YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK] - - - - - - - - Common YANG Data Types - - - - This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. - - - - - - - - - JSON Encoding of Data Modeled with YANG - - - - - - - - - - - - Guidelines for Authors and Reviewers of YANG Data Model Documents - - - - - - - - - - - RESTCONF Protocol - - - - - - - - - - - - - - - - - CoAP Management Interface - - - - - - - - - - + + + + + + + + + + + + + XSL Transformations (XSLT) Version 1.0 @@ -13735,6 +13493,7 @@ compromised. + XML Path Language (XPath) 2.0 (Second Edition) @@ -13763,6 +13522,7 @@ compromised. +