]> Sandelman Software Works

mcr+ietf@sandelman.ca

Internet NETMOD Working Group Internet-Draft This document describes a mechanism of signaling extensions to YANG modules that can be used when YANG is not used in an online fashion. About This Document Status information for this document may be found at . Discussion of this document takes place on the cbor Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In the process of revising to accomodate needed extensions an effort was initially made to do this using augment (cite) and later augment-structure. is a digitally signed voucher format used in onboarding of new devices. It is a file format that may be transmitted over CoAP, HTTP or via USB key, but it does not use RESTCONF. The contents of the file are not subject to negotiation as might be done with . Rather than have each topic document define the relevant extensions needed, it turned out to be necessary to collect all the extensions necessary into a single revision to the YANG module, which is being produced as . is like : it is a file format. When was defined, it anticipated that there would be future extensions, and defined a YANG leaf called "extensions" which is a list of subsequent YANG modules which are included. This is being used to define, for instance, . When YANG is serialized to XML or JSON, the keys used in the attribute map are strings, and so it seems relatively straightforward for a human programmer to understand how to insert these new keys into the same attribute map. YANG however, is intended to be machine parseable, and provides a way to serialize YANG to CBOR. While strings can be used if necessary, the preferred method is via YANG-SID values, allocated for instance, via . It is not obvious how an extension mechanism as described by can be efficiently encoded to CBOR, nor how YANG tooling should react to these ad-hoc extensions. This document makes the extension mechanism a generic mechanism that can be used by any YANG module, and explains how to efficiently encode this to CBOR using YANG-SID.

Terminology 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.

Motivation XXX - Do we need more details about the motivation?

Protocol

Extensions A YANG module that expects to have extensions establishes an attribute called "extensions" This attribute value is a list of extensions that are included in this object. This set of available values is established as an IANA registry by the document defining the module. (XXX- this assumes per-module extensions, vs a global set of extensions that could be used by many modules) When encoding YANG as CBOR, in order to encode the additional attributes defined by that extension, a new sub-map is created. The key for this sub-map, in the parent map, consists of the YANG module SID, encoded using the CBOR Tag 47, the tag for an absolute SID. Within the sub-map, the normal delta-encoding is used, using the SID values allocated for that module. (XXX- the submap should allow to XML and JSON too?)

Privacy Considerations YYY

Security Considerations ZZZ

IANA Considerations

Acknowledgements Hello.

Changelog

References Normative References YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items. SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228). This document defines the semantics, registration processes, and assignment processes for YANG SIDs for IETF-managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module. Watsen Networks Sandelman Software Cisco Systems Futurewei Technologies Inc. Huawei This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. Cisco Systems Universität Bremen TZI This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such.