Operations and Management Area Working Group (opsawg) Internet Drafts


      
 Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices
 
 draft-ietf-opsawg-mud-tls-14.txt
 Date: 17/03/2024
 Authors: Tirumaleswar Reddy.K, Dan Wing, Blake Anderson
 Working Group: Operations and Management Area Working Group (opsawg)
This memo extends the Manufacturer Usage Description (MUD) specification to incorporate (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint.
 Authorized update to MUD URLs
 
 draft-ietf-opsawg-mud-acceptable-urls-11.txt
 Date: 01/03/2024
 Authors: Michael Richardson, Wei Pan, Eliot Lear
 Working Group: Operations and Management Area Working Group (opsawg)
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls
 Operational Considerations for Use of DNS in IoT Devices
 
 draft-ietf-opsawg-mud-iot-dns-considerations-13.txt
 Date: 24/03/2024
 Authors: Michael Richardson, Wei Pan
 Working Group: Operations and Management Area Working Group (opsawg)
This document details concerns about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying RFC 8520 Manufacturer Usage Description (MUD) definitions to control device access. Alos, this document makes recommendations on when and how to use DNS names in MUD files.
 Ownership and licensing statements in YANG
 
 draft-ietf-opsawg-ol-05.txt
 Date: 18/04/2024
 Authors: Eliot Lear, Carsten Bormann
 Working Group: Operations and Management Area Working Group (opsawg)
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.
 TACACS+ TLS 1.3
 
 draft-ietf-opsawg-tacacs-tls13-07.txt
 Date: 23/04/2024
 Authors: Thorsten Dahm, John Heasley, dcmgash@cisco.com, Andrej Ota
 Working Group: Operations and Management Area Working Group (opsawg)
The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC RFC8907.
 Export of On-Path Delay in IPFIX
 
 draft-ietf-opsawg-ipfix-on-path-telemetry-06.txt
 Date: 14/01/2024
 Authors: Thomas Graf, Benoit Claise, Alex Feng
 Working Group: Operations and Management Area Working Group (opsawg)
This document introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay on the IOAM transit and decapsulation nodes.
 Link-Layer Types for PCAP and PCAPNG Capture File Formats
 
 draft-ietf-opsawg-pcaplinktype-02.txt
 Date: 30/01/2024
 Authors: Guy Harris, Michael Richardson
 Working Group: Operations and Management Area Working Group (opsawg)
This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap.
 A Data Manifest for Contextualized Telemetry Data
 
 draft-ietf-opsawg-collected-data-manifest-03.txt
 Date: 04/03/2024
 Authors: Benoit Claise, Jean Quilbeuf, Diego Lopez, Ignacio Martinez-Casanueva, Thomas Graf
 Working Group: Operations and Management Area Working Group (opsawg)
Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists.
 Export of UDP Options Information in IP Flow Information Export (IPFIX)
 
 draft-ietf-opsawg-tsvwg-udp-ipfix-07.txt
 Date: 23/01/2024
 Authors: Mohamed Boucadair, Tirumaleswar Reddy.K
 Working Group: Operations and Management Area Working Group (opsawg)
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix.
 Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements
 
 draft-ietf-opsawg-ipfix-tcpo-v6eh-11.txt
 Date: 15/04/2024
 Authors: Mohamed Boucadair, Benoit Claise
 Working Group: Operations and Management Area Working Group (opsawg)
This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options.
 Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry
 
 draft-ietf-opsawg-ipfix-fixes-08.txt
 Date: 17/04/2024
 Authors: Mohamed Boucadair, Benoit Claise
 Working Group: Operations and Management Area Working Group (opsawg)
This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry.
 Finding and Using Geofeed Data
 
 draft-ietf-opsawg-9092-update-11.txt
 Date: 22/02/2024
 Authors: Randy Bush, Massimo Candela, Warren Kumari, Russ Housley
 Working Group: Operations and Management Area Working Group (opsawg)
This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed data files. This document obsoletes RFC 9092.
 A YANG Data Model and RADIUS Extension for Policy-based Network Access Control
 
 draft-ietf-opsawg-ucl-acl-03.txt
 Date: 02/02/2024
 Authors: Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King
 Working Group: Operations and Management Area Working Group (opsawg)
This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a RADIUS attribute that is used to communicate the user group identifier as part of identification and authorization information.
 A Common YANG Data Model for Attachment Circuits
 
 draft-ietf-opsawg-teas-common-ac-10.txt
 Date: 19/04/2024
 Authors: Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu
 Working Group: Operations and Management Area Working Group (opsawg)
The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc.
 YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)
 
 draft-ietf-opsawg-teas-attachment-circuit-11.txt
 Date: 19/04/2024
 Authors: Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu
 Working Group: Operations and Management Area Working Group (opsawg)
This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features.
 A Network YANG Data Model for Attachment Circuits
 
 draft-ietf-opsawg-ntw-attachment-circuit-09.txt
 Date: 19/04/2024
 Authors: Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu
 Working Group: Operations and Management Area Working Group (opsawg)
This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in I-D.ietf-opsawg-teas- attachment-circuit. The module augments the 'ietf-network' and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs).
 A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits
 
 draft-ietf-opsawg-ac-lxsm-lxnm-glue-09.txt
 Date: 11/04/2024
 Authors: Mohamed Boucadair, Richard Roberts, Samier Barguil, Oscar de Dios
 Working Group: Operations and Management Area Working Group (opsawg)
The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network ((i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM))) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to ACs that are created using the Attachment Circuit (AC) service ("ietf-ac- svc") and network ("ietf-ac-ntw") models.
 An Information Model for Packet Discard Reporting
 
 draft-ietf-opsawg-discardmodel-00.txt
 Date: 05/02/2024
 Authors: John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh
 Working Group: Operations and Management Area Working Group (opsawg)
The primary function of a network is to transport packets and deliver them according to a service level objective. Understanding both where and why packet loss occurs within a network is essential for effective network operation. Router-reported packet loss is the most direct signal for network operations to identify customer impact resulting from unintended packet loss. This document defines an information model for packet loss reporting, which classifies these signals to enable automated network mitigation of unintended packet loss.


data-group-menu-data-url="/group/groupmenu.json"> Skip to main content

Operations and Management Area Working Group (opsawg)

WG Name Operations and Management Area Working Group
Acronym opsawg
Area Operations and Management Area (ops)
State Active
Charter charter-ietf-opsawg-04-00 Draft Charter
Document dependencies
Additional resources GitHub organization
Issue tracker
Wiki
Zulip stream
Personnel Chairs Henk Birkholz, Joe Clarke
Area Director Mahesh Jethanandani
Mailing list Address opsawg@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/opsawg
Archive https://mailarchive.ietf.org/arch/browse/opsawg/
Chat Room address https://zulip.ietf.org/#narrow/stream/opsawg

Charter for Working Group

The Operations and Management Area receives occasional proposals for
the development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group
and do not justify the formation of a new working group. The OPSAWG
will serve as the forum for developing such work items in the IETF.

The OPSAWG mailing list is an open discussion forum for such work
items, when they arise. The working group meets if there are active
proposals that require discussion. The working group milestones are
updated as needed to reflect the current work items and their
associated milestones. All new work items and rechartering proposals
will be brought for approval with the IESG.

The focus of the work will be on topics that govern the behavior or WGs
in the O&M area (e.g., manageability requirements) and on small,
highly focused projects that don't merit a WG of their own or belong
to WGs that have already concluded (e.g. advancement of documents on
the standards track, application statements, extensions of MIB
modules).

The OPSAWG will undertake only work items that are proved to have at
least a reasonable level of interest from the operators and users
community and have a committed number of editors and reviewers. It is
not within the scope of the OPSAWG to pick up failed WG work or parts
of a WG charter items that could not come to convergence on what they
were chartered to do.

The currently active OPSAWG work items mostly fall under the following
topics:

(A) Templates and tools for Operations and Management Area Documents

(B) Maintenance and small scale extensions of documents that were
developed in working groups that have concluded (e.g. MIB modules).

(C) The RFC 5066 "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" has
transitioned to the IEEE 802.3. However, as agreed with the IEEE, the IF-CAP-
STACK-MIB MIB module (from RFC5066) is generic by nature and should continue
to be supported by the IETF. The WG will develop a document extracting the
IF-CAP-STACK-MIB from RFC5066, emphasizing the generic nature of this module,
and obsolete RFC5066.

(D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011.
Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE
802.1 WG" as an reference, the following pieces of information would the
foundation for the document: a table mapping the old IETF MIB names with the
corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions
(mailing lists, reviews), and clarifications on the intellectual property considerations.

Milestones

Date Milestone Associated documents
Mar 2013 Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational
Oct 2012 Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft

Done milestones

Date Milestone Associated documents
Done Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard
Done Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft
Done Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard
Done WGLC for the 'Structured Data Elements (SDEs) for syslog'
Done Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP
Done WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft
Done Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard
Done Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft
Done Initial submission for the 'Template for Generic Management Data Models' Internet-Draft
Done Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft
Done WGLC for the 'SNMP Engine ID Discovery' Internet-Draft
Done Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft