IT in general

The initial focus of this Working Group was the development of mechanisms that provide confidentiality and authentication between DNS Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With proposed standard solutions for the client-to-iterative resolvers published, the working group turns its attention to the development of documents focused on: 1) providing confidentiality to DNS transactions between Iterative Resolvers and Authoritative Servers, 2) measuring the efficacy in preserving privacy in the face pervasive monitoring attacks, and 3) defining operational, policy, and security considerations for DNS operators offering DNS privacy services. Some of the results of this working group may be experimental.There are numerous aspects that differ between DNS exchanges with an iterative resolver and exchanges involving DNS root/authoritative servers. The working group will work with
DNS operators and developers (via the DNSOP WG) to ensure that proposed solutions address key requirements.

The present document specifies a data model for NFV descriptors, using the TOSCA Simple Profile in YAML, fulfilling the requirements specified in ETSI GS NFV-IFA 011 and ETSI GS NFV-IFA 014 for a Virtualised Network Function Descriptor (VNFD), a Network Service Descriptor (NSD) and a Physical Network Function Descriptor (PNFD). The present document also specifies requirements on the VNFM and NFVO specific to the handling of NFV descriptors based on the TOSCA Simple Profile in YAML specification.

The standard establishes a process model by which engineers and technologists can address ethical consideration throughout the various stages of system initiation, analysis and design. Expected process requirements include management and engineering view of new IT product development, computer ethics and IT system design, value-sensitive design, and, stakeholder involvement in ethical IT system design.

This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.

As more and more protocols need to be compressed, the encoding capabilities of the original dispatch defined in the 6LowPAN adaptation-layer framework ([RFC4944] and [RFC6282]) becomes saturated. This specification introduces a new context switch mechanism for 6LoWPAN compression, expressed in terms of Pages and signaled by a new Paging Dispatch mechanism.

LoWPAN encapsulation as defined in RFC 4944 has been updated by [RFC6282], and may be extended and modified by future IETF Standards. The intended Layer 2 technology for IPv6 datagrams using LoWPAN encapsulation as originally defined is [IEEE.802.15.4_2011], which does not provide for a protocol switch in its Layer 2 headers.

The low- power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

The document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944].

The document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.

RFC 6282 modifies the value of the ESC dispatch type and that value is recorded in IANA registry [IANA-6LoWPAN]. However, the octets and usage following the ESC dispatch type are not defined in either [RFC4944] or [RFC6282]. In recent years with 6LoWPAN deployments, implementations and standards organizations have started using the ESC extension octets. This highlights the need for an updated IANA registration policy.

This document defines the new "ESC Extension Types" registry and the ESC extension octets for future applications. In addition, this document records the ITU-T specification for ESC dispatch octet code points as an existing known usage.