Networking

The present document specifies technical characteristics and methods of measurements for maritime mobile broadband radiocommunication systems (MBR) radio equipment intended to operate in the 5,8 GHz band.

The present document applies to systems utilizing integral electronically phase steered antennae applicable for communications between vessels and between vessels and platforms engaged in coordinated off-shore activities.

This amendment to IEEE Std 802.3-2018 specifies additions and appropriate modifications to add 10 Mb/s Physical Layer (PHY) specifications and management parameters for operation, and associated optional provision of power, over a single balanced pair of conductors.

The 3rd Generation Partnership Project (3GPP) is the primary body for developing technology specifications for cellular networks. It self-organises through its Working Groups coordinated by the Chairs of the Technical Specifications Groups (TSGs)

CT WG4 - MAP/CAMEL/GTP/BCH/SS (TSG Core Network and Terminals WG4) standardises stage 2 and stage 3 aspects within the Core Network focusing on:

• Supplementary Services.
• Basic Call Processing.
• Mobility Management within the Core Network.
• Bearer Independent Architecture.
• GPRS between network entities.
• Transcoder Free Operation.
• CAMEL.
• Generic User Profile.
• Wireless LAN - UMTS interworking and descriptions of IP Multimedia Subsystem.

CT WG4 is also responsible as a "protocol steward" for the some IP related protocols (this involves analysing, validating, extending if necessary, clarifying how they are used, specifying packages and parameter values).

This document provides a standardized IoT Reference Architecture using a common vocabulary, reusable designs and industry best practices. It uses a top down approach, beginning with collecting the most important characteristics of IoT, abstracting those into a generic IoT Conceptual Model, deriving a high level system based reference with subsequent dissection of that model into the four architecture views (functional view, system view, networking view and usage view) from different perspectives.

The mission of the Distributed Tracing is to define standards for interoperability between tracing tools.
Modern cloud-native applications are highly distributed and often span multiple technology and vendor boundaries. The complexity of these applications requires a detailed understanding of how individual requests are executed. This is referred to as "tracing".
Tracing tools for collecting this information have been available for quite some time. However, these tools have not been built with interoperability in mind. This leaves the developer with a number of challenges in getting an end-to-end trace of complex transactions:

• Traces are often broken, because trace context information is lost in a contributing tier or the trace is restarted
• Vendors cannot pass proprietary information across tiers instrumented with a different implementation and therefore lose relevant information (e.g. step count, server information, ...)
• End users don't have the ability to create complete end-to-end traces of application transactions which are monitored by different tools, as there is no defined data format and semantics for trace data

The scope of this working group is the definition of data formats and headers enabling the propagation and correlation of tracing data across different implementations.

The mission of the Decentralized Identifier Working Group is to standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.
 
The design approach for the DID specification is the same as the URI specification (RFC 3986). RFC 3986 defines the generic syntax for URIs, and all URI schemes are separate specifications. In fact, the DID specification is a conformant URI scheme. The goal of the DID specification is to do exactly the same for DIDs, that is, for this Working Group to define the generic DID specification, and then for others to define DID Method specifications.
 
The Working Group will:

1. Define the DID URI scheme.
2. Recommend a data model and syntax(es) for the expression of Decentralized Identifier Documents, including one or more core vocabularies.
3. Recommend a set of requirements for DID Method specifications that are conformant with the data model and syntax(es). The DID Method specification authoring requirements will recommend a list of mandatory and optional operations, with associated descriptions, which are expected to be defined in DID method specifications.
4. Provide a rubric of decentralized characteristics for DID Method specifications. This allows the DID Method specifications to self-certify, or independent third parties to evaluate, the DID Method specification's level of adherence to principles of decentralization.
5. Concentrate their efforts on the initial use cases with a particular focus on enabling future specification and implementation of Identity and Access Management. Use cases from other industries may be included if there is significant industry participation.
6. Define extension points enabling authentication, signing and cryptography mechanisms, but not defining specific authentication, signing, or cryptography mechanisms. (See "Out of Scope".)
7. With the initial use cases document as input, the WG will produce a NOTE at the end of the process that is a refined Use Cases document.
8. Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.

The Swordfish Scalable Storage Management API ("Swordfish") uses RESTful interface semantics and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services.

The Storage Management Initiative Technical Work Group (SMI TWG) is responsible for the maintenance and evolution of the SNIA Storage Management Initiative Specification (SMI-S). SMI-S defines an interface for the interoperable management of a heterogeneous Storage Area Network (SAN). It describes the information available to a WBEM Client from an SMI-S compliant CIM Server via an object-oriented, XML-based, messaging-based interface designed to support the specific requirements of managing devices in and through SANs.

The SNIA SFF Technology Affiliate (TA) Technical Work Group (TWG)  work items include the development of technical specifications as SNIA Architecture for storage media, storage networks, and pluggable solutions that complement existing industry standards work that encompass cables, connectors, form factor sizes and housing dimensions, management interfaces, transceiver interfaces, electrical interfaces, and related technologies.  The specifications enable technology vendors to procure compatible, multi-sourced products and solutions

The Security TWG provides architectures and frameworks for the establishment of information security capabilities within the storage networking industry, including that of stored information in heterogeneous environments. The focus of the Security Work Group is directed toward long-term security solutions, taking into account any security inherent in underlying transports or technologies.

The Object Drive TWG was created for the purpose of establishing architectures and standards for disk, solid state and tape drive based functionalities that allow them to be higher level storage nodes in emerging scale out solutions. The TWG creates specifications that enable scale out storage systems to add and remove these nodes incrementally and seamlessly. These specifications are vendor agnostic and support existing and future functionality in drive form factors.
The Object Drive TWG:
 
    Acts as the primary technical entity for the SNIA to identify, develop, and coordinate standards for Object Drives operating as storage nodes in scale out storage solutions.
    Produces a comprehensive set of specifications related to data and control path interfaces and protocols.
    Promotes interoperability among Object Drive software hosting environments