asdf avtcore asap httpapi calext cellar cbor core cdni dispatch dmarc dkim extra ecrit httpbis jmap jsonpath moq mediaman mimi mmusic rtcweb regext rum uuidrev emailcore satp sframe stir sedate sipcore scim tigress uta wish webtrans gendispatch elegy shmoo add dmm dprive drip dhc dnssd intarea 6man lpwan 6lo 6tisch lwig madinas ntp schc snac tictoc anima bmwg dime dnsop grow iotops v6ops mboned mops netconf netmod opsec opsawg sidrops babel bess bfd bier ccamp cats detnet idr lsr lsvr lisp manet mpls nvo3 pce pim pals raw rtgwg rift roll sfc savnet spring tvr teas ace acme cose kitten dance emu gnap i2nsf ipsecme jose lake lamps mls ohai openpgp pquip privacypass ppm radext rats secdispatch secevent suit scitt tls teep oauth alto dtn ippm masque nfsv4 quic rmcat tcpm tsvwg taps A Semantic Definition Format for Data and Interactions of Things (asdf) ----------------------------------------------------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Michael Richardson Niklas Widell Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: asdf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/asdf Archive: https://mailarchive.ietf.org/arch/browse/asdf/ Description of Working Group: ## Background Data and interaction models of IoT devices today exhibit unneeded diversity between different industry ecosystem standards development organizations (SDOs), hindering interoperability across these ecosystems with little discernible benefit from the diversity. Early 2019, One Data Model (OneDM) was started to bring several IoT SDOs and IoT device and platform vendors together under a broad, multi-party liaison agreement, with a goal of arriving at a common set of data and interaction models that describe IoT devices. Ideally, for every class of IoT device, there is just a single model selected/created by the participating organizations, which everyone can adopt. As a common language for writing down these models, the Semantic Definition Format (SDF, draft-onedm-t2trg-sdf) was created, which can represent IoT Things, their composition from reusable Objects, their Interaction Affordances (Properties, Actions, Events), and the data models relevant to describe these Affordances. SDF represents these models in JSON, enabling re-use of specification formats such as CDDL (RFC8610) and the formats proposed at json-schema.org and their tooling, for describing both the SDF format itself and the structure of the data to be modelled in SDF. By July 2020, some 200 models in SDF format have been contributed by participating ecosystems; new models are being submitted continually. Version 1.0 of the SDF specification was published on the OneDM github repository and as an Internet-Draft. OneDM is now focusing on consolidating the body of submitted models and developing processes for arriving at harmonized models that span different industry ecosystems in a common way; as expressed at the IETF 108 ASDF BoF, they look to the IETF for developing SDF 1.0 further into a high-quality specification. The IETF also defines the YANG data modelling language (RFC 7950). YANG has a strong focus on modelling the management interface for network devices, using a fairly small set of network management protocols, whereas SDF is designed to span (and transitively unify) many existing interaction models already present. While data associated with a YANG schema can be serialized to a variety of wire formats (e.g., XML, JSON, CBOR, and others), the serialization is driven directly by the structure of the data models defined in YANG; there is no separate "protocol binding" step as in the use of SDF. Conversely, SDF does not deal directly with serialization at all, modelling only the structure and semantics of the data being interchanged, hence leaving data serialization (and RPC semantics) to other standards, most likely defined by existing IoT SDOs. ## The ASDF Working Group The objective of the ASDF working group is to develop SDF into a standards-track specification for thing interaction and data modelling. In the process of developing this specification, further functional requirements that emerge in the usage of SDF for model harmonization will be addressed. The ASDF WG will work with experts from OneDM and its contributing organizations. In the IETF, it will work closely with the CBOR WG, home of the CDDL specification. It will also engage the still active mailing list of the concluded JSON WG. Recent proposals to form an IRTF formal description techniques (FDT) Research Group might lead to another collaboration partner. ASDF will work with Thing-to-Thing Research Group (T2TRG) and its WISHI (Work on IoT Semantic/Hypermedia Interoperability, http://wishi.space) program to engage researchers and other SDOs in this space, such as W3C Web of Things, which is working on Thing Models and related specifications. Goals and Milestones: May 2022 - SDF specification, publication requested Done - SDF specification, WG document adopted Internet-Drafts: - Semantic Definition Format (SDF) for Data and Interactions of Things [draft-ietf-asdf-sdf-13] (100 pages) - Semantic Definition Format (SDF) for Data and Interactions of Things [draft-onedm-t2trg-sdf-00] (51 pages) No Requests for Comments Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Dr. Bernard D. Aboba Jonathan Lennox Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: https://mailarchive.ietf.org/arch/browse/avt/ Description of Working Group: The Real-time Transport Protocol (RTP) along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP is widely implemented and deployed for a broad range of applications, from telephony to television over IP. RTP itself is now an Internet Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. As new applications emerge, there is a need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications. The AVTCORE working group is chartered for the following tasks: 1. To maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. 2. To develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. 3. To specify and maintain payload formats for use with RTP. The working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those that are especially useful to Internet Standard, and declare others Historic. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36] and "How to Write an RTP Payload Format" (RFC 8088), and is responsible for maintaining those guidelines. 4. To evaluate and process proposals for RTP eXtended Report Block (XRBLOCK) definitions containing new metrics. The group will work within the framework defined by RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)" along with other RTP monitoring architecture being developed in the working group. It will follow the guidelines established in RFC 5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RFC 6390, "Guidelines for Considering New Performance Metric Development". The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile (SAVP). Goals and Milestones: Apr 2019 - Submit RTP Header Extension for Video Frame Information for Proposed Standard Jun 2019 - Submit Feedback Mechanism for RTP Congestion Control for Proposed Standard Nov 2019 - Submit RTP Payload Format for VP9 Video for Proposed Standard Mar 2020 - Submit RTP Payload Format for ISO/IEC 21122 (JPEG XS) for Proposed Standard Feb 2021 - Submit RTP Payload format for Versatile Video Coding (VVC) Feb 2021 - Submit RTP Mixer Formatting of Multi-party Real-time Text Jul 2021 - Submit RTP Payload format for Essential Video Coding (EVC) Done - Submit Guidelines for using the Multiplexing Features of RTP for Informational Done - Submit RTP Payload Format for TTML Timed Text for Proposed Standard Internet-Drafts: - Multiplexing Scheme Updates for QUIC [draft-aboba-avtcore-rfc7983bis-01] (8 pages) - SDP Offer/Answer for RTP using QUIC as Transport - Design Issues [draft-dawkins-avtcore-sdp-rtp-quic-issues-00] (8 pages) - RTP over QUIC [draft-engelbart-rtp-over-quic-04] (21 pages) - RTP Control Protocol (RTCP) Messages for Green Metadata [draft-he-avtcore-rtcp-green-metadata-01] (10 pages) - Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows [draft-ietf-avt-app-rtp-keepalive-10] (12 pages) - Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing [draft-ietf-avtcore-5761-update-06] (7 pages) - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [draft-ietf-avtcore-6222bis-06] (10 pages) - The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descriptions [draft-ietf-avtcore-aria-sdes-02] (9 pages) - The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-avtcore-aria-srtp-11] (19 pages) - Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) [draft-ietf-avtcore-avp-codecs-03] (4 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control [draft-ietf-avtcore-cc-feedback-message-09] (13 pages) - RTP Clock Source Signalling [draft-ietf-avtcore-clksrc-11] (30 pages) - Completely Encrypting RTP Header Extensions and Contributing Sources [draft-ietf-avtcore-cryptex-08] (21 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-08] (58 pages) - RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-17] (13 pages) - Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) [draft-ietf-avtcore-idms-13] (23 pages) - RTP and Leap Seconds [draft-ietf-avtcore-leap-second-08] (9 pages) - Guidelines for Use of the RTP Monitoring Framework [draft-ietf-avtcore-monarch-22] (17 pages) - Multipath RTP (MPRTP) [draft-ietf-avtcore-mprtp-03] (41 pages) - Sending Multiple Types of Media in a Single RTP Session [draft-ietf-avtcore-multi-media-rtp-session-13] (15 pages) - RTP-Mixer Formatting of Multiparty Real-Time Text [draft-ietf-avtcore-multi-party-rtt-mix-20] (35 pages) - Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams [draft-ietf-avtcore-multiplex-guidelines-12] (36 pages) - Port Mapping between Unicast and Multicast RTP Sessions [draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02] (30 pages) - A General Mechanism for RTP Header Extensions [draft-ietf-avtcore-rfc5285-bis-14] (25 pages) - Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) [draft-ietf-avtcore-rfc5764-mux-fixes-11] (13 pages) - Multiplexing Scheme Updates for QUIC [draft-ietf-avtcore-rfc7983bis-09] (10 pages) - RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution [draft-ietf-avtcore-rtcp-green-metadata-01] (12 pages) - Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions [draft-ietf-avtcore-rtp-circuit-breakers-18] (25 pages) - RTP Payload Format for Essential Video Coding (EVC) [draft-ietf-avtcore-rtp-evc-04] (50 pages) - Sending Multiple RTP Streams in a Single RTP Session [draft-ietf-avtcore-rtp-multi-stream-11] (29 pages) - Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback [draft-ietf-avtcore-rtp-multi-stream-optimisation-12] (16 pages) - RTP over QUIC [draft-ietf-avtcore-rtp-over-quic-02] (27 pages) - RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec [draft-ietf-avtcore-rtp-scip-05] (15 pages) - Options for Securing RTP Sessions [draft-ietf-avtcore-rtp-security-options-10] (37 pages) - RTP Topologies [draft-ietf-avtcore-rtp-topologies-update-10] (48 pages) - RTP Payload Format for Visual Volumetric Video-based Coding (V3C) [draft-ietf-avtcore-rtp-v3c-01] (41 pages) - RTP Payload Format for Versatile Video Coding (VVC) [draft-ietf-avtcore-rtp-vvc-18] (54 pages) - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-aes-gcm-17] (48 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avtcore-srtp-ekt-03] (45 pages) - Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-encrypted-header-ext-05] (15 pages) - Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [draft-ietf-avtcore-srtp-vbr-audio-04] (6 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-03] (44 pages) - Video Frame Marking RTP Header Extension [draft-ietf-avtext-framemarking-14] (15 pages) - Forward-Shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-08] (13 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-11] (35 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution [draft-ietf-avt-srtp-not-mandatory-16] (10 pages) - RTP Payload Format for ISO/IEC 21122 (JPEG XS) [draft-ietf-payload-rtp-jpegxs-18] (27 pages) - RTP Payload for Timed Text Markup Language (TTML) [draft-ietf-payload-rtp-ttml-06] (15 pages) - RTP Payload Format for the TETRA Audio Codec [draft-ietf-payload-tetra-03] (15 pages) - RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec [draft-ietf-payload-tsvcis-05] (20 pages) - RTP Payload Format for VP9 Video [draft-ietf-payload-vp9-16] (25 pages) - RTP Payload Format for Visual Volumetric Video-based Coding (V3C) [draft-ilola-avtcore-rtp-v3c-02] (41 pages) - Game State over Real Time Protocol [draft-jennings-dispatch-game-state-over-rtp-01] (24 pages) - RTP Congestion Control: Circuit Breakers for Unicast Sessions [draft-perkins-avtcore-rtp-circuit-breakers-01] (15 pages) - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [draft-rescorla-avtcore-6222bis-00] (10 pages) - Completely Encrypting RTP Header Extensions and Contributing Sources [draft-uberti-avtcore-cryptex-01] (10 pages) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (12 pages) RFC6284: Port Mapping between Unicast and Multicast RTP Sessions (30 pages) RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) RFC6562: Guidelines for the Use of Variable Bit Rate Audio with Secure RTP (6 pages) RFC6642: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report (13 pages) RFC6679: Explicit Congestion Notification (ECN) for RTP over UDP (58 pages) * Updates RFC8311 RFC6792: Guidelines for Use of the RTP Monitoring Framework (17 pages) RFC6904: Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) (15 pages) RFC7007: Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) (4 pages) RFC7022: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (10 pages) RFC7164: RTP and Leap Seconds (9 pages) RFC7201: Options for Securing RTP Sessions (37 pages) RFC7202: Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution (10 pages) RFC7272: Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) (23 pages) RFC7273: RTP Clock Source Signalling (30 pages) RFC7667: RTP Topologies (48 pages) RFC7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) (48 pages) RFC7983: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) (13 pages) RFC8035: Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing (7 pages) RFC8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions (25 pages) RFC8108: Sending Multiple RTP Streams in a Single RTP Session (29 pages) RFC8269: The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) (19 pages) RFC8285: A General Mechanism for RTP Header Extensions (25 pages) RFC8759: RTP Payload for Timed Text Markup Language (TTML) (15 pages) RFC8817: RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec (20 pages) RFC8860: Sending Multiple Types of Media in a Single RTP Session (15 pages) RFC8861: Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback (16 pages) RFC8872: Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams (36 pages) RFC8888: RTP Control Protocol (RTCP) Feedback for Congestion Control (13 pages) RFC9071: RTP-Mixer Formatting of Multiparty Real-Time Text (35 pages) RFC9134: RTP Payload Format for ISO/IEC 21122 (JPEG XS) (27 pages) RFC9328: RTP Payload Format for Versatile Video Coding (VVC) (54 pages) RFC9335: Completely Encrypting RTP Header Extensions and Contributing Sources (21 pages) Automatic SIP trunking And Peering (asap) ----------------------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Gonzalo Salgueiro Jean Mahoney Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: asap@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/asap Archive: https://mailarchive.ietf.org/arch/browse/asap/ Description of Working Group: The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between these networks, such as analog lines and time-division multiplexing (TDM)-based digital circuits. Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often unclear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks. As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individually or with enterprise equipment manufacturer and service provider support teams. Consequently, there is an increase in the time taken to deploy SIP trunking between enterprise and service provider networks. The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, encapsulates sufficient information to set up SIP trunking with the service provider network. In addition to defining a descriptive capability set, the ASAP working group will define a data model for the capability set, a service discovery mechanism and a transport mechanism for the capability set. The aforementioned deliverables of the ASAP working group are collectively referred to as “SIP Auto Peer”. The scope of the ASAP working group is: * A capability set that encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks. * A data model for the capability set. * An HTTPS-based transport mechanism for the capability set. * A mechanism to discover the server(s) in the SIP service provider network that hosts the capability set. * A mechanism to extend the data model to allow the encoding of proprietary parameters. The following are out of scope: * Extensions to SIP that enable an enterprise network to solicit and obtain a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly configure devices in the enterprise network. The group will produce: * Specification for SIP Auto Peer This group will co-ordinate with the SIPCORE working group and the SIPConnect efforts carried out by the SIP Forum. Goals and Milestones: Jun 2021 - SIP Automatic Peering specification submitted for publication to the IESG. Internet-Drafts: - Automatic Peering for SIP Trunks [draft-ietf-asap-sip-auto-peer-07] (40 pages) - The 'sip-trunking-capability' Link Relation Type [draft-ietf-asap-siptrunkingcapability-link-05] (6 pages) - Automatic Peering for SIP Trunks [draft-kinamdar-dispatch-sip-auto-peer-05] (32 pages) No Requests for Comments Building Blocks for HTTP APIs (httpapi) --------------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Darrel Miller Rich Salz Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Secretary: Mark Nottingham Mailing Lists: General Discussion: httpapi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/httpapi Archive: https://mailarchive.ietf.org/arch/browse/httpapi/ Description of Working Group: In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs. This Working Group will standardise HTTP protocol extensions for use in such cases, with a focus on building blocks for separate or combined use. Its output can include the following: • Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields) • Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects) • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc. Other items are out of scope. In particular, this WG will not take on work items for HTTP APIs for specific applications or services, and it will not define new HTTP extension points. APIs for HTTP itself (e.g., in clients and servers) are also out of scope. To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. To assess whether the group is functioning well, this charter will be reviewed by the IESG nine months after chartering. This Working Group will also need to coordinate closely with the HTTP Working Group, in particular when new methods and status codes are proposed. Work items that are more broadly applicable (e.g., for implementation in Web browsers) are likely to be more appropriate in the HTTP Working Group, but it is expected that coordination and discussion between the groups' Chairs and Area Director(s) will guide work items to the appropriate venue. Goals and Milestones: Internet-Drafts: - The Idempotency HTTP Header Field [draft-idempotency-header-01] (13 pages) - Link relationship types for authentication [draft-ietf-httpapi-authentication-link-00] (5 pages) - The Deprecation HTTP Header Field [draft-ietf-httpapi-deprecation-header-02] (14 pages) - The Idempotency-Key HTTP Header Field [draft-ietf-httpapi-idempotency-key-header-02] (12 pages) - Linkset: Media Types and a Link Relation Type for Link Sets [draft-ietf-httpapi-linkset-10] (31 pages) - The Link-Template HTTP Header Field [draft-ietf-httpapi-link-template-02] (6 pages) - RateLimit header fields for HTTP [draft-ietf-httpapi-ratelimit-headers-06] (33 pages) - REST API Media Types [draft-ietf-httpapi-rest-api-mediatypes-03] (14 pages) - Problem Details for HTTP APIs [draft-ietf-httpapi-rfc7807bis-07] (19 pages) - YAML Media Type [draft-ietf-httpapi-yaml-mediatypes-06] (17 pages) - REST API mediatypes [draft-polli-rest-api-mediatypes-00] (9 pages) - Linkset: Media Types and a Link Relation Type for Link Sets [draft-wilde-linkset-07] (29 pages) Requests for Comments: RFC9264: Linkset: Media Types and a Link Relation Type for Link Sets (31 pages) Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Bron Gondwana Daniel Migault Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: calsify@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: https://mailarchive.ietf.org/arch/browse/calsify/ Description of Working Group: The CALEXT working group is chartered to maintain and extend the specifications for formats and protocols related to calendaring and contacts within the IETF, starting from the basis of: - CalDAV (RFC 4791) - iCalendar (RFC 5545) - iTIP (RFC 5546) - iMIP (RFC 6047) - VCARD (RFC 6350) - CardDAV (RFC 6352) - JSCalendar (RFC 8984) - JSContact (draft-ietf-jmap-jscontact) and the many existing extensions and companion documents to these. This working group is envisaged to be long-running, and deal with a steady flow of changes. Experience has shown that these specifications are still seeing significant need for updates, as new use-cases are identified and user requirements change. This working group will do the following: - maintain existing standards and proposed standards, processing errata and refreshing them as required - evaluate and develop extensions to the existing standards to provide for new use-cases where there is demand - generate documents describing existing vendor extensions which are in common usage, and likely to be encountered in the wild. The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing standards. Incompatibilities must be identified, minimized, and justified. - Any extensions to icalendar or jscalendar must include a representation in both formats, and define a robust mapping between them. - Any extensions to vcard or jscontact must include a representation in both formats, and define a robust mapping between them. - All calendar extensions must examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. The working group will maintain relationships with other working groups: - HTTPBIS and HTTPAPI: when extending the CalDAV or CardDAV protocols to ensure that changes are consistent with good http practices. - JMAP: when making updates to JSCalendar and JSContact to ensure that the changes are compatible with the JMAP methods for managing data in these formats. - EXTRA, DMARC and EMAILCORE: for changes related to iTIP delivery via email. - TZDIST and SEDATE for date, time, and timezone related issues. - Other IETF working groups as appropriate, when their work interacts with ours. - Other standards organisations like CalConnect and M3AAWG that are doing work in the same fields. The following are out of scope for the working group: - Any attempt to develop non-Gregorian calendar systems/calculations. - Work which is in scope for any other ART area working group, and better suited to that group. - Work which is unrelated to anything that this group is currently maintaining. Goals and Milestones: Nov 2022 - Submit task draft to IESG Nov 2022 - Submit JSON Contact document to IESG Nov 2022 - Submit Subscription Upgrade document to IESG for publication Jan 2023 - Adopt a draft updating iTIP Feb 2023 - Submit Serverside Subscription draft to IESG for publication Apr 2023 - Submit vpoll document to IESG for publication Jul 2023 - Submit JSCalendar mapping document to IESG for publication Jul 2023 - Submit calendar series document to IESG for publication Internet-Drafts: - Calendar Availability [draft-daboo-calendar-availability-05] (22 pages) - New Properties for iCalendar [draft-daboo-icalendar-extensions-09] (21 pages) - Non-Gregorian Recurrence Rules in iCalendar [draft-daboo-icalendar-rscale-04] (15 pages) - Calendar Availability [draft-ietf-calext-availability-04] (24 pages) - Calendaring Extensions to WebDAV (CalDAV): Managed Attachments [draft-ietf-calext-caldav-attachments-04] (34 pages) - CalDAV Extension for scheduling controls [draft-ietf-calext-caldav-scheduling-controls-00] (6 pages) - Event Publishing Extensions to iCalendar [draft-ietf-calext-eventpub-extensions-19] (29 pages) - New Properties for iCalendar [draft-ietf-calext-extensions-05] (23 pages) - iCalendar Format Extension for JSCalendar [draft-ietf-calext-icalendar-jscalendar-extensions-00] (9 pages) - Support for Series in iCalendar [draft-ietf-calext-icalendar-series-03] (28 pages) - Support for iCalendar Relationships [draft-ietf-calext-ical-relations-11] (19 pages) - Task Extensions to iCalendar [draft-ietf-calext-ical-tasks-06] (31 pages) - JSCalendar: A JSON Representation of Calendar Data [draft-ietf-calext-jscalendar-32] (73 pages) - JSCalendar: A JSON Representation of Calendar Data [draft-ietf-calext-jscalendarbis-01] (88 pages) - JSCalendar: Converting from and to iCalendar [draft-ietf-calext-jscalendar-icalendar-07] (67 pages) - JSContact: A JSON representation of contact data [draft-ietf-calext-jscontact-10] (80 pages) - JSContact: Converting from and to vCard [draft-ietf-calext-jscontact-vcard-08] (63 pages) - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calext-rscale-04] (21 pages) - Serverside Subscriptions [draft-ietf-calext-serverside-subscriptions-02] (11 pages) - Calendar subscription upgrades [draft-ietf-calext-subscription-upgrade-08] (15 pages) - "VALARM" Extensions for iCalendar [draft-ietf-calext-valarm-extensions-07] (18 pages) - vCard Format Extension for JSContact [draft-ietf-calext-vcard-jscontact-extensions-06] (16 pages) - VPOLL: Consensus Scheduling Component for iCalendar [draft-ietf-calext-vpoll-04] (61 pages) - JSContact: A JSON representation of contact data [draft-ietf-jmap-jscontact-10] (26 pages) - JSContact: Converting from and to vCard [draft-ietf-jmap-jscontact-vcard-09] (41 pages) - JSCalendar: A JSON representation of calendar data [draft-jenkins-jscalendar-05] (51 pages) Requests for Comments: RFC7529: Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (21 pages) RFC7953: Calendar Availability (24 pages) RFC7986: New Properties for iCalendar (23 pages) RFC8607: Calendaring Extensions to WebDAV (CalDAV): Managed Attachments (34 pages) RFC8984: JSCalendar: A JSON Representation of Calendar Data (73 pages) RFC9073: Event Publishing Extensions to iCalendar (29 pages) RFC9074: "VALARM" Extensions for iCalendar (18 pages) RFC9253: Support for iCalendar Relationships (19 pages) Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Michael Richardson Spencer Dawkins Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: cellar@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cellar Archive: https://mailarchive.ietf.org/arch/browse/cellar/ Description of Working Group: The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community. FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption. There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption. Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Initial specifications can be accessed here: Specifications: - FFV1: https://mediaarea.net/temp/ffv1.html - Matroska: http://matroska.org/technical/specs/index.html - EBML: http://matroska-org.github.io/libebml/specs.html - FLAC: https://xiph.org/flac/format.html Development Versions: - FFV1: https://github.com/ffmpeg/ffv1 - Matroska: https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml - EBML: https://github.com/Matroska-Org/ebml-specification The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. Deliverables: - Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication - Standards Track specification for Matroska container format version 4 to IESG for publication - Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication - Standards Track specification for FFV1 video codec version 4 to IESG for publication - Standards Track specification for FLAC audio codec to IESG for publication Goals and Milestones: Apr 2022 - Submit specification for Matroska container to IESG (Standards Track) Jul 2022 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Jul 2022 - Submit specification for FLAC audio codec to IESG (Standards Track) Done - Adopt matroska specifications as WG documents Done - Adopt matroska specifications as WG documents Done - Submit specification for EBML to IESG (Standards Track) Done - Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Internet-Drafts: - Matroska Media Container Chapter Codecs Specifications [draft-ietf-cellar-chapter-codecs-02] (7 pages) - Matroska Media Container Codec Specifications [draft-ietf-cellar-codec-10] (54 pages) - Matroska Media Container Control Track Specifications [draft-ietf-cellar-control-02] (10 pages) - Extensible Binary Meta Language [draft-ietf-cellar-ebml-17] (51 pages) - FFV1 Video Coding Format Versions 0, 1, and 3 [draft-ietf-cellar-ffv1-20] (51 pages) - FFV1 Video Coding Format Version 4 [draft-ietf-cellar-ffv1-v4-20] (57 pages) - Free Lossless Audio Codec [draft-ietf-cellar-flac-08] (92 pages) - Matroska Media Container Format Specifications [draft-ietf-cellar-matroska-16] (162 pages) - Matroska Media Container Tag Specifications [draft-ietf-cellar-tags-10] (23 pages) - FF Video Codec 1 [draft-niedermayer-cellar-ffv1-02] (36 pages) - Free Lossless Audio Codec [draft-weaver-cellar-flac-00] (31 pages) Requests for Comments: RFC8794: Extensible Binary Meta Language (51 pages) RFC9043: FFV1 Video Coding Format Versions 0, 1, and 3 (51 pages) Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2023-03-08 Current Status: Active Chairs: Barry Leiba Christian Amsüss Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: cbor@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Description of Working Group: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group has updated RFC 7049 to deal with existing errata, and the new version, draft-ietf-cbor-7049bis, is in the RFC Editor queue to become an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. CDDL has been published as RFC 8610. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other than manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and, where warranted, progress them either in a standalone document or as part of a new edition of the specification. The working group will define the approach to further evolving CDDL as a sequence of editions, which might also add further extension points, probably as part of the introduction of the next edition of the CDDL base specification. The body of existing specifications that make use of CDDL is considered precious, and the WG will set out not to damage their value. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF as an RFC. There are a number of additional CBOR tagged types and CBOR related media type specifications that are currently adopted by the working group, are work items in other working groups, or exist as individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases, the working group expects to adopt and publish these proposals, and for those the working group will evaluate them individually and decide about adoption and milestones. Proposals that are deemed to be out of scope for the working group, for example because they are too narrow in purpose, may still be published as individual submissions or in another groups if there is a specific need. The CBOR group will review these proposals on request. Goals and Milestones: Internet-Drafts: - Additional Control Operators for CDDL [draft-bormann-cbor-cddl-control-02] (10 pages) - Packed CBOR [draft-bormann-cbor-packed-01] (9 pages) - Concise Binary Object Representation (CBOR) Tags for Object Identifiers [draft-bormann-cbor-tags-oid-07] (14 pages) - Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period [draft-bormann-cbor-time-tag-04] (11 pages) - Concise Binary Object Representation (CBOR) [draft-ietf-cbor-7049bis-16] (66 pages) - Concise Binary Object Representation (CBOR) Tags for Typed Arrays [draft-ietf-cbor-array-tags-08] (13 pages) - Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures [draft-ietf-cbor-cddl-08] (64 pages) - Additional Control Operators for the Concise Data Definition Language (CDDL) [draft-ietf-cbor-cddl-control-07] (11 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-ietf-cbor-date-tag-07] (6 pages) - On Stable Storage for Items in Concise Binary Object Representation (CBOR) [draft-ietf-cbor-file-magic-12] (18 pages) - Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes [draft-ietf-cbor-network-addresses-13] (10 pages) - Packed CBOR [draft-ietf-cbor-packed-08] (25 pages) - Concise Binary Object Representation (CBOR) Sequences [draft-ietf-cbor-sequence-02] (10 pages) - Concise Binary Object Representation (CBOR) Tags for Object Identifiers [draft-ietf-cbor-tags-oid-08] (13 pages) - Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period [draft-ietf-cbor-time-tag-05] (21 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-jones-cbor-date-tag-01] (5 pages) - On storing CBOR encoded items on stable storage [draft-richardson-cbor-file-magic-01] (5 pages) - CBOR tags for IPv4 and IPv6 addresses and prefixes [draft-richardson-cbor-network-addresses-01] (4 pages) Requests for Comments: RFC8610: Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures (64 pages) RFC8742: Concise Binary Object Representation (CBOR) Sequences (10 pages) RFC8746: Concise Binary Object Representation (CBOR) Tags for Typed Arrays (13 pages) RFC8943: Concise Binary Object Representation (CBOR) Tags for Date (6 pages) RFC8949: Concise Binary Object Representation (CBOR) (66 pages) RFC9090: Concise Binary Object Representation (CBOR) Tags for Object Identifiers (13 pages) RFC9164: Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes (10 pages) RFC9165: Additional Control Operators for the Concise Data Definition Language (CDDL) (11 pages) RFC9277: On Stable Storage for Items in Concise Binary Object Representation (CBOR) (18 pages) STD94: Concise Binary Object Representation (CBOR) (66 pages) Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2022-10-10 Current Status: Active Chairs: Carsten Bormann Jaime Jimenez Marco Tiloca Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Description of Working Group: CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Goals and Milestones: Jun 2022 - Management over CoAP submitted to IESG for PS Jun 2022 - Secure group communication for CoAP submitted to IESG for PS Jun 2022 - Group communication for CoAP bis submitted to IESG for PS Jun 2022 - Constrained Resource Identifiers submitted to IESG for PS Sep 2022 - Conditional Attributes for Constrained RESTful Environments submitted to IESG for PS Mar 2023 - Constrained RESTful Application Language (CoRAL) submitted to IESG for PS May 2023 - Using EDHOC with CoAP and OSCORE submitted to IESG for PS May 2023 - Creation of IANA registry for CoRE target attributes submitted to IESG as Informational RFC Jun 2023 - Dynamic Resource Linking for Constrained RESTful Environments submitted to IESG for PS Dec 2099 - CoRE Interfaces submitted to IESG Done - Blockwise transfers in CoAP submitted to IESG Done - Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG Done - WG adoption for Management over CoAP Done - Representing CoRE Link Collections in JSON submitted to IESG Done - Patch and Fetch Methods for CoAP submitted to IESG for PS Done - CoAP over TCP, TLS, and WebSockets submitted to IESG for PS Done - Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS Done - Object Security for Constrained RESTful Environments (OSCORE) Done - CBOR Encoding of Data Modeled with YANG submitted to IESG for PS Done - CoRE Resource Directory submitted to IESG for PS Done - Concise Problem Details For CoAP APIs submitted to IESG for PS Internet-Drafts: - CoAP Protocol Indication [draft-amsuess-core-transport-indication-03] (25 pages) - SenML Features and Versions [draft-bormann-core-senml-versions-01] (5 pages) - CoRE Target Attribute Registry [draft-bormann-core-target-attr-01] (10 pages) - Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission [draft-bosh-core-new-block-04] (23 pages) - Problem Details For CoAP APIs [draft-fossati-core-coap-problem-02] (12 pages) - Constrained Application Protocol (CoAP) Performance Measurement Option [draft-fz-core-coap-pm-04] (16 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-hartke-core-stateless-02] (16 pages) - Attacks on the Constrained Application Protocol (CoAP) [draft-ietf-core-attacks-on-coap-02] (19 pages) - Block-Wise Transfers in the Constrained Application Protocol (CoAP) [draft-ietf-core-block-21] (37 pages) - The Constrained Application Protocol (CoAP) [draft-ietf-core-coap-18] (112 pages) - Constrained Application Protocol (CoAP) Performance Measurement Option [draft-ietf-core-coap-pm-00] (16 pages) - A publish-subscribe architecture for the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-pubsub-12] (25 pages) - CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [draft-ietf-core-coap-tcp-tls-11] (54 pages) - CoAP Simple Congestion Control/Advanced [draft-ietf-core-cocoa-03] (18 pages) - CoAP Management Interface (CORECONF) [draft-ietf-core-comi-12] (55 pages) - Conditional Attributes for Constrained RESTful Environments [draft-ietf-core-conditional-attributes-06] (19 pages) - The Constrained RESTful Application Language (CoRAL) [draft-ietf-core-coral-05] (48 pages) - Uniform Resource Names for Device Identifiers [draft-ietf-core-dev-urn-11] (15 pages) - DNS over CoAP (DoC) [draft-ietf-core-dns-over-coap-02] (13 pages) - Dynamic Resource Linking for Constrained RESTful Environments [draft-ietf-core-dynlink-14] (14 pages) - Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing [draft-ietf-core-echo-request-tag-14] (27 pages) - PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) [draft-ietf-core-etch-04] (21 pages) - Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP [draft-ietf-core-fasor-02] (15 pages) - Group Communication for the Constrained Application Protocol (CoAP) [draft-ietf-core-groupcomm-25] (46 pages) - Group Communication for the Constrained Application Protocol (CoAP) [draft-ietf-core-groupcomm-bis-08] (86 pages) - Constrained Application Protocol (CoAP) Hop-Limit Option [draft-ietf-core-hop-limit-07] (8 pages) - Constrained Resource Identifiers [draft-ietf-core-href-12] (45 pages) - Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) [draft-ietf-core-http-mapping-17] (40 pages) - Reusable Interface Definitions for Constrained RESTful Environments [draft-ietf-core-interfaces-14] (25 pages) - Constrained RESTful Environments (CoRE) Link Format [draft-ietf-core-link-format-14] (22 pages) - Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR [draft-ietf-core-links-json-10] (20 pages) - Multipart Content-Format for the Constrained Application Protocol (CoAP) [draft-ietf-core-multipart-ct-04] (9 pages) - Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission [draft-ietf-core-new-block-14] (41 pages) - Object Security for Constrained RESTful Environments (OSCORE) [draft-ietf-core-object-security-16] (94 pages) - Observing Resources in the Constrained Application Protocol (CoAP) [draft-ietf-core-observe-16] (30 pages) - Observe Notifications as CoAP Multicast Responses [draft-ietf-core-observe-multicast-notifications-06] (86 pages) - Using EDHOC with CoAP and OSCORE [draft-ietf-core-oscore-edhoc-07] (30 pages) - Group OSCORE - Secure Group Communication for CoAP [draft-ietf-core-oscore-groupcomm-17] (113 pages) - Key Usage Limits for OSCORE [draft-ietf-core-oscore-key-limits-00] (12 pages) - Key Update for OSCORE (KUDOS) [draft-ietf-core-oscore-key-update-04] (55 pages) - Concise Problem Details for Constrained Application Protocol (CoAP) APIs [draft-ietf-core-problem-details-08] (21 pages) - CoRE Resource Directory: DNS-SD mapping [draft-ietf-core-rd-dns-sd-05] (14 pages) - Constrained RESTful Environments (CoRE) Resource Directory [draft-ietf-core-resource-directory-28] (60 pages) - Sensor Measurement Lists (SenML) [draft-ietf-core-senml-16] (54 pages) - Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format [draft-ietf-core-senml-data-ct-07] (10 pages) - FETCH and PATCH with Sensor Measurement Lists (SenML) [draft-ietf-core-senml-etch-07] (11 pages) - Additional Units for Sensor Measurement Lists (SenML) [draft-ietf-core-senml-more-units-06] (9 pages) - Sensor Measurement Lists (SenML) Features and Versions [draft-ietf-core-senml-versions-05] (7 pages) - YANG Schema Item iDentifier (YANG SID) [draft-ietf-core-sid-20] (46 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-ietf-core-stateless-08] (20 pages) - CoRE Target Attributes Registry [draft-ietf-core-target-attr-04] (8 pages) - "Too Many Requests" Response Code for the Constrained Application Protocol [draft-ietf-core-too-many-reqs-06] (6 pages) - CoAP Protocol Indication [draft-ietf-core-transport-indication-02] (27 pages) - Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) [draft-ietf-core-yang-cbor-20] (45 pages) - Constrained YANG Module Library [draft-ietf-core-yang-library-03] (17 pages) - Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP [draft-jarvinen-core-fasor-02] (15 pages) - SenML Data Value Content-Format Indication [draft-keranen-core-senml-data-ct-02] (6 pages) - Attacks on the Constrained Application Protocol (CoAP) [draft-mattsson-core-coap-attacks-03] (20 pages) - Combining EDHOC and OSCORE [draft-palombini-core-oscore-edhoc-02] (12 pages) - Observe Notifications as CoAP Multicast Responses [draft-tiloca-core-observe-multicast-notifications-05] (67 pages) - Constrained YANG Module Library [draft-veillette-core-yang-library-05] (15 pages) Requests for Comments: RFC6690: Constrained RESTful Environments (CoRE) Link Format (22 pages) RFC7252: The Constrained Application Protocol (CoAP) (112 pages) * Updates RFC7959 * Updates RFC8613 * Updates RFC8974 * Updates RFC9175 RFC7390: Group Communication for the Constrained Application Protocol (CoAP) (46 pages) RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) (30 pages) * Updates RFC8323 RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) (37 pages) * Updates RFC8323 * Updates RFC8323 RFC8075: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) (40 pages) RFC8132: PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) (21 pages) RFC8323: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets (54 pages) * Updates RFC8974 RFC8428: Sensor Measurement Lists (SenML) (54 pages) * Updates RFC9100 RFC8516: "Too Many Requests" Response Code for the Constrained Application Protocol (6 pages) RFC8613: Object Security for Constrained RESTful Environments (OSCORE) (94 pages) RFC8710: Multipart Content-Format for the Constrained Application Protocol (CoAP) (9 pages) RFC8768: Constrained Application Protocol (CoAP) Hop-Limit Option (8 pages) RFC8790: FETCH and PATCH with Sensor Measurement Lists (SenML) (11 pages) RFC8798: Additional Units for Sensor Measurement Lists (SenML) (9 pages) RFC8974: Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) (20 pages) RFC9039: Uniform Resource Names for Device Identifiers (15 pages) RFC9100: Sensor Measurement Lists (SenML) Features and Versions (7 pages) RFC9175: Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing (27 pages) RFC9176: Constrained RESTful Environments (CoRE) Resource Directory (60 pages) RFC9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission (41 pages) RFC9193: Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format (10 pages) RFC9254: Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) (45 pages) RFC9290: Concise Problem Details for Constrained Application Protocol (CoAP) APIs (21 pages) Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Kevin J. Ma Sanjay Mishra Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: https://mailarchive.ietf.org/arch/browse/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A specification of the "CDNI Request Routing Redirection interface". This interface will allow an upstream CDN Request Routing system to obtain from the downstream CDN the information necessary to perform request redirection. It is actually a logical bundling of two separate but related interfaces: * Footprint & Capability Advertisement interface: Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * Request Routing Redirection interface: Synchronous operations to select a delivery CDN (surrogate) for a given user request. - A specification of the "CDNI Metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI Logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI Control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropriate. Goals and Milestones: Nov 2022 - Submit specification of CDNI Control Triggers Interface Extensions to IESG as Proposed Standard Nov 2022 - Submit specification of CDNI Extensions for HTTPS ACME STAR Delegation to IESG as Proposed Standard Mar 2023 - Submit specification of CDNI Extensions for HTTPS TLS Subcert Delegation to IESG as Proposed Standard Jul 2023 - Submit specification of CDNI Extensions for Capacity Capability Advertisement Aug 2023 - Recharter or dissolve Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Done - Submit CDNI requirements to IESG as Informational Done - Submit CDNI framework to IESG as Informational Done - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Done - Submit specification of the CDNI Control interface to IESG as proposed Standard Done - Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard Done - Submit specification of the CDNI Metadata interface to IESG as Proposed Standard Done - Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard Done - Submit specification of CDNI Request Routing Extensions to IESG as Proposed Standard Done - Submit specification of URI Signing for CDNI to IESG as Proposed Standard Done - Submit specification of CDNI Footprint Type Extensions to IESG as Proposed Standard Internet-Drafts: - CDNI SVA Request Routing Extensions [draft-finkelman-cdni-rr-sva-extensions-01] (11 pages) - Content Delivery Network Interconnection (CDNI) Footprint Types: Subdivision Code and Footprint Union [draft-ietf-cdni-additional-footprint-types-11] (12 pages) - CDNI Capacity Capability Advertisement Extensions [draft-ietf-cdni-capacity-insights-extensions-01] (15 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition [draft-ietf-cdni-ci-triggers-rfc8007bis-04] (88 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers [draft-ietf-cdni-control-triggers-15] (49 pages) - CDNI delegation using Automated Certificate Management Environment [draft-ietf-cdni-delegation-acme-02] (11 pages) - Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics [draft-ietf-cdni-footprint-capabilities-semantics-20] (31 pages) - Framework for Content Distribution Network Interconnection (CDNI) [draft-ietf-cdni-framework-14] (58 pages) - CDNI Metadata for Delegated Credentials [draft-ietf-cdni-https-delegation-subcerts-03] (11 pages) - CDNI extensions for HTTPS delegation [draft-ietf-cdni-interfaces-https-delegation-13] (10 pages) - Content Distribution Network Interconnection (CDNI) Logging Interface [draft-ietf-cdni-logging-27] (63 pages) - Content Delivery Network Interconnection (CDNI) Media Type Registration [draft-ietf-cdni-media-type-06] (7 pages) - Content Delivery Network Interconnection (CDNI) Metadata [draft-ietf-cdni-metadata-21] (66 pages) - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-08] (32 pages) - Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection [draft-ietf-cdni-redirection-20] (35 pages) - Content Delivery Network Interconnection (CDNI) Request Routing Extensions [draft-ietf-cdni-request-routing-extensions-08] (17 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-17] (23 pages) - CDNI Control Triggers Interface Extensions [draft-ietf-cdni-triggers-extensions-09] (45 pages) - URI Signing for Content Delivery Network Interconnection (CDNI) [draft-ietf-cdni-uri-signing-26] (37 pages) - Use Cases for Content Delivery Network Interconnection [draft-ietf-cdni-use-cases-10] (16 pages) Requests for Comments: RFC6707: Content Distribution Network Interconnection (CDNI) Problem Statement (32 pages) RFC6770: Use Cases for Content Delivery Network Interconnection (16 pages) RFC7336: Framework for Content Distribution Network Interconnection (CDNI) (58 pages) RFC7337: Content Distribution Network Interconnection (CDNI) Requirements (23 pages) RFC7736: Content Delivery Network Interconnection (CDNI) Media Type Registration (7 pages) RFC7937: Content Distribution Network Interconnection (CDNI) Logging Interface (63 pages) RFC7975: Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection (35 pages) RFC8006: Content Delivery Network Interconnection (CDNI) Metadata (66 pages) RFC8007: Content Delivery Network Interconnection (CDNI) Control Interface / Triggers (49 pages) RFC8008: Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics (31 pages) RFC8804: Content Delivery Network Interconnection (CDNI) Request Routing Extensions (17 pages) RFC9246: URI Signing for Content Delivery Network Interconnection (CDNI) (37 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2023-04-04 Current Status: Active Chairs: Jim Fenton Shuping Peng Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: dispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: https://mailarchive.ietf.org/arch/browse/dispatch/ Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the ART area is expected to be considered in the DISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths. For example work may go directly to BoFs, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD sponsored. Goals and Milestones: Internet-Drafts: - Updates to ECMAScript Media Types [draft-ietf-dispatch-javascript-mjs-17] (13 pages) Requests for Comments: RFC9239: Updates to ECMAScript Media Types (13 pages) Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Barry Leiba Seth Blank Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: dmarc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: https://mailarchive.ietf.org/arch/browse/dmarc/ Description of Working Group: Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. The existing DMARC base specification is published as Informational RFC 7489 in the Independent Stream. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue four tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document desirable uses of existing authentication technologies. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options 4. Related work Extensions to SPF/DKIM/DMARC that do not already fit under the charter of any existing working group can be considered for adoption by DMARC Working Group after consultation with the responsible AD. A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related updates to DMARC and the protocols upon which it depends. Any such work needs to carefully consider interoperability implications. Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. This is now complete and published as RFC 7960. Phase II: Specification of DMARC improvements to support indirect mail flows; this is now complete as draft-ietf-dmarc-arc-protocol (ARC). Draft Guide on DMARC Usage. Phase III: Review and refinement of the DMARC specification. Completion of Guide on DMARC and ARC Usage. References ---------- DMARC - http://dmarc.org SPF - RFC7208 Authentication-Results Header Field - RFC7001 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 Goals and Milestones: Done - Complete Authenticated Received Chain (ARC) protocol spec Internet-Drafts: - DMARC Use of the RFC5322.Sender Header Field [draft-crocker-dmarc-sender-01] (8 pages) - Interoperability Issues Between DMARC and Indirect Email Flows [draft-dmarc-interoperability-00] (16 pages) - DMARC Aggregate Reporting [draft-ietf-dmarc-aggregate-reporting-11] (28 pages) - Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol [draft-ietf-dmarc-arc-multi-03] (6 pages) - The Authenticated Received Chain (ARC) Protocol [draft-ietf-dmarc-arc-protocol-23] (35 pages) - Recommended Usage of the Authenticated Received Chain (ARC) [draft-ietf-dmarc-arc-usage-09] (19 pages) - Domain-based Message Authentication, Reporting, and Conformance (DMARC) [draft-ietf-dmarc-dmarcbis-27] (71 pages) - Email Authentication for Internationalized Mail [draft-ietf-dmarc-eaiauth-06] (6 pages) - Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting [draft-ietf-dmarc-failure-reporting-07] (15 pages) - Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows [draft-ietf-dmarc-interoperability-18] (27 pages) - Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains [draft-ietf-dmarc-psd-15] (14 pages) - Message Header Field for Indicating Message Authentication Status [draft-ietf-dmarc-rfc7601bis-06] (54 pages) - DMARC Use of the RFC5322.Sender Header Field [draft-ietf-dmarc-sender-00] (8 pages) Requests for Comments: RFC7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows (27 pages) RFC8601: Message Header Field for Indicating Message Authentication Status (54 pages) RFC8616: Email Authentication for Internationalized Mail (6 pages) RFC8617: The Authenticated Received Chain (ARC) Protocol (35 pages) RFC9091: Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains (14 pages) Domain Keys Identified Mail (dkim) ---------------------------------- Charter Last Modified: 2023-02-21 Current Status: Active Chairs: Laura A Tim Wicinski Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: ietf-dkim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ietf-dkim/ Archive: https://mailarchive.ietf.org/arch/browse/ietf-dkim/ Description of Working Group: Domain Keys Identified Mail (DKIM, RFC 6376) defines a method for using a digital signature to associate a domain identity with an email message using an appropriate cryptographic authentication mechanism, and to assure receiving domains that the message has not been altered since the signature was created. Receiving systems can use this information as part of their message-handling decision. This can help reduce spam, phishing, and other unwanted or malicious email. A DKIM-signed message can be re-posted, to additional recipients, in a fashion that retains the original signature. With an author and a recipient collaborating, this can "replay" the message, using the original signer's reputation to propagate email with problematic content -- spam, phishing, and the like. Generally, the technical characteristics of this form of abuse match those of legitimate mail, making its detection or prevention challenging. Timestamps and carefully-tailored message signing conventions are appealing approaches to replay mitigation. Each has significant limitations. The DKIM working group will first develop and publish a clear problem statement. Then, it will produce one or more technical specifications that propose replay-resistant mechanisms. The working group will prefer solutions compatible with DKIM's broad deployment, and there will be an expectation that these solutions will have been through implementation and interoperability testing before publication. If the working group decides that is unable to identify a consensus technical solution to this problem space, it may instead publish a report describing the problem and summarizing the reasons that none of the proposed approaches are acceptable. Finally, the working group may produce documents that update operational advice to reflect modern considerations, especially with respect to the replay problem described above. This should be done only if there is a consensus opinion that such advice would be based on experience rather than theory. Current proposals include the following drafts:  - draft-bradshaw-envelope-validation-extension-dkim - draft-chuang-dkim-replay-problem  - draft-chuang-replay-resistant-arc  - draft-gondwana-email-mailpath  - draft-kucherawy-dkim-anti-replay The working group may adopt or ignore these as it sees fit, and may consider or develop other proposals. Goals and Milestones: Apr 2023 - Post a consensus problem statement draft to the datatracker (may not go to the IESG) Jun 2023 - Proposal regarding plans for remaining document(s) presented to the AD Dec 2023 - Submit technical specifications for replay-resistant DKIM enhancement(s) to the IESG at Proposed Standard Dec 2023 - Submit revised operational advice for replay-resistant DKIM use to the IESG at Informational Internet-Drafts: - DKIM Replay Problem Statement [draft-chuang-dkim-replay-problem-03] (13 pages) - DomainKeys Identified Mail (DKIM) Signatures [draft-ietf-dkim-base-10] (71 pages) - DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations [draft-ietf-dkim-deployment-11] (51 pages) - RFC4871 Implementation Report [draft-ietf-dkim-implementation-report-06] (17 pages) - DomainKeys Identified Mail (DKIM) and Mailing Lists [draft-ietf-dkim-mailinglists-12] (26 pages) - DomainKeys Identified Mail (DKIM) Service Overview [draft-ietf-dkim-overview-12] (24 pages) - DomainKeys Identified Mail (DKIM) Signatures [draft-ietf-dkim-rfc4871bis-15] (76 pages) - RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update [draft-ietf-dkim-rfc4871-errata-07] (14 pages) - DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) [draft-ietf-dkim-ssp-10] (21 pages) - Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol [draft-ietf-dkim-ssp-requirements-05] (15 pages) - Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) [draft-ietf-dkim-threats-03] (29 pages) Requests for Comments: BCP167: DomainKeys Identified Mail (DKIM) and Mailing Lists (26 pages) RFC4686: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) (29 pages) RFC4871: DomainKeys Identified Mail (DKIM) Signatures (71 pages) * Obsoletes RFC6376 * Updates RFC5672 RFC5016: Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol (15 pages) RFC5585: DomainKeys Identified Mail (DKIM) Service Overview (24 pages) RFC5617: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (21 pages) * Updates RFC8553 RFC5672: RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update (14 pages) * Obsoletes RFC6376 RFC5863: DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations (51 pages) RFC6376: DomainKeys Identified Mail (DKIM) Signatures (76 pages) * Updates RFC8301 * Updates RFC8463 * Updates RFC8553 * Updates RFC8616 RFC6377: DomainKeys Identified Mail (DKIM) and Mailing Lists (26 pages) STD76: DomainKeys Identified Mail (DKIM) Signatures (76 pages) Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: extra@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/extra Archive: https://mailarchive.ietf.org/arch/browse/extra/ Description of Working Group: The IETF maintains several key email related protocols that relate to message delivery to mailstores and mailstore access. These include the following: IMAP (RFC3501) SIEVE (RFC5228) ManageSieve (RFC5804) From time to time, there are bursts of work to do and the motivation and critical mass to do it. When such bursts coincide, it's important to give them a home. This working group provides such a venue. The WG will work on updates, extensions, and revisions to the above email protocols. Upon formation, the working group will consider any existing Internet Drafts that could be appropriate for its processing. While an interest poll for a new related idea is fine, the WG should avoid detailed discussion of work items lacking an Internet-Draft. The working group will start with processing the backlog of IMAP/Sieve extensions. Once this is done it will continue processing submitted IMAP/Sieve extensions, as well as work on a revision of IMAP (RFC 3501). Work on updating this RFC will include appropriate corrections, clarifications, or amplifications to reflect existing practice or to address problems that have been identified through experience with IMAP as currently specified. Also eligible for consideration is the incorporation of accumulated errata or consolidation with newer documents that have updated and/or extended the base specification. However, any new functionality is expected to be pursued via extensions rather than changes to the base protocol wherever possible. If there is interest in revising SIEVE (RFC5228) and ManageSieve (RFC5804), the WG will recharter. Expressly excluded from this charter is work on any protocol for which a dedicated working group already exists, such as DMARC, DCRUP or JMAP, as well as any work on POP3, SMTP/LMTP and email format/MIME. However, each working group should endeavor to remain aware of the activities of the other and collaborate as needed. Goals and Milestones: Jun 2022 - Adopt a document for EAI with Sieve Nov 2022 - Submit process imip draft to IESG Nov 2022 - Adopt a document for returning metadata in list responses Dec 2022 - Submit Sieve EAI to IESG Dec 2022 - Submit Sieve Snooze document to IESG Feb 2023 - Submit MESSAGELIMIT draft Done - Submit "Sieve Email Filtering: Delivering to Special-Use Mailboxes" to IESG as a Proposed Standard Done - Submit "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST" to IESG as a Proposed Standard Done - Adopt a QUOTA-BIS document Done - Adopt a sieve-snooze document Done - Submit sieve-mailboxid to the IESG as a proposed standard Done - Submit "IMAP4rev2" to IESG as a Proposed Standard Done - Submit "Quota BIS" to IESG as a Proposed Standard Done - Adopt a document creating a sieve actions registry Internet-Drafts: - Internet Message Access Protocol (IMAP) - SAVEDATE Extension [draft-bosch-imap-savedate-00] (6 pages) - Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension [draft-bosch-imap-status-size-00] (5 pages) - IMAP REPLACE Extension [draft-brandt-imap-replace-03] (10 pages) - IMAP Extension for unique identifiers [draft-extra-imap-uniqueid-00] (10 pages) - Internet Message Access Protocol (IMAP) - Version 4rev2 [draft-ietf-extra-imap4rev2-30] (163 pages) - 64bit body part and message sizes in IMAP4 [draft-ietf-extra-imap-64bit-03] (7 pages) - IMAP4 Extension: Message Preview Generation [draft-ietf-extra-imap-fetch-preview-10] (10 pages) - IMAP4 Extension: Message Snippet Generation [draft-ietf-extra-imap-fetch-snippet-00] (10 pages) - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST [draft-ietf-extra-imap-list-myrights-07] (6 pages) - IMAP MESSAGELIMIT Extension [draft-ietf-extra-imap-messagelimit-03] (9 pages) - IMAP Extension for Object Identifiers [draft-ietf-extra-imap-objectid-08] (16 pages) - IMAP Paged SEARCH & FETCH Extension [draft-ietf-extra-imap-partial-04] (10 pages) - IMAP REPLACE Extension [draft-ietf-extra-imap-replace-03] (11 pages) - Internet Message Access Protocol (IMAP) - SAVEDATE Extension [draft-ietf-extra-imap-savedate-01] (7 pages) - IMAP Extension for STATUS=SIZE [draft-ietf-extra-imap-status-size-02] (6 pages) - IMAP Extension for only using and returning UIDs [draft-ietf-extra-imap-uidonly-01] (8 pages) - IMAP UNAUTHENTICATE Extension for Connection Reuse [draft-ietf-extra-imap-unauth-01] (11 pages) - IMAP Extension for unique identifiers [draft-ietf-extra-imap-uniqueid-00] (10 pages) - The JMAPACCESS Extension for IMAP [draft-ietf-extra-jmapaccess-03] (7 pages) - Sieve Email Filtering: Extension for Processing iMIP Messages [draft-ietf-extra-processimip-01] (8 pages) - IMAP QUOTA Extension [draft-ietf-extra-quota-10] (19 pages) - IANA registry for Sieve actions [draft-ietf-extra-sieve-action-registry-06] (9 pages) - Sieve Extension: File Carbon Copy (FCC) [draft-ietf-extra-sieve-fcc-09] (12 pages) - Sieve Email Filtering: Delivery by MAILBOXID [draft-ietf-extra-sieve-mailboxid-09] (8 pages) - Sieve Email Filtering: Snooze Extension [draft-ietf-extra-sieve-snooze-07] (14 pages) - Sieve Email Filtering: Delivering to Special-Use Mailboxes [draft-ietf-extra-sieve-special-use-05] (12 pages) - IMAP "$Important" Keyword and "\Important" Special-Use Attribute [draft-ietf-extra-specialuse-important-04] (11 pages) - IMAP $Important Keyword and \Important Special-Use Attribute [draft-leiba-extra-specialuse-important-01] (9 pages) - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 [draft-melnikov-imap4rev2-08] (125 pages) - IMAP4 Extension: Message Snippet Generation [draft-slusarz-imap-fetch-snippet-00] (10 pages) Requests for Comments: RFC8437: IMAP UNAUTHENTICATE Extension for Connection Reuse (11 pages) RFC8438: IMAP Extension for STATUS=SIZE (6 pages) RFC8440: IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST (6 pages) RFC8457: IMAP "$Important" Keyword and "\Important" Special-Use Attribute (11 pages) RFC8474: IMAP Extension for Object Identifiers (16 pages) RFC8508: IMAP REPLACE Extension (11 pages) RFC8514: Internet Message Access Protocol (IMAP) - SAVEDATE Extension (7 pages) RFC8579: Sieve Email Filtering: Delivering to Special-Use Mailboxes (12 pages) RFC8580: Sieve Extension: File Carbon Copy (FCC) (12 pages) RFC8970: IMAP4 Extension: Message Preview Generation (10 pages) RFC9042: Sieve Email Filtering: Delivery by MAILBOXID (8 pages) RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2 (163 pages) RFC9208: IMAP QUOTA Extension (19 pages) Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Allison Mankin Randall Gellens Roger Marshall Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit Archive: https://mailarchive.ietf.org/arch/browse/ecrit/ Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group has described where and how these mechanisms may be used. The group specified how location data and call routing information are used to enable communication between a user and a relevant emergency response center [RFC6443,RFC6444]. Though the term "call routing" is used, it should be understood that some of the mechanisms described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group will develop new methods to enable non-human-initiated requests for emergency assistance, such as sensor initiated emergency requests. The working group will also address topics required for the operation of emergency calling systems, such as: authentication of location, management of the service URN namespace, augmented information that could assist emergency call takers or responders. Explicitly outside the scope of this group is the question of pre- emption or prioritization of emergency services traffic in the network. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, language contents, etc., may be routed differently depending on established policies and availability. This working group will address privacy and security concerns within its documents. Goals and Milestones: Nov 2022 - Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the Mapping Protocol Architecture Done - A Standards Track RFC describing how to route an emergency call based on location information Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC Done - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Done - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Done - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Done - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC Done - Submit 'A Routing Request Extension for the HELD Protocol' to the IESG for consideration as a Standards Track RFC Done - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Done - Submit ‘Internet Protocol-based In-Vehicle Emergency Calls‘ to the IESG for consideration as an Informational RFC Done - Submit ‘Next-Generation Pan-European eCall‘ to the IESG for consideration as an Informational RFC Done - Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC Done - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Internet-Drafts: - Validation of Locations Around a Planned Change [draft-ecrit-lost-planned-changes-00] (10 pages) - Additional Data Related to an Emergency Call [draft-ietf-ecrit-additional-data-38] (113 pages) - Next-Generation Vehicle-Initiated Emergency Calls [draft-ietf-ecrit-car-crash-23] (40 pages) - URN for Country-Specific Emergency Services [draft-ietf-ecrit-country-emg-urn-03] (4 pages) - Non-interactive Emergency Calls [draft-ietf-ecrit-data-only-ea-22] (25 pages) - Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) [draft-ietf-ecrit-dhc-lost-discovery-03] (8 pages) - Next-Generation Pan-European eCall [draft-ietf-ecrit-ecall-27] (43 pages) - Framework for Emergency Calling Using Internet Multimedia [draft-ietf-ecrit-framework-13] (38 pages) - A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol [draft-ietf-ecrit-held-routing-05] (16 pages) - IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications [draft-ietf-ecrit-local-emergency-rph-namespace-04] (8 pages) - Location Hiding: Problem Statement and Requirements [draft-ietf-ecrit-location-hiding-req-04] (9 pages) - Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy [draft-ietf-ecrit-location-profile-registry-policy-02] (4 pages) - LoST: A Location-to-Service Translation Protocol [draft-ietf-ecrit-lost-10] (69 pages) - Validation of Locations Around a Planned Change [draft-ietf-ecrit-lost-planned-changes-07] (21 pages) - Location-to-Service Translation (LoST) Service List Boundary Extension [draft-ietf-ecrit-lost-servicelistboundary-05] (15 pages) - Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol [draft-ietf-ecrit-lost-sync-18] (25 pages) - Location-to-URL Mapping Architecture and Framework [draft-ietf-ecrit-mapping-arch-04] (17 pages) - Best Current Practice for Communications Services in Support of Emergency Calling [draft-ietf-ecrit-phonebcp-20] (28 pages) - Public Safety Answering Point (PSAP) Callback [draft-ietf-ecrit-psap-callback-13] (18 pages) - Requirements for Emergency Context Resolution with Internet Technologies [draft-ietf-ecrit-requirements-13] (23 pages) - Using Imprecise Location for Emergency Context Resolution [draft-ietf-ecrit-rough-loc-05] (19 pages) - Security Threats and Requirements for Emergency Call Marking and Mapping [draft-ietf-ecrit-security-threats-05] (12 pages) - A Uniform Resource Name (URN) for Emergency and Other Well-Known Services [draft-ietf-ecrit-service-urn-07] (14 pages) - Policy for defining new service-identifying labels [draft-ietf-ecrit-service-urn-policy-04] (4 pages) - A LoST extension to return complete and similar location info [draft-ietf-ecrit-similar-location-19] (19 pages) - Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries [draft-ietf-ecrit-specifying-holes-03] (11 pages) - Trustworthy Location [draft-ietf-ecrit-trustworthy-location-14] (31 pages) - Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices [draft-ietf-ecrit-unauthenticated-access-10] (25 pages) - Emergency Registries [draft-rosen-ecrit-emergency-registries-01] (53 pages) Requests for Comments: BCP181: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) RFC5012: Requirements for Emergency Context Resolution with Internet Technologies (23 pages) RFC5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (14 pages) * Updates RFC7163 RFC5069: Security Threats and Requirements for Emergency Call Marking and Mapping (12 pages) RFC5222: LoST: A Location-to-Service Translation Protocol (69 pages) * Updates RFC6848 * Updates RFC8917 * Updates RFC9036 RFC5223: Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) (8 pages) RFC5582: Location-to-URL Mapping Architecture and Framework (17 pages) RFC5964: Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries (11 pages) RFC6197: Location-to-Service Translation (LoST) Service List Boundary Extension (15 pages) RFC6443: Framework for Emergency Calling Using Internet Multimedia (38 pages) * Updates RFC7852 RFC6444: Location Hiding: Problem Statement and Requirements (9 pages) RFC6739: Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol (25 pages) * Updates RFC8996 RFC6881: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) * Updates RFC7840 * Updates RFC7852 RFC7090: Public Safety Answering Point (PSAP) Callback (18 pages) RFC7163: URN for Country-Specific Emergency Services (4 pages) RFC7378: Trustworthy Location (31 pages) RFC7406: Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices (25 pages) RFC7840: A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol (16 pages) RFC7852: Additional Data Related to an Emergency Call (113 pages) RFC8147: Next-Generation Pan-European eCall (43 pages) RFC8148: Next-Generation Vehicle-Initiated Emergency Calls (40 pages) RFC8876: Non-interactive Emergency Calls (25 pages) RFC9036: Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy (4 pages) HTTP (httpbis) -------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Mark Nottingham Tommy Pauly Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: This Working Group is charged with maintaining and developing the "core" specifications for HTTP, and generic extensions to it (i.e., those that are not specific to one application). Its current work items are: # HTTP/1.1 Revision After the revision of the core HTTP document set in the RFC723x series, the Working Group published HTTP/2, which defines an alternative mapping of HTTP's semantics to TCP, and introduced new capabilities, like Server Push. Additionally, several ambiguities, interoperability issues and errata have been identified since their publication. The Working Group will revise the "core" HTTP document set (RFC 7230-RFC 7235) to: * Incorporate errata * Address ambiguities * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments # HTTP and QUIC Upon request from the QUIC Working Group, the HTTPBIS Working Group will review the QUIC Working Group's documents regarding the use of HTTP over the transport protocol they define, providing feedback and collaborating where necessary. Once the QUIC Working Group publishes the expression of HTTP semantics in QUIC (HTTP/3), the HTTPBIS Working Group will maintain and develop extensions for HTTP/3 as necessary. This includes ancillary specifications (e.g. QPACK). # Other HTTP-Related Work The Working Group may define extensions and other documents related to HTTP as work items, provided that: * They are generic; i.e., not specific to one application using HTTP. Note that Web browsing by definition is a generic use. * The Working Group Chairs judge that there is consensus to take on the item and believe that it will not interfere with the work described above, and * The Area Director approves the addition and add corresponding milestones. Goals and Milestones: - Submit RFC6265bis (Cookies) - Submit HTTP Representation Variants - Submit HTTP Alternative Services - Submit ORIGIN in HTTP/3 - Submit Retrofit Structured Fields - Submit HTTP Message Signatures - Submit The HTTP QUERY Method - Submit Client-Cert Header Done - Submit the "core" HTTP documents for consideration as Internet Standards Done - Submit Client Hints Done - Submit Structured Headers Done - Submit Building Protocols with HTTP (BCP56bis) Done - Submit Cache-Status Header Done - Submit Proxy-Status Header Done - Submit Digest Headers Done - Submit Binary Representation of HTTP Messages Internet-Drafts: - Client-Cert HTTP Header: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications [draft-bdc-something-something-certificate-05] (13 pages) - Secondary Certificate Authentication in HTTP/2 [draft-bishop-httpbis-http2-additional-certs-05] (21 pages) - The ORIGIN Extension in HTTP/3 [draft-bishop-httpbis-origin-h3-00] (3 pages) - Targeted HTTP Response Header Fields for Cache Control [draft-cdn-control-header-01] (8 pages) - Using TLS 1.3 with HTTP/2 [draft-davidben-http2-tls13-00] (4 pages) - The Key HTTP Response Header Field [draft-fielding-http-key-03] (17 pages) - HTTP Client Hints [draft-grigorik-http-client-hints-03] (11 pages) - Bootstrapping WebSockets with HTTP/3 [draft-hamilton-httpbis-h3-websockets-01] (4 pages) - HTTP Proxy-Status Parameter for Next-Hop Aliases [draft-ietf-httpbis-alias-proxy-status-03] (7 pages) - HTTP Alternative Services [draft-ietf-httpbis-alt-svc-14] (20 pages) - HTTP Authentication [draft-ietf-httpbis-auth-01] (4 pages) - HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields [draft-ietf-httpbis-auth-info-05] (6 pages) - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations [draft-ietf-httpbis-authscheme-registrations-10] (3 pages) - Building Protocols with HTTP [draft-ietf-httpbis-bcp56bis-15] (27 pages) - Binary Representation of HTTP Messages [draft-ietf-httpbis-binary-message-06] (16 pages) - HTTP Caching [draft-ietf-httpbis-cache-19] (35 pages) - Cache Digests for HTTP/2 [draft-ietf-httpbis-cache-digest-05] (17 pages) - The Cache-Status HTTP Response Header Field [draft-ietf-httpbis-cache-header-10] (9 pages) - Loop Detection in Content Delivery Networks (CDNs) [draft-ietf-httpbis-cdn-loop-02] (6 pages) - Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding [draft-ietf-httpbis-cice-03] (7 pages) - Client-Cert HTTP Header Field [draft-ietf-httpbis-client-cert-field-06] (19 pages) - HTTP Client Hints [draft-ietf-httpbis-client-hints-15] (10 pages) - HTTP Conditional Requests [draft-ietf-httpbis-conditional-01] (4 pages) - Template-Driven HTTP CONNECT Proxying for TCP [draft-ietf-httpbis-connect-tcp-00] (10 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-09] (14 pages) - Deprecate modification of 'secure' cookies from non-secure origins [draft-ietf-httpbis-cookie-alone-01] (6 pages) - Cookie Prefixes [draft-ietf-httpbis-cookie-prefixes-00] (6 pages) - Same-Site Cookies [draft-ietf-httpbis-cookie-same-site-00] (14 pages) - Digest Fields [draft-ietf-httpbis-digest-headers-12] (41 pages) - An HTTP Status Code for Indicating Hints [draft-ietf-httpbis-early-hints-05] (7 pages) - Encrypted Content-Encoding for HTTP [draft-ietf-httpbis-encryption-encoding-09] (16 pages) - Expect-CT Extension for HTTP [draft-ietf-httpbis-expect-ct-08] (18 pages) - Bootstrapping WebSockets with HTTP/2 [draft-ietf-httpbis-h2-websockets-07] (8 pages) - Bootstrapping WebSockets with HTTP/3 [draft-ietf-httpbis-h3-websockets-04] (4 pages) - HPACK: Header Compression for HTTP/2 [draft-ietf-httpbis-header-compression-12] (55 pages) - Structured Field Values for HTTP [draft-ietf-httpbis-header-structure-19] (30 pages) - Hypertext Transfer Protocol Version 2 (HTTP/2) [draft-ietf-httpbis-http2-17] (96 pages) - HTTP/2 [draft-ietf-httpbis-http2bis-07] (78 pages) - Opportunistic Security for HTTP/2 [draft-ietf-httpbis-http2-encryption-11] (10 pages) - Secondary Certificate Authentication in HTTP/2 [draft-ietf-httpbis-http2-secondary-certs-06] (27 pages) - Using TLS 1.3 with HTTP/2 [draft-ietf-httpbis-http2-tls13-03] (5 pages) - HTTP Immutable Responses [draft-ietf-httpbis-immutable-03] (6 pages) - A JSON Encoding for HTTP Header Field Values [draft-ietf-httpbis-jfv-02] (13 pages) - The Key HTTP Response Header Field [draft-ietf-httpbis-key-01] (17 pages) - An HTTP Status Code to Report Legal Obstacles [draft-ietf-httpbis-legally-restricted-status-04] (5 pages) - HTTP Message Signatures [draft-ietf-httpbis-message-signatures-17] (117 pages) - HTTP/1.1 [draft-ietf-httpbis-messaging-19] (46 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-15] (5 pages) - The ORIGIN HTTP/2 Frame [draft-ietf-httpbis-origin-frame-06] (11 pages) - The ORIGIN Extension in HTTP/3 [draft-ietf-httpbis-origin-h3-03] (5 pages) - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing [draft-ietf-httpbis-p1-messaging-26] (89 pages) - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [draft-ietf-httpbis-p2-semantics-26] (101 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-20] (3 pages) - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests [draft-ietf-httpbis-p4-conditional-26] (28 pages) - Hypertext Transfer Protocol (HTTP/1.1): Range Requests [draft-ietf-httpbis-p5-range-26] (25 pages) - Hypertext Transfer Protocol (HTTP/1.1): Caching [draft-ietf-httpbis-p6-cache-26] (43 pages) - Hypertext Transfer Protocol (HTTP/1.1): Authentication [draft-ietf-httpbis-p7-auth-26] (19 pages) - Extensible Prioritization Scheme for HTTP [draft-ietf-httpbis-priority-12] (21 pages) - The Proxy-Status HTTP Response Header Field [draft-ietf-httpbis-proxy-status-08] (22 pages) - HTTP Random Access and Live Content [draft-ietf-httpbis-rand-access-live-04] (10 pages) - HTTP Range Requests [draft-ietf-httpbis-range-01] (4 pages) - Using Early Data in HTTP [draft-ietf-httpbis-replay-04] (12 pages) - Resumable Uploads for HTTP [draft-ietf-httpbis-resumable-upload-01] (21 pages) - Retrofit Structured Fields for HTTP [draft-ietf-httpbis-retrofit-06] (13 pages) - Indicating Character Encoding and Language for HTTP Header Field Parameters [draft-ietf-httpbis-rfc5987bis-05] (13 pages) - Cookies: HTTP State Management Mechanism [draft-ietf-httpbis-rfc6265bis-12] (66 pages) - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) [draft-ietf-httpbis-rfc7238bis-03] (6 pages) - HTTP Alternative Services [draft-ietf-httpbis-rfc7838bis-00] (20 pages) - The HTTP QUERY Method [draft-ietf-httpbis-safe-method-w-body-03] (9 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - HTTP Semantics [draft-ietf-httpbis-semantics-19] (194 pages) - Structured Field Values for HTTP [draft-ietf-httpbis-sfbis-02] (39 pages) - Targeted HTTP Cache Control [draft-ietf-httpbis-targeted-cache-control-04] (8 pages) - The ALPN HTTP Header Field [draft-ietf-httpbis-tunnel-protocol-05] (7 pages) - HTTP Unprompted Authentication [draft-ietf-httpbis-unprompted-auth-02] (11 pages) - HTTP Representation Variants [draft-ietf-httpbis-variants-06] (23 pages) - Extensible Prioritization Scheme for HTTP [draft-kazuho-httpbis-priority-04] (20 pages) - Bootstrapping WebSockets with HTTP/2 [draft-mcmanus-httpbis-h2-websockets-02] (7 pages) - The ORIGIN HTTP/2 Frame [draft-nottingham-httpbis-origin-frame-01] (4 pages) - Retrofit Structured Fields for HTTP [draft-nottingham-http-structure-retrofit-02] (14 pages) - The Proxy-Status HTTP Header Field [draft-nottingham-proxy-status-00] (17 pages) - HTTP Proxy-Status Parameter for Next-Hop Aliases [draft-pauly-httpbis-alias-proxy-status-00] (5 pages) - The IP Geolocation HTTP Client Hint [draft-pauly-httpbis-geoip-hint-00] (6 pages) - Signing HTTP Messages [draft-richanna-http-message-signatures-00] (38 pages) - HTTP Unprompted Authentication [draft-schinazi-httpbis-unprompted-auth-01] (9 pages) - Template-Driven HTTP CONNECT Proxying for TCP [draft-schwartz-httpbis-connect-tcp-01] (8 pages) - HTTP SEARCH Method [draft-snell-search-method-02] (8 pages) - Reactive Certificate-Based Client Authentication in HTTP/2 [draft-thomson-http2-client-certs-02] (19 pages) - Binary Representation of HTTP Messages [draft-thomson-http-binary-message-01] (16 pages) - tus - Resumable Uploads Protocol [draft-tus-httpbis-resumable-uploads-protocol-02] (21 pages) - Incrementally Better Cookies [draft-west-cookie-incrementalism-01] (17 pages) - Same-site Cookies [draft-west-first-party-cookies-07] (14 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (14 pages) RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (89 pages) * Updates RFC8615 * Obsoletes RFC9110 * Obsoletes RFC9112 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (101 pages) * Obsoletes RFC9110 RFC7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (28 pages) * Obsoletes RFC9110 RFC7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests (25 pages) * Obsoletes RFC9110 RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching (43 pages) * Obsoletes RFC9111 RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication (19 pages) * Obsoletes RFC9110 RFC7236: Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations (3 pages) RFC7237: Initial Hypertext Transfer Protocol (HTTP) Method Registrations (5 pages) RFC7538: The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) (6 pages) * Obsoletes RFC9110 RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (96 pages) * Updates RFC8740 * Obsoletes RFC9113 RFC7541: HPACK: Header Compression for HTTP/2 (55 pages) RFC7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields (6 pages) * Obsoletes RFC9110 RFC7639: The ALPN HTTP Header Field (7 pages) RFC7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding (7 pages) * Obsoletes RFC9110 RFC7725: An HTTP Status Code to Report Legal Obstacles (5 pages) RFC7838: HTTP Alternative Services (20 pages) RFC8164: Opportunistic Security for HTTP/2 (10 pages) RFC8187: Indicating Character Encoding and Language for HTTP Header Field Parameters (13 pages) RFC8188: Encrypted Content-Encoding for HTTP (16 pages) RFC8246: HTTP Immutable Responses (6 pages) RFC8297: An HTTP Status Code for Indicating Hints (7 pages) RFC8336: The ORIGIN HTTP/2 Frame (11 pages) RFC8441: Bootstrapping WebSockets with HTTP/2 (8 pages) RFC8470: Using Early Data in HTTP (12 pages) RFC8586: Loop Detection in Content Delivery Networks (CDNs) (6 pages) RFC8673: HTTP Random Access and Live Content (10 pages) RFC8740: Using TLS 1.3 with HTTP/2 (5 pages) * Obsoletes RFC9113 RFC8941: Structured Field Values for HTTP (30 pages) RFC8942: HTTP Client Hints (10 pages) RFC9110: HTTP Semantics (194 pages) RFC9111: HTTP Caching (35 pages) RFC9112: HTTP/1.1 (46 pages) RFC9113: HTTP/2 (78 pages) RFC9163: Expect-CT Extension for HTTP (18 pages) RFC9205: Building Protocols with HTTP (27 pages) RFC9209: The Proxy-Status HTTP Response Header Field (22 pages) RFC9211: The Cache-Status HTTP Response Header Field (9 pages) RFC9213: Targeted HTTP Cache Control (8 pages) RFC9218: Extensible Prioritization Scheme for HTTP (21 pages) RFC9220: Bootstrapping WebSockets with HTTP/3 (4 pages) RFC9292: Binary Representation of HTTP Messages (16 pages) STD97: HTTP Semantics (194 pages) STD98: HTTP Caching (35 pages) STD99: HTTP/1.1 (46 pages) JSON Mail Access Protocol (jmap) -------------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Bron Gondwana Jim Fenton Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: jmap@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Description of Working Group: The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, beginning with calendars and contacts. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. The contact work will begin with a JSON format for contact data based upon the work begun in draft-stepanek-jscontact, and in consultation with other users of contact data within the IETF and outside to build an extensible format. Where possible, this format will retain the ability to convert backwards and forwards to RFC6350 vCard format. This format will then be used as the basis of JMAP object types for contacts. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over WSS (WebSocket over TLS, RFC 6455). Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - JSON formats for representing contacts and groups of contacts (JSContact) - JMAP access to addressbooks using the JSContact format - Accessing JMAP over Websockets - Handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - Other extensions which the working group considers related to email and compatible with the constraints listed above Also within scope for this working group are informational documents for converting between JMAP data representation and other formats already in wide use which can be used to specify the same underlying data. Goals and Milestones: Dec 2022 - Submit Sieve document to the IESG Dec 2022 - Submit JMAP Sharing document to IESG Feb 2023 - Adopt a draft for a basic migration simplified endpoint Mar 2023 - Submit SMIME Sender Extensions document to the IESG Jul 2023 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Jul 2023 - Submit JMAP Calendars document to the IESG Jul 2023 - Submit JMAP Tasks document to IESG Done - Adopt a document for a JSON Contact format (after recharter) Done - Submit Message Disposition Notification document to the IESG Done - Adopt a document defining mappings between VCARD and JSContact Done - Adopt a document for managing Sieve via JMAP Done - Submit JMAP S/MIME signature validation document to the IESG Done - Adopt a document for creating Blobs via JMAP method call Done - Adopt a document for S/MIME key management and server side signing/encryption Done - Submit JMAP Quotas document to the IESG Done - Submit document for Blobs via JMAP to the IESG Done - Adopt a document defining JMAP access to addressbooks Internet-Drafts: - JMAP for Tasks [draft-baum-jmap-tasks-00] (16 pages) - JMAP Blob management extension [draft-gondwana-jmap-blob-02] (10 pages) - JMAP Blob management extension [draft-ietf-jmap-blob-18] (30 pages) - JMAP for Calendars [draft-ietf-jmap-calendars-11] (54 pages) - JMAP for Contacts [draft-ietf-jmap-contacts-00] (9 pages) - The JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-core-17] (90 pages) - The JSON Meta Application Protocol (JMAP) for Mail [draft-ietf-jmap-mail-16] (108 pages) - Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-mdn-17] (13 pages) - JMAP for Quotas [draft-ietf-jmap-quotas-12] (11 pages) - JMAP Sharing [draft-ietf-jmap-sharing-03] (12 pages) - JMAP for Sieve Scripts [draft-ietf-jmap-sieve-14] (26 pages) - S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-smime-12] (10 pages) - JMAP extension for S/MIME signing and encryption [draft-ietf-jmap-smime-sender-extensions-03] (8 pages) - JMAP for Tasks [draft-ietf-jmap-tasks-06] (26 pages) - A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket [draft-ietf-jmap-websocket-07] (13 pages) Requests for Comments: RFC8620: The JSON Meta Application Protocol (JMAP) (90 pages) RFC8621: The JSON Meta Application Protocol (JMAP) for Mail (108 pages) RFC8887: A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket (13 pages) RFC9007: Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) (13 pages) RFC9219: S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) (10 pages) JSON Path (jsonpath) -------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: James Gruessing Tim Bray Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: jsonpath@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jsonpath Archive: https://mailarchive.ietf.org/arch/browse/jsonpath/ Description of Working Group: JSONPath is a syntax, originally based on the XML "XPath" design, which selects fields and values from a JSON document. It is used in a variety of applications which rely on JSON message formats. JSONPath was originally described by Stefan Goessner [1] but has never had an official specification of any kind, and the 39+ implementations, while mostly compatible, differ in certain behaviors. Note that while JSON Pointer (RFC 6901) is already standardised, it is designed to provide a reference to a single, specific part of a JSON document, whereas JSONPath provides the ability to query a document and potentially return multiple values. The WG will develop a standards-track JSONPath specification that is technically sound and complete, based on the common semantics and other aspects of existing implementations. Where there are differences, the working group will analyze those differences and make choices that rough consensus considers technically best, with an aim toward minimizing disruption among the different JSONPath implementations. Possible input documents are: * https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ * https://jsonpath-standard.github.io/internet-draft/ [1] https://goessner.net/articles/JsonPath/ Goals and Milestones: Sep 2022 - Submit "iregexp" specification to the IESG Nov 2022 - Standards Track document defining JSON Path to the IESG Internet-Drafts: - I-Regexp: An Interoperable Regexp Format [draft-bormann-jsonpath-iregexp-04] (10 pages) - JSONPath: Query expressions for JSON [draft-ietf-jsonpath-base-13] (64 pages) - I-Regexp: An Interoperable Regexp Format [draft-ietf-jsonpath-iregexp-07] (12 pages) - JavaScript Object Notation (JSON) Path [draft-normington-jsonpath-00] (21 pages) No Requests for Comments Media Over QUIC (moq) --------------------- Charter Last Modified: 2023-01-30 Current Status: Active Chairs: Alan Frindell Ted Hardie Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Tech Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: moq@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/moq Archive: https://mailarchive.ietf.org/arch/browse/moq/ Description of Working Group: Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently. The solution will be implementable in both browser and non-browser endpoints. The work focuses on building protocol mechanisms for publication of media and means to identify and receive the media. The media publication protocol will enable sending media including audio, video, and timed metadata, such as closed captions and cue points. The common protocol for publishing media for ingest and distribution will support: * one or more media formats * an interoperable way to indicate the media and the media format being sent * rate adaptation strategies based on changing codec rates, changing chosen media encoding/qualities, or other mechanisms * cache friendly media mechanisms The mechanism to name and receive media will enable: * Requesting the server start sending media related to a given point in the stream * Selection of desired encoding (choosing language, bit rate, etc.) Media will be mapped onto underlying QUIC mechanisms (QUIC streams and/or QUIC datagrams) and can be used over raw QUIC or WebTransport. The proposed solution will provide extensibility for supporting different media formats and will support multiple media types and media encodings. The working group will define MoQ so that the media publication protocol can leverage coordinating relays, caches, or replication points wherever applicable to improve the delivery performance. The solution will specify a simple method for clients to authenticate to the relay or server to transmit or receive media. Media will be encrypted at the transport layer using the standard QUIC mechanisms. Media content may be end-to-end encrypted in certain use cases, where the "end-to-end" keys are available to media sources and consumers, but not relays. Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on. Such media metadata will be authenticated and integrity-protected end-to-end. Mechanisms for establishing keys for these end-to-end protections are outside the scope of this group. This working group will not propose changes to the underlying QUIC transport, but may propose requirements for QUIC extensions to the QUIC WG. This working group will not define signaling mechanisms for discovery of relay or media producers or consumers. This working group will coordinate with the QUIC, WebTransport, and MOPS working groups as needed. It will liaise with MPEG Systems WG, DASH Industry Forum, and W3C WebTransport as appropriate. Goals and Milestones: Dec 2022 - WG adoption of Protocol Specification for Common Media Publication Protocol over QUIC Dec 2022 - WG adoption of Protocol Specification for the use of the Datagram Extension for Media Publication Protocol over QUIC Dec 2022 - WG adoption of Protocol Specification for Media Subscription Protocol over QUIC Dec 2022 - WG adoption of Architecture Specification for a Common Media Delivery Protocol over QUIC Dec 2022 - WG adoption of Use Cases and Requirements document for Media Delivery over QUIC Jun 2023 - Forward Protocol Specification for Common Media Publication Protocol over QUIC draft to IESG Jun 2023 - Forward Protocol Specification for the use of the Datagram Extension for Media Publication Protocol over QUIC draft to IESG Jun 2023 - Forward Protocol Specification for Media Subscription Protocol over QUIC draft to IESG Jun 2023 - Forward Architecture Specification for a Common Media Delivery Protocol over QUIC draft to IESG Internet-Drafts: No Requests for Comments Media Type Maintenance (mediaman) --------------------------------- Charter Last Modified: 2022-05-04 Current Status: Active Chair: Harald T. Alvestrand Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: media-types@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/media-types Archive: https://mailarchive.ietf.org/arch/browse/media-types/ Description of Working Group: IANA maintains a registry of media types and subtypes that are used to identify particular payloads and their semantics as they are transported via application level protocols such as messaging (“email”) and the web (HTTP). The core structure and use of media types is the MIME framework, defined in RFCs 2045 through 2049, and amended by various later documents. Registration of new media types is defined by BCP 13, which was last updated in 2013. The registration of a top-level media type is a rare event. BCP 13 describes the process for doing so, as was used in RFC 8081, but it does not provide any guidance or criteria regarding what constitutes an appropriate registration. Several other topics have appeared in the interim that are large enough in scope and importance to warrant the formation of a working group to develop and process them. This working group will therefore take up the following items, in this order (or as otherwise negotiated with the supervising Area Director): * Determine whether any specific criteria or guidance are warranted to handle registration of future top-level media types, and publish any such guidance. * Develop and process the pending ‘haptics’ top-level media type request, based on draft-muthusamy-dispatch-haptics, and the outcome of the previous work item. * Consider whether and how to permit multiple media type suffixes. * Develop a reviewer’s checklist regarding Security Considerations sections in media type applications. * Consider any issues around media types for programming languages and data definition languages such as YANG. * Review the format of the media types registry itself. * Evaluate the registry policies and procedures in the context of how media types are currently used, and modify them if necessary. This last item will consider the existing use of GitHub for managing registrations and the processing queues for the “link relations” and “well known URIs” registries as examples. Input Document(s): * draft-muthusamy-dispatch-haptics * draft-w3cdidwg-media-types-with-multiple-suffixes Proposed milestones (target dates TBD): * Publish any specific criteria or guidance for handling registration of future top-level media types, either as an RFC or a wiki page. * draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for approval (Proposed Standard) * A draft about handling multiple suffixes to the IESG for approval (BCP) * Publish a reviewer’s checklist about Security Considerations in media type applications, either as an RFC or a wiki page. * Deliver recommendations about the media types registry format. * Deliver any recommendations about future registration and queue management. Goals and Milestones: Jun 2023 - Publish any specific criteria or guidance for handling registration of future top-level media types, either as an RFC or a wiki page. Jul 2023 - Registration of the "haptics" top-level type to the IESG for approval (Proposed Standard) Aug 2023 - Draft about handling multiple suffixes to the IESG for approval (BCP) Sep 2023 - Publish a reviewer’s checklist about Security Considerations in media type applications, either as an RFC or a wiki page Oct 2023 - Deliver recommendations about the media types registry format Nov 2023 - Deliver any recommendations about future registration and queue management Internet-Drafts: - The 'haptics' Top-level Media Type [draft-ietf-mediaman-haptics-03] (12 pages) - Media Types with Multiple Suffixes [draft-ietf-mediaman-suffixes-03] (6 pages) - Guidelines for the Definition of New Top-Level Media Types [draft-ietf-mediaman-toplevel-03] (11 pages) No Requests for Comments More Instant Messaging Interoperability (mimi) ---------------------------------------------- Charter Last Modified: 2023-02-11 Current Status: Active Chairs: Alissa Cooper Tim Geoghegan Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mimi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mimi Archive: https://mailarchive.ietf.org/arch/browse/mimi/ Description of Working Group: The More Instant Messaging Interoperability (MIMI) working group will specify the minimal set of mechanisms required to make modern Internet messaging services interoperable. Over time, messaging services have achieved widespread use, their feature sets have broadened, and their adoption of end-to-end encryption (E2EE) has grown, but the lack of interoperability between these services continues to create a suboptimal user experience. The standards produced by the MIMI working group will allow for E2EE messaging services for both consumer and enterprise to interoperate without undermining the security guarantees that they provide. The working group will aim to achieve the strongest usable security and privacy properties for each targeted functional requirement. Recognizing the need for a standardized security protocol to support group key establishment, authentication, and confidentiality services for messaging, the IETF has specified the Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol] and architecture [I-D.ietf-mls-architecture]. MLS is agnostic to the identity system used within any given messaging service; it provides confidentiality of sessions once the participants in a conversation have been identified. To achieve interoperable messaging, the MIMI working group will specify how one or more identity building block technologies (for example, X.509 certificates or Verifiable Credentials) can be used to establish end-to-end cryptographic identity across messaging services, assuming the use of MLS for key establishment. Interoperable messaging in federated environments requires consensus on a common delivery service and a transport protocol between federated domains. Specifically, the MLS protocol requires ordering of handshake messages within groups to ensure clients can synchronize despite asynchronous message delivery. This working group will specify a flexible solution for transport and delivery that takes into account typical requirements and best practices from the industry. Achieving interoperable messaging among MIMI-compliant services requires a solution for the introduction problem, i.e., the ability for a user in one application to take an identity of a target user along with the associated application, be granted permission to initiate communications, and be able to establish communications with the target. The working group will specify a solution to the introduction problem, together with best practice recommendations for functionality, configuration options, and other aspects. The working group may also choose to specify a solution to discover the set of preferred messaging services associated with a given identity. Express and implied user preferences about discoverability and reachability must be respected. Modern messaging services commonly support numerous features including plain and rich text, delivery notifications, read receipts, replies, reactions, presence, and many more. The working group will identify an extensible baseline set of messaging features and specify a content format to allow this feature set to be implemented interoperably. This format must be usable in the presence of E2EE. In defining the format, the working group will seek to reuse existing primitives (especially existing semantics) including previously defined message headers, MIME types, and URIs where practical. In its initial phase, the working group will focus on solutions for messaging. The working group will aim for general-purpose designs fit for both 1:1 and multiparty messaging. The working group will not standardize new audio/video signaling or media protocols but may recommend the use of existing protocols and suites such as SIP and WebRTC. The following are out of scope for the working group: * Metadata processing to manage spam and abuse * Interoperable mechanisms for group administration or moderation across systems * Extensions to the MLS protocol. If needed, requirements will be referred to the MLS working group or other relevant working groups in the security area. * Definition of completely new identity formats or protocols. * Extensions to SIP, SDP, MSRP, or WebRTC. * Development of anti-spam or anti-abuse algorithms. * Oracle or look-up services that reveal the list of messaging services associated with a given user identity without the user's permission. Numerous prior attempts have been made to address messaging interoperability, including the IETF's extensive prior work on XMPP, SIP/SIMPLE, and their related messaging formats. The MIMI working group will draw lessons from these prior attempts, seek to avoid re-hashing old debates, and will focus on the minimal standards suite necessary to facilitate interoperability given the feature set of modern messaging applications. MIMI will communicate with related working groups as needed, including MLS, STIR, OAUTH, GNAP, and the W3C Verifiable Credentials WG. Goals and Milestones: Mar 2023 - WG adoption of framework document for messaging interoperability Mar 2023 - WG adoption of requirements document for messaging interoperability (decision about whether to forward to IESG for publication to be made later, by WG consensus) Apr 2023 - WG adoption of specification for identifier naming conventions Apr 2023 - WG adoption of specification for establishment of end-to-end cryptographic identity May 2023 - WG adoption of specification for delivery service and transport mechanisms May 2023 - WG adoption of specification of MLS profile Jun 2023 - WG adoption of specification for messaging content format Jun 2023 - WG adoption of specification for user discovery mechanism Dec 2023 - Forward framework document for messaging interoperability to IESG Dec 2023 - Forward specification for identifier naming conventions to IESG Jan 2024 - Forward specification for establishment of end-to-end cryptographic identity to IESG Jan 2024 - Forward specification for delivery service and transport mechanisms to IESG Feb 2024 - Forward specification of MLS profile to IESG Feb 2024 - Forward specification for messaging content format to IESG Mar 2024 - Forward specification for user discovery mechanism to IESG Internet-Drafts: - More Instant Messaging Interoperability (MIMI) message content [draft-mahy-mimi-content-02] (23 pages) No Requests for Comments Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2022-05-04 Current Status: Active Chairs: Bo Burman Flemming Andreasen Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mmusic@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mmusic Archive: https://mailarchive.ietf.org/arch/browse/mmusic/ Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was originally chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployment. Currently, the group is focused on using and negotiating media streams with the Session Description Protocol (SDP), which is used as a common protocol to express media and session descriptions. The group also maintains the Real-time Streaming Protocol (RTSP) specifications. The group has revised these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVTCORE, CLUE, ICE, and RTCWEB). In particular, the many uses of SDP have led to requests for numerous extensions as well as a recognition of several limitations in the original protocol design. Today, the SDP protocol is widely deployed and continues to see extensions being defined. The current aims of the working group include the following: - Provide SDP signaling support for the Interactive Connectivity Establishment (ICE) protocol and its extensions. These were originally defined in MMUSIC, but are now handled by the ICE WG. - To support the establishment of multi-party multimedia sessions for RTCWEB based implementations, MMUSIC provides SDP signaling support for a number of extensions required by RTCWEB. The MMUSIC WG will seek a balanced trade-off between general applicability of such extensions versus RTCWEB specific usage. - Various other extensions to SDP may be pursued to remedy the most urgent of SDP's shortcomings. These include updates to the SDP specification itself and missing IANA registrations. - With the exception of the items listed above, only extensions within the existing SDP framework will be done. - Maintain the specification of the (revised) Real Time Streaming Protocol (RTSP) as needed. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVTCORE, CLUE, ICE, RTCWEB and SIPCORE, as well as others where appropriate. Goals and Milestones: Jul 2021 - Submit Using Multicast DNS to protect privacy when exposing ICE candidates as Informational Done - Submit a framework for SDP attributes when multiplexing as Proposed Standard Done - Submit IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles as Proposed Standard Done - Submit SDP extension for cross session stream identification as Proposed Standard Done - Submit Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP as Proposed Standard Done - Submit SCTP-Based Media Transport in SDP as Proposed Standard. Done - Using the SDP Offer/Answer Mechanism for DTLS Done - Submit RTP Payload Format Constraints as Proposed Standard Done - Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard Done - Submit SIP usage for Trickle ICE as Proposed Standard Done - Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard Done - Submit revised SDP specification to IETF as Proposed Standard Done - Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard Done - Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard Done - Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Proposed Standard Done - Submit T.140 Real-time Text Conversation over WebRTC Data Channels as Proposed Standard Done - Submit SDP Negotiation of MSRP over Data Channels as Proposed Standard Done - Submit RFC 8843bis (Negotiating Media Multiplexing Using the Session Description Protocol (SDP)) as Proposed Standard Internet-Drafts: - T.140 Real-time Text Conversation over WebRTC Data Channels [draft-holmberg-mmusic-t140-usage-data-channel-02] (16 pages) - Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile [draft-hutton-mmusic-opportunistic-negotiation-00] (6 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-4572-update-13] (18 pages) - Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism [draft-ietf-mmusic-agree-00] (29 pages) - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-anat-02] (7 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-comedia-tls-06] (17 pages) - The Internet Multimedia Conferencing Architecture [draft-ietf-mmusic-confarch-03] (28 pages) - Connection-Establishment Preconditions in the Session Initiation Protocol (SIP) [draft-ietf-mmusic-connection-precon-01] (8 pages) - Connectivity Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-connectivity-precon-07] (17 pages) - Negotiation Data Channels Using the Session Description Protocol (SDP) [draft-ietf-mmusic-data-channel-sdpneg-28] (24 pages) - Signaling Media Decoding Dependency in the Session Description Protocol (SDP) [draft-ietf-mmusic-decoding-dependency-08] (18 pages) - Duplication Delay Attribute in the Session Description Protocol [draft-ietf-mmusic-delayed-duplication-03] (11 pages) - Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) [draft-ietf-mmusic-dtls-sdp-32] (19 pages) - Duplication Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-duplication-grouping-04] (10 pages) - Forward Error Correction Grouping Semantics in Session Description Protocol [draft-ietf-mmusic-fec-grouping-05] (6 pages) - Grouping of Media Lines in the Session Description Protocol (SDP) [draft-ietf-mmusic-fid-06] (11 pages) - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer [draft-ietf-mmusic-file-transfer-mech-11] (50 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols [draft-ietf-mmusic-ice-19] (117 pages) - ICE Multihomed and IPv4/IPv6 Dual Stack Fairness [draft-ietf-mmusic-ice-dualstack-fairness-02] (10 pages) - IANA Registry for Interactive Connectivity Establishment (ICE) Options [draft-ietf-mmusic-ice-options-registry-02] (5 pages) - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-sip-sdp-39] (38 pages) - TCP Candidates with Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-tcp-16] (29 pages) - Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-image-attributes-11] (23 pages) - A Framework for the Usage of Internet Media Guides (IMGs) [draft-ietf-mmusic-img-framework-09] (22 pages) - Requirements for Internet Media Guides (IMGs) [draft-ietf-mmusic-img-req-08] (23 pages) - Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-kmgmt-ext-15] (30 pages) - Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication [draft-ietf-mmusic-latching-08] (16 pages) - An Mbus Profile for Call Control [draft-ietf-mmusic-mbus-call-control-00] (37 pages) - The Message Bus: Guidelines for Application Profile Writers [draft-ietf-mmusic-mbus-guidelines-00] (49 pages) - Requirements for Local Conference Control [draft-ietf-mmusic-mbus-req-00] (10 pages) - A Message Bus for Local Coordination [draft-ietf-mmusic-mbus-transport-06] (39 pages) - Using Multicast DNS to protect privacy when exposing ICE candidates [draft-ietf-mmusic-mdns-ice-candidates-03] (20 pages) - An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback [draft-ietf-mmusic-media-loopback-27] (33 pages) - Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path [draft-ietf-mmusic-media-path-middleboxes-07] (20 pages) - WebRTC MediaStream Identification in the Session Description Protocol [draft-ietf-mmusic-msid-17] (12 pages) - Message Session Relay Protocol (MSRP) over Data Channels [draft-ietf-mmusic-msrp-usage-data-channel-24] (17 pages) - Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP) [draft-ietf-mmusic-mux-exclusive-12] (9 pages) - Short term NAT requirements for UDP based peer-to-peer applications [draft-ietf-mmusic-natreq4udp-00] (6 pages) - Session Description Protocol (SDP) Offer/Answer Examples [draft-ietf-mmusic-offer-answer-examples-06] (24 pages) - Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile [draft-ietf-mmusic-opportunistic-negotiation-01] (7 pages) - SDP attribute to signal parallax [draft-ietf-mmusic-parallax-attribute-00] (15 pages) - Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles [draft-ietf-mmusic-proto-iana-registration-06] (7 pages) - Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) [draft-ietf-mmusic-qos-identification-03] (9 pages) - Mapping of Media Streams to Resource Reservation Flows [draft-ietf-mmusic-reservation-flows-01] (6 pages) - Real-Time Streaming Protocol Version 2.0 [draft-ietf-mmusic-rfc2326bis-40] (318 pages) - The Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-rfc3388bis-04] (21 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-rfc4566bis-37] (57 pages) - Forward Error Correction Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-rfc4756bis-10] (14 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal [draft-ietf-mmusic-rfc5245bis-05] (91 pages) - Negotiating Media Multiplexing Using the Session Description Protocol (SDP) [draft-ietf-mmusic-rfc8843bis-09] (54 pages) - RTP Payload Format Restrictions [draft-ietf-mmusic-rid-15] (26 pages) - Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-08] (92 pages) - RTSP Announce Method [draft-ietf-mmusic-rtsp-announce-01] (0 pages) - A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-22] (33 pages) - Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-evaluation-16] (46 pages) - SAP: Session Announcement Protocol [draft-ietf-mmusic-sap-00] (14 pages) - SAP Security Using Public Key Algorithms [draft-ietf-mmusic-sap-sec-04] (18 pages) - Session Announcement Protocol [draft-ietf-mmusic-sap-v2-06] (18 pages) - Simple Conference Control Protocol [draft-ietf-mmusic-sccp-01] (24 pages) - Simple Conference Invitation Protocol [draft-ietf-mmusic-scip-00] (18 pages) - Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport [draft-ietf-mmusic-sctp-sdp-26] (21 pages) - Session Description Protocol (SDP) Security Descriptions for Media Streams [draft-ietf-mmusic-sdescriptions-12] (44 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-06] (42 pages) - Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp4nat-05] (8 pages) - Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections [draft-ietf-mmusic-sdp-atm-05] (110 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-mmusic-sdp-bfcp-03] (12 pages) - Negotiating Media Multiplexing Using the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bundle-negotiation-54] (50 pages) - A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bwparam-06] (22 pages) - Session Description Protocol (SDP) Capability Negotiation [draft-ietf-mmusic-sdp-capability-negotiation-13] (77 pages) - SDP Capability Negotiation: Requirements and Review of Existing Work [draft-ietf-mmusic-sdp-capability-negotiation-reqts-01] (23 pages) - TCP-Based Media Transport in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-comedia-10] (15 pages) - Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) [draft-ietf-mmusic-sdp-cs-23] (39 pages) - Describing session directories in SDP [draft-ietf-mmusic-sdp-directory-type-02] (0 pages) - Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-sdp-dtls-00] (8 pages) - Offer/Answer Considerations for G.723 Annex A and G.729 Annex B [draft-ietf-mmusic-sdp-g273-g729-00] (8 pages) - Offer/Answer Considerations for G723 Annex A and G729 Annex B [draft-ietf-mmusic-sdp-g723-g729-06] (8 pages) - Implementation Status Of SDP [draft-ietf-mmusic-sdp-implem-00] (18 pages) - Support for IPv6 in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-ipv6-03] (5 pages) - Session Description Protocol (SDP) Media Capabilities Negotiation [draft-ietf-mmusic-sdp-media-capabilities-17] (55 pages) - The Session Description Protocol (SDP) Content Attribute [draft-ietf-mmusic-sdp-media-content-06] (11 pages) - The Session Description Protocol (SDP) Label Attribute [draft-ietf-mmusic-sdp-media-label-01] (8 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-misc-cap-00] (17 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-miscellaneous-caps-07] (22 pages) - A Framework for Session Description Protocol (SDP) Attributes When Multiplexing [draft-ietf-mmusic-sdp-mux-attributes-19] (82 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-new-26] (49 pages) - Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-08] (61 pages) - Requirements for Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-req-01] (24 pages) - SDPng Transition [draft-ietf-mmusic-sdpng-trans-04] (15 pages) - An Offer/Answer Model with Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-offer-answer-02] (25 pages) - Establishing QoS and Security Preconditions for SDP Sessions [draft-ietf-mmusic-sdp-qos-00] (13 pages) - Using Simulcast in Session Description Protocol (SDP) and RTP Sessions [draft-ietf-mmusic-sdp-simulcast-14] (30 pages) - Source-Specific Media Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-source-attributes-02] (18 pages) - Session Description Protocol (SDP) Source Filters [draft-ietf-mmusic-sdp-srcfilter-10] (14 pages) - SDP Extensions for Fax over IP Using T.38 [draft-ietf-mmusic-sdp-t38-00] (4 pages) - TCP-Based Media Transport in SDP [draft-ietf-mmusic-sdp-tcpmedia-00] (9 pages) - Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-uks-07] (17 pages) - Security Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-securityprecondition-04] (16 pages) - Signal 3D format [draft-ietf-mmusic-signal-3d-format-00] (27 pages) - SIP: Session Initiation Protocol [draft-ietf-mmusic-sip-12] (151 pages) - Reliability of Provisional Responses in SIP [draft-ietf-mmusic-sip-100rel-01] (12 pages) - SIP Caller Preferences and Callee Capabilities [draft-ietf-mmusic-sip-caller-00] (16 pages) - SIP Call Control Services [draft-ietf-mmusic-sip-cc-01] (34 pages) - The SIP INFO Method [draft-ietf-mmusic-sip-info-method-01] (6 pages) - The SIP ISUP/MIME type [draft-ietf-mmusic-sip-isup-mime-00] (4 pages) - The multipart/sip-id media type [draft-ietf-mmusic-sip-multipart-00] (4 pages) - SIP Security Using Public Key Algorithms [draft-ietf-mmusic-sip-sec-00] (24 pages) - SIP Session Timer [draft-ietf-mmusic-sip-session-timer-02] (12 pages) - SIP URL Scheme [draft-ietf-mmusic-sip-url-00] (3 pages) - A real-time stream control protocol (RTSP') [draft-ietf-mmusic-stream-00] (25 pages) - T.140 Real-Time Text Conversation over WebRTC Data Channels [draft-ietf-mmusic-t140-usage-data-channel-14] (18 pages) - The Session Description Protocol (SDP) 'trafficclass' Attribute [draft-ietf-mmusic-traffic-class-for-sdp-05] (29 pages) - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol [draft-ietf-mmusic-trickle-ice-02] (25 pages) - A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) [draft-ietf-mmusic-trickle-ice-sip-18] (34 pages) - UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-udptl-dtls-10] (23 pages) Requests for Comments: RFC2326: Real Time Streaming Protocol (RTSP) (92 pages) * Obsoletes RFC7826 RFC2327: SDP: Session Description Protocol (42 pages) * Obsoletes RFC4566 * Updates RFC3266 RFC2543: SIP: Session Initiation Protocol (151 pages) * Obsoletes RFC3261 * Obsoletes RFC3262 * Obsoletes RFC3263 * Obsoletes RFC3264 * Obsoletes RFC3265 RFC2974: Session Announcement Protocol (18 pages) RFC3108: Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections (110 pages) RFC3259: A Message Bus for Local Coordination (39 pages) RFC3264: An Offer/Answer Model with Session Description Protocol (SDP) (25 pages) * Updates RFC6157 * Updates RFC8843 * Updates RFC9143 RFC3266: Support for IPv6 in Session Description Protocol (SDP) (5 pages) * Obsoletes RFC4566 RFC3388: Grouping of Media Lines in the Session Description Protocol (SDP) (11 pages) * Obsoletes RFC5888 RFC3524: Mapping of Media Streams to Resource Reservation Flows (6 pages) RFC3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) (8 pages) RFC3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (22 pages) RFC4091: The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (7 pages) * Obsoletes RFC5245 RFC4145: TCP-Based Media Transport in the Session Description Protocol (SDP) (15 pages) * Updates RFC4572 RFC4317: Session Description Protocol (SDP) Offer/Answer Examples (24 pages) RFC4435: A Framework for the Usage of Internet Media Guides (IMGs) (22 pages) RFC4473: Requirements for Internet Media Guides (IMGs) (23 pages) RFC4566: SDP: Session Description Protocol (49 pages) * Obsoletes RFC8866 RFC4567: Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) (30 pages) RFC4568: Session Description Protocol (SDP) Security Descriptions for Media Streams (44 pages) RFC4570: Session Description Protocol (SDP) Source Filters (14 pages) RFC4572: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (17 pages) * Obsoletes RFC8122 RFC4574: The Session Description Protocol (SDP) Label Attribute (8 pages) RFC4583: Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (12 pages) * Obsoletes RFC8856 RFC4756: Forward Error Correction Grouping Semantics in Session Description Protocol (6 pages) * Obsoletes RFC5956 RFC4796: The Session Description Protocol (SDP) Content Attribute (11 pages) RFC5027: Security Preconditions for Session Description Protocol (SDP) Media Streams (16 pages) RFC5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols (117 pages) * Updates RFC6336 * Obsoletes RFC8445 * Obsoletes RFC8839 RFC5432: Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) (9 pages) RFC5547: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer (50 pages) RFC5576: Source-Specific Media Attributes in the Session Description Protocol (SDP) (18 pages) RFC5583: Signaling Media Decoding Dependency in the Session Description Protocol (SDP) (18 pages) RFC5888: The Session Description Protocol (SDP) Grouping Framework (21 pages) * Updates RFC8843 * Updates RFC9143 RFC5898: Connectivity Preconditions for Session Description Protocol (SDP) Media Streams (17 pages) RFC5939: Session Description Protocol (SDP) Capability Negotiation (77 pages) * Updates RFC6871 RFC5956: Forward Error Correction Grouping Semantics in the Session Description Protocol (14 pages) RFC6236: Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) (23 pages) RFC6336: IANA Registry for Interactive Connectivity Establishment (ICE) Options (5 pages) * Obsoletes RFC8839 RFC6544: TCP Candidates with Interactive Connectivity Establishment (ICE) (29 pages) RFC6849: An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback (33 pages) RFC6871: Session Description Protocol (SDP) Media Capabilities Negotiation (55 pages) RFC7006: Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) (22 pages) RFC7104: Duplication Grouping Semantics in the Session Description Protocol (10 pages) RFC7195: Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) (39 pages) RFC7197: Duplication Delay Attribute in the Session Description Protocol (11 pages) RFC7261: Offer/Answer Considerations for G723 Annex A and G729 Annex B (8 pages) RFC7345: UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) (23 pages) * Updates RFC8842 RFC7362: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication (16 pages) RFC7604: Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) (46 pages) RFC7825: A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) (33 pages) RFC7826: Real-Time Streaming Protocol Version 2.0 (318 pages) RFC7850: Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles (7 pages) RFC8122: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (18 pages) * Updates RFC8844 RFC8830: WebRTC MediaStream Identification in the Session Description Protocol (12 pages) RFC8839: Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE) (38 pages) RFC8840: A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) (34 pages) RFC8841: Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport (21 pages) RFC8842: Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) (19 pages) RFC8843: Negotiating Media Multiplexing Using the Session Description Protocol (SDP) (50 pages) * Obsoletes RFC9143 RFC8844: Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP) (17 pages) RFC8851: RTP Payload Format Restrictions (26 pages) RFC8853: Using Simulcast in Session Description Protocol (SDP) and RTP Sessions (30 pages) RFC8858: Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP) (9 pages) RFC8859: A Framework for Session Description Protocol (SDP) Attributes When Multiplexing (82 pages) RFC8864: Negotiation Data Channels Using the Session Description Protocol (SDP) (24 pages) RFC8865: T.140 Real-Time Text Conversation over WebRTC Data Channels (18 pages) RFC8866: SDP: Session Description Protocol (57 pages) RFC8873: Message Session Relay Protocol (MSRP) over Data Channels (17 pages) RFC9143: Negotiating Media Multiplexing Using the Session Description Protocol (SDP) (54 pages) Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Sean Turner Ted Hardie Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: rtcweb@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Archive: https://mailarchive.ietf.org/arch/browse/rtcweb/ Description of Working Group: The RTCWEB working group was originally chartered to standardize mechanisms that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers, without requiring non-standard extensions or proprietary plug-ins. The result was a set of RFCs from RTCWEB, in addition to many other RFCs from other working groups, all of which are interrelated and had to be published together in what the RFC Editor refers to as a “cluster”. In the end, that cluster comprised more than 40 RFCs and was finally published in January 2021. During the run-up to publication of the cluster, a contradiction was identified between what became RFCs 8829 and 8843. A description of this contradiction was added to both documents to highlight the problem, and state our intention to proceed with publication but quickly initiate an effort to publish updates to the affected documents. The key part of the added text was as follows: “The specific issue involves the handling of "m=" sections that are designated as bundle-only, as discussed in Section 4.1.1 of [RFC 8829]. Currently, there is divergence between JSEP and BUNDLE, as well as between these specifications and existing browser implementations …” The working group is being reconstituted to take up this contradiction, come to consensus on a resolution, and issue Standards Track updates for those two documents. Specifically, the goal of this work is to address only the contradictions regarding "bundle-only" between BUNDLE and JSEP. The resulting aligned solution should avoid impacting the interoperability with SDP Offer/Answer. Finally, the impact on existing implementations that are affected by any change is to be considered. draft-ietf-rtcweb-sdp, which has not yet been published, will be returned to the working group to be updated according to the resolution of the issue described above. The working group will therefore produce updates to the JSEP and BUNDLE documents, and re-submit draft-ietf-rtcweb-sdp for publication after it has been revised. Updating any other document, or taking up any other issue, is out of scope and will require IESG approval via rechartering. Coordination with the MMUSIC working group to develop this solution will be required. Goals and Milestones: Aug 2021 - Update to draft-ietf-rtcweb-sdp to the IESG as Informational. Aug 2021 - Updates to the JSEP and BUNDLE documents to the IESG as Proposed Standard. Internet-Drafts: - WebRTC Gateways [draft-alvestrand-rtcweb-gateways-02] (5 pages) - Overview: Real Time Protocols for Brower-based Applications [draft-alvestrand-rtcweb-overview-01] (14 pages) - Web Real-Time Communication Use-cases and Requirements [draft-holmberg-rtcweb-ucreqs-01] (11 pages) - Application-Layer Protocol Negotiation (ALPN) for WebRTC [draft-ietf-rtcweb-alpn-04] (6 pages) - WebRTC Audio Codec and Processing Requirements [draft-ietf-rtcweb-audio-11] (7 pages) - Additional WebRTC Audio Codecs for Interoperability [draft-ietf-rtcweb-audio-codecs-for-interop-06] (12 pages) - IANA Registry for RTCWeb Constrainable Properties [draft-ietf-rtcweb-constraints-registry-03] (5 pages) - WebRTC Data Channels [draft-ietf-rtcweb-data-channel-13] (14 pages) - WebRTC Data Channel Establishment Protocol [draft-ietf-rtcweb-data-protocol-09] (12 pages) - WebRTC Forward Error Correction Requirements [draft-ietf-rtcweb-fec-10] (10 pages) - WebRTC Gateways [draft-ietf-rtcweb-gateways-02] (7 pages) - WebRTC IP Address Handling Requirements [draft-ietf-rtcweb-ip-handling-12] (9 pages) - JavaScript Session Establishment Protocol (JSEP) [draft-ietf-rtcweb-jsep-26] (95 pages) - Overview: Real-Time Protocols for Browser-Based Applications [draft-ietf-rtcweb-overview-19] (17 pages) - DSCP and other packet markings for RTCWeb QoS [draft-ietf-rtcweb-qos-00] (10 pages) - Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC [draft-ietf-rtcweb-return-02] (18 pages) - Media Transport and Use of RTP in WebRTC [draft-ietf-rtcweb-rtp-usage-26] (39 pages) - Annotated Example SDP for WebRTC [draft-ietf-rtcweb-sdp-14] (129 pages) - Security Considerations for WebRTC [draft-ietf-rtcweb-security-12] (21 pages) - WebRTC Security Architecture [draft-ietf-rtcweb-security-arch-20] (35 pages) - Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness [draft-ietf-rtcweb-stun-consent-freshness-16] (10 pages) - Transports for WebRTC [draft-ietf-rtcweb-transports-17] (13 pages) - Web Real-Time Communication Use Cases and Requirements [draft-ietf-rtcweb-use-cases-and-requirements-16] (28 pages) - WebRTC Video Processing and Codec Requirements [draft-ietf-rtcweb-video-06] (10 pages) - Using Multicast DNS to protect privacy when exposing ICE candidates [draft-mdns-ice-candidates-00] (6 pages) - STUN Usage for Consent Freshness [draft-muthu-behave-consent-freshness-04] (7 pages) - SDP for the WebRTC [draft-nandakumar-rtcweb-sdp-08] (104 pages) - Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC [draft-schwartz-rtcweb-return-06] (18 pages) - WebRTC IP Address Handling Recommendations [draft-shieh-rtcweb-ip-handling-00] (6 pages) - JavaScript Session Establishment Protocol (JSEP) [draft-uberti-rtcweb-rfc8829bis-04] (106 pages) Requests for Comments: RFC7478: Web Real-Time Communication Use Cases and Requirements (28 pages) RFC7675: Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness (10 pages) RFC7742: WebRTC Video Processing and Codec Requirements (10 pages) RFC7874: WebRTC Audio Codec and Processing Requirements (7 pages) RFC7875: Additional WebRTC Audio Codecs for Interoperability (12 pages) RFC8825: Overview: Real-Time Protocols for Browser-Based Applications (17 pages) RFC8826: Security Considerations for WebRTC (21 pages) RFC8827: WebRTC Security Architecture (35 pages) RFC8828: WebRTC IP Address Handling Requirements (9 pages) RFC8829: JavaScript Session Establishment Protocol (JSEP) (95 pages) RFC8831: WebRTC Data Channels (14 pages) RFC8832: WebRTC Data Channel Establishment Protocol (12 pages) RFC8833: Application-Layer Protocol Negotiation (ALPN) for WebRTC (6 pages) RFC8834: Media Transport and Use of RTP in WebRTC (39 pages) RFC8835: Transports for WebRTC (13 pages) RFC8854: WebRTC Forward Error Correction Requirements (10 pages) Registration Protocols Extensions (regext) ------------------------------------------ Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Antoin Verschuren James Galvin Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: regext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/regext Archive: https://mailarchive.ietf.org/arch/browse/regext/ Description of Working Group: Charter for Working Group The Extensible Provisioning Protocol (EPP, Standard 69) is the standard domain name provisioning protocol for top-level domain name registries. To avoid many separate EPP extensions that provide the same functions, it's important to coordinate and standardize EPP extensions. The EPP Extensions (EPPEXT) working group completed its first goal of creating an IANA registry of EPP extensions. The registration process of the registry is documented in RFC 7451. Extensions may be registered for informational purposes as long as there is a published specification that has been reviewed by a designated expert. The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the proposed standard for retrieving registration metadata from both domain name and Regional Internet Registries. To ensure interoperable implementations it's important to coordinate and standardize extensions and profiles to be used by registries. Extensions in both cases that are targeted for the Standards Track are subject to more thorough review and open discussion within the IETF. In addition, commonality may be discovered in related extensions, especially EPP extensions listed on the EPP extension registry, for which it would makes sense to merge them into a single standard extension everybody agrees on. The REGEXT working group is the home of the coordination effort for standards track extensions. The selection of extensions for standards track shall incorporate the following guidelines. 1. Proprietary documented extensions and individual submissions of informational or experimental EPP extensions will follow the expert review process as described in RFC 7451 for inclusion in the EPP extensions registry. These documents will not be part of the REGEXT working group work or milestones. The working group may discuss or advise on these documents. 2. Extensions that seek standards track status can be suggested for WG adoption. If accepted by the working group then the development of the standard may proceed. 3. When there are no more proposals for Standards-Track extensions, the working group will either close or become dormant, with the decision made in consultation with the responsible AD. In any case, the mailing list will remain open and available for the use of the expert review process as described in RFC 7451. The working group may also take on work to develop specifications that describe the following types of information exchanged between entities involved in Internet identifier registration that are using the RDAP or EPP protocols: * Uniform representation formats for publishing local policy or configuration options regarding EPP and RDAP use. * Data formats for files exchanged between registration entities that need insertion in or extraction from EPP or RDAP. * Technical guidance for registration processes that are supported by EPP or RDAP. Goals and Milestones: Mar 2023 - Submit for publication "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses" Mar 2023 - Submit for publication "Redacted Fields in the Registration Data Access Protocol (RDAP) Response" Jun 2023 - Submit for publication "DNS Data Dictionary" Jul 2023 - Submit for publication "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect" Jul 2023 - Submit for publication "Simple Registration Reporting" Sep 2023 - Submit for publication "RDAP RIR Search" Done - Submit for publication "Change Poll Extension for EPP" Done - Submit for publication "Registry Fee Extension for EPP" Done - Submit for publication "EPP Domain Name Mapping Extension for Bundling Registration" Done - Submit for publication "Login Security Extension for the Extensible Provisioning Protocol (EPP)" Done - Submit for publication "Registry Data Escrow Specification" Done - Submit for publication "Domain Name Registration Data (DNRD) Objects Mapping" Done - Submit for publication "Registration Data Access Protocol (RDAP) Partial Response" Done - Submit for publication "Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging" Done - Submit for publication "EPP Unhandled Namespaces" Done - Submit for publication "EPP Secure Authorization Information for Transfer" Done - Submit for publication "Registration Data Access Protocol (RDAP) Query Format" Done - Submit for publication "JSON Responses for the Registration Data Access Protocol (RDAP)" Done - Submit for publication "Registry Maintenance Notifications for the EPP" Done - Submit for publication "Finding the Authoritative Registration Data (RDAP) Service" Done - Submit for publication "Use of Internationalized Email Addresses in EPP protocol" Done - Submit for publication "Registration Data Access Protocol (RDAP) Reverse search capabilities" Internet-Drafts: - Use of Internationalized Email Addresses in EPP protocol [draft-belyavskiy-epp-eai-04] (10 pages) - Finding the Authoritative Registration Data (RDAP) Service [draft-blanchet-regext-rfc7484bis-00] (17 pages) - DNS Data Dictionary [draft-flanagan-regext-datadictionary-01] (13 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-gould-casanova-regext-unhandled-namespaces-02] (18 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-gould-regext-secure-authinfo-transfer-03] (24 pages) - RDAP RIR Search [draft-harrison-regext-rdap-rir-search-00] (8 pages) - Registration Data Access Protocol (RDAP) Query Format [draft-hollenbeck-regext-rfc7482bis-06] (25 pages) - JSON Responses for the Registration Data Access Protocol (RDAP) [draft-hollenbeck-regext-rfc7483bis-01] (85 pages) - Key Relay Mapping for the Extensible Provisioning Protocol [draft-ietf-eppext-keyrelay-12] (16 pages) - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-eppext-launchphase-07] (61 pages) - ICANN TMCH functional specifications [draft-ietf-eppext-tmch-func-spec-01] (60 pages) - Allocation Token Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-allocation-token-12] (17 pages) - Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration [draft-ietf-regext-bundling-registration-11] (25 pages) - Change Poll Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-change-poll-12] (20 pages) - Registration Data Dictionary [draft-ietf-regext-datadictionary-03] (14 pages) - Registry Data Escrow Specification [draft-ietf-regext-data-escrow-10] (16 pages) - Domain Name Registration Data (DNRD) Objects Mapping [draft-ietf-regext-dnrd-objects-mapping-11] (169 pages) - Third Party DNS operator to Registrars/Registries Protocol [draft-ietf-regext-dnsoperator-to-rrr-protocol-05] (15 pages) - Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-eai-18] (14 pages) - Registry Fee Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-fees-20] (30 pages) - Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping [draft-ietf-regext-epp-rdap-status-mapping-04] (11 pages) - Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-registry-maintenance-19] (22 pages) - Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values [draft-ietf-regext-epp-ttl-00] (15 pages) - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-launchphase-07] (58 pages) - Login Security Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-login-security-10] (21 pages) - Extensible Provisioning Protocol (EPP) China Name Verification Mapping [draft-ietf-regext-nv-mapping-00] (37 pages) - Extensible Provisioning Protocol (EPP) Organization Mapping [draft-ietf-regext-org-12] (43 pages) - Organization Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-org-ext-11] (22 pages) - Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses [draft-ietf-regext-rdap-jscontact-15] (26 pages) - Registration Data Access Protocol (RDAP) Object Tagging [draft-ietf-regext-rdap-object-tag-05] (13 pages) - Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect [draft-ietf-regext-rdap-openid-22] (49 pages) - Registration Data Access Protocol (RDAP) Partial Response [draft-ietf-regext-rdap-partial-response-16] (12 pages) - Redacted Fields in the Registration Data Access Protocol (RDAP) Response [draft-ietf-regext-rdap-redacted-12] (41 pages) - Registration Data Access Protocol (RDAP) Reverse Search [draft-ietf-regext-rdap-reverse-search-22] (22 pages) - RDAP RIR Search [draft-ietf-regext-rdap-rir-search-02] (17 pages) - Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging [draft-ietf-regext-rdap-sorting-and-paging-20] (23 pages) - Extensible Provisioning Protocol (EPP) Reseller Mapping [draft-ietf-regext-reseller-01] (30 pages) - Reseller Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-reseller-ext-01] (18 pages) - Registration Data Access Protocol (RDAP) Query Format [draft-ietf-regext-rfc7482bis-03] (18 pages) - JSON Responses for the Registration Data Access Protocol (RDAP) [draft-ietf-regext-rfc7483bis-05] (81 pages) - Finding the Authoritative Registration Data Access Protocol (RDAP) Service [draft-ietf-regext-rfc7484bis-06] (15 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-ietf-regext-secure-authinfo-transfer-07] (22 pages) - Simple Registration Reporting [draft-ietf-regext-simple-registration-reporting-07] (35 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-ietf-regext-unhandled-namespaces-08] (21 pages) - Validate Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-validate-04] (16 pages) - Verification Code Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-verificationcode-06] (38 pages) - Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses [draft-loffredo-regext-rdap-jcard-deprecation-04] (16 pages) - Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values [draft-regext-brown-epp-ttl-04] (15 pages) - Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) [draft-sattler-epp-registry-maintenance-10] (22 pages) - Simple Registration Reporting [draft-yee-regext-simple-registration-reporting-01] (16 pages) Requests for Comments: BCP221: Registration Data Access Protocol (RDAP) Object Tagging (13 pages) RFC8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping (11 pages) RFC8063: Key Relay Mapping for the Extensible Provisioning Protocol (16 pages) RFC8334: Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) (58 pages) RFC8495: Allocation Token Extension for the Extensible Provisioning Protocol (EPP) (17 pages) RFC8521: Registration Data Access Protocol (RDAP) Object Tagging (13 pages) RFC8543: Extensible Provisioning Protocol (EPP) Organization Mapping (43 pages) RFC8544: Organization Extension for the Extensible Provisioning Protocol (EPP) (22 pages) RFC8590: Change Poll Extension for the Extensible Provisioning Protocol (EPP) (20 pages) RFC8748: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) (30 pages) RFC8807: Login Security Extension for the Extensible Provisioning Protocol (EPP) (21 pages) RFC8909: Registry Data Escrow Specification (16 pages) RFC8977: Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging (23 pages) RFC8982: Registration Data Access Protocol (RDAP) Partial Response (12 pages) RFC9022: Domain Name Registration Data (DNRD) Objects Mapping (169 pages) RFC9038: Extensible Provisioning Protocol (EPP) Unhandled Namespaces (21 pages) RFC9082: Registration Data Access Protocol (RDAP) Query Format (18 pages) RFC9083: JSON Responses for the Registration Data Access Protocol (RDAP) (81 pages) RFC9154: Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer (22 pages) RFC9167: Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) (22 pages) RFC9224: Finding the Authoritative Registration Data Access Protocol (RDAP) Service (15 pages) Relay User Machine (rum) ------------------------ Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Brian Rosen Paul Kyzivat Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: rum@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rum Archive: https://mailarchive.ietf.org/arch/browse/rum/ Description of Working Group: Many current instances of Video Relay Service (VRS), sometimes called Video Interpretation Service, use the Session Initiation Protocol (SIP) and other IETF multimedia protocols. VRS is used by deaf/hard-of-hearing persons and by persons with speech impairments to communicate with hearing persons. The deaf, hard-of-hearing, or speech-impaired person (D-HOH-SI) uses a SIP-based video phone to connect with an interpreter, and the interpreter places a phone call to the hearing person. The hearing person can also reach D-HOH-SI individuals in the same manner as calling any hearing user. The D-HOH-SI person uses sign language and possibly real-time text with the interpreter and the interpreter uses spoken language with the hearing person, providing on-line, real-time, two-way communication. Having a standard interface between the end-user device and the VRS provider allows vendors and open-source developers to build devices that work with multiple service providers; devices can also be retained when changing providers. In this instance, “device” could be a purpose-built videophone or could be downloadable software on a general purpose computing platform or mobile phone. To ensure interoperability of the key features of this service, certain aspects (e.g., codecs, media transport, addressing and SIP features) must be specified as mandatory-to-implement for SIP-based VRS devices. These specified features effectively form a profile for SIP and the media it negotiates. This working group will produce a single document: a profile of SIP and media features for use with video relay services (which includes video, real time text, and audio), and other similar interpretation services that require multimedia. It will reference the IETF’s current thinking on multimedia communication, including references to work beyond SIP (e.g., WebRTC and SLIM). The profile will require best-practice security mechanisms for SIP-based end devices. The working group will consider issues related to authentication of the parties involved in the video relay call. No protocol changes are anticipated by this work. Often, the hearing user is on the PSTN, and RUM will include interoperability specifications for that use, including the use of telephone numbers. RUM will not assume hearing users are on the PSTN. While WebRTC could be used to implement a profile to fulfill RUM's requirements, the group’s work will focus on the device-to-provider interface. The working group will consider ways for WebRTC based services to interwork with a RUM-compliant provider, but is not required to make such interwork possible. RUM devices will be expected to be able to place emergency calls conforming to the current IETF emergency call recommendations. The scope of the work includes mechanisms to provision the user’s device with common features such as speed dial lists, provider to contact, videomail service interface point and similar items. These features allow users to more easily switch providers temporarily (a feature known as “dial around”) or permanently, while retaining their data. Devices used in VRS can be used to place point-to-point calls where both communicating parties use sign language. When used for point-to-point calling where the participants are not served by the same VRS provider, or when one provider provides the originating multimedia transport environment, but another provides the interpreter (“dial-around call”), the call traverses two providers. Both of these uses impose additional requirements on a RUM device and are in scope for this work. Although the interface between providers also requires standardization to enable multi-provider point-to-point and dial-around calls, that interface has already been defined in a SIP Forum document and is thus out of scope for RUM. Goals and Milestones: Dec 2019 - Submit a profile of SIP and media features for use with video relay services to the IESG for publication Internet-Drafts: - Interoperability Profile for Relay User Equipment [draft-ietf-rum-rue-11] (36 pages) Requests for Comments: RFC9248: Interoperability Profile for Relay User Equipment (36 pages) Revise Universally Unique Identifier Definitions (uuidrev) ---------------------------------------------------------- Charter Last Modified: 2022-08-29 Current Status: Active Chairs: Jim Fenton Michael Richardson Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: uuidrev@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/uuidrev Archive: https://mailarchive.ietf.org/arch/browse/uuidrev/ Description of Working Group: Since the publication of RFC 4122 in 2005, a number of additional versions of universally unique IDs (UUIDs) have been proposed. A number of errata have also been verified against the original specification, motivating a full revision of the UUID specification with the additional versions added. This working group will produce a standard-track RFC4122bis specification based on limited review of RFC4122 that will include resolution of verified or held errata and incorporation of the following additional UUID versions, using draft-peabody-dispatch-new-uuid-format as a guide: - Field-compatible version of UUIDv1 optimized for improved database locality - Time-ordered UUID based on Unix epoch timestamp - UUID version for vendor-specific use cases Other aspects of UUIDs, such as alternative representations and UUIDs that are other than 128 bits in length, will also be considered and the working group may produce specifications on those topics. They will not be considered, however, prior to completion of RFC4122bis, and such milestones will be negotiated with the responsible AD prior to work commencing. Goals and Milestones: Mar 2023 - Submit RFC4122bis to the IESG for publication as Proposed Standard Internet-Drafts: - Universally Unique IDentifiers (UUID) [draft-ietf-uuidrev-rfc4122bis-04] (49 pages) No Requests for Comments Revision of core Email specifications (emailcore) ------------------------------------------------- Charter Last Modified: 2022-05-18 Current Status: Active Chairs: Alexey Melnikov Todd Herr Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: emailcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emailcore Archive: ​https://mailarchive.ietf.org/arch/browse/emailcore/ Description of Working Group: The base documents defining Internet messaging — colloquially, email -- are RFC 5321 (protocol) and RFC 5322 (format). These are revisions and consolidations of prior documents and were last published in 2008. They currently sit at Draft Standard status, a status that no longer exists according to the current IETF procedure. Since then some errata have accumulated (both submitted to IETF and reported directly to editors), as have comments made about these documents not necessarily describing best email practices. There is now sufficient critical mass to undertake a limited review and revision of these documents for the purpose of advancing them to Internet Standard status. This working group will conduct a limited review and revision to the base email specifications, and will publish new versions of these documents at Internet Standard status, per RFC 6410. The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping these minimal and avoiding broader changes to terminology or document organization. In addition to processing existing, verified errata and errata marked as "held for document update", the WG may address newly-offered errata. However, no new protocol extensions or amendments will be considered for inclusion into 5321bis and 5322bis documents, unless they are already published as IETF Stream RFCs and are at sufficient maturity level to move to Internet Standard. The working group will also work on an Applicability Statement in parallel with 5321bis and 5322bis, to capture relationships to other documented and widely deployed work (recommended extensions, transport security and other issues from the UTA working group's output, and such) and current email practices. 5321bis and 5322bis will be submitted for publication before this document is finalized, and the "bis" documents will have priority for the working group's attention until they are finished. Upon completion of these three milestones, and assuming there is still the momentum to do so, the working group may undertake similar review and revision of other email specifications. Such future work will require rechartering. Goals and Milestones: Internet-Drafts: - Applicability Statement for IETF Core Email Protocols [draft-ietf-emailcore-as-08] (17 pages) - Simple Mail Transfer Protocol [draft-ietf-emailcore-rfc5321bis-18] (149 pages) - Internet Message Format [draft-ietf-emailcore-rfc5322bis-05] (56 pages) No Requests for Comments Secure Asset Transfer Protocol (satp) ------------------------------------- Charter Last Modified: 2023-02-03 Current Status: Active Chairs: Claire Wes Hardaker Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: sat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sat Archive: https://mailarchive.ietf.org/arch/browse/sat/ Description of Working Group: Objective There is currently an interoperability problem in many digital asset networks (frequently shortened to "network" below for simplicity), where assets in one network cannot be moved easily to another network. The problem is more acute in the case of private asset networks, where external entities have no visibility into the state of an asset in the private network. An example is regulated digital representations of real-world private assets, such as property ownership certificates, and regulated government-issued digital currencies. The goal of the Secure Asset Transfer Protocol (SATP) working group will be to develop a standard protocol which operates between two peer gateways for the purpose of transferring digital assets between an originator in the origin network to a beneficiary in a destination network. The resulting protocol shall be agnostic with respect to the type of asset being transferred. Problem space and architecture To begin addressing these challenges, SATP will employ the gateway paradigm as a means for digital assets to be moved from one network to another through a standardized asset transfer protocol implemented between peer gateways. Each gateway represents one digital asset network, and SATP allows gateways to perform a voluntary transfer of a digital asset from the origin network to a destination network in such a way that evidence of the transfer can be verified by a third-party audit in the case of disputes. Both the origin and destination networks are assumed to share a common understanding of the digital asset. There might be several gateways representing the same digital asset network. It is assumed that the same peer gateways representing the networks are participating in the entire asset transfer sequence from the beginning to the end. A key requirement for transferring assets is ensuring that the digital asset is valid in one network only at any given time. This means that SATP must ensure that the properties of atomicity, consistency, isolation, and durability (ACID) of the underlying networks are satisfied in an asset transfer. Commitments and rollbacks must be supported in the case of an asset mid-transfer failure. Relationship with other IETF Working Groups The Transfer dIGital cREdentialS Securely (TIGRESS) working group is focused on transferring digital credentials, which is akin to but not equal to SATP's goals of transferring digital assets. An additional difference is TIGRESS is a wallet-to-wallet transfer, while SATP's proposed solution involves a gateway-to-gateway transfer. The SATP working group will work with TIGRESS proponents to ensure reuse of existing TIGRESS outputs are used within SATP to promote technology reuse. Deliverables The deliverables of the SATP Working Group will be as follows: SATP Architecture: The immediate scope of work for SATP will be a base architecture that utilizes the gateway paradigm that ensures a common semantic understanding to be shared among the modes of asset transfers, data sharing and coordinated asset exchanges. The starting point for the architecture document will be draft-hardjono-sat-architecture. Secure Asset Transfer Protocol: Concurrent with the development of the SATP architecture will be the Secure Asset Transfer Protocol that implements the transfer of a digital asset from one gateway to another, satisfying the ACID properties. SATP Use-Cases: Various real-world use-cases will be collected and described succinctly, with the goal of providing the background to the SATP work. SATP will define common identifiers, message flows and payloads for transferring digital assets. A common terminology will be defined in the architecture document. SATP will reuse existing IETF standards for various aspects of the protocol modes, including but not limited to secure channel establishment (TLS), payload formats (e.g., JSON, CBOR, etc.), digital signature and encryption (e.g., JOSE, COSE, etc.), digital certificates and tokens (e.g., PKIX, JWT, etc.), and others. SATP may also reuse existing standards from other organizations (e.g., W3C with DIDs). Note that for the protocol to work, agreements will likely be needed between participating digital asset networks that intend to use SATP; these legal or other frameworks, along with proof of their proper implementation, are outside of the scope of the SATP. This assumption is akin to how the BGP protocol is frequently run between parties that have previously agreed to route IP packets. Goals and Milestones: Jan 2024 - SATP Use-Cases document Jul 2024 - ATP Asset Transfer Protocol document Jul 2024 - SATP Architecture document Internet-Drafts: - Secure Asset Transfer (SAT) Interoperability Architecture [draft-hardjono-sat-architecture-03] (21 pages) - Secure Asset Transfer Protocol (SATP) [draft-hargreaves-sat-core-02] (29 pages) - Secure Asset Transfer (SAT) Interoperability Architecture [draft-ietf-satp-architecture-00] (21 pages) - Secure Asset Transfer Protocol (SATP) [draft-ietf-satp-core-00] (29 pages) - Secure Asset Transfer (SAT) Use Cases [draft-ietf-satp-usecases-00] (12 pages) - Secure Asset Transfer (SAT) Use Cases [draft-ramakrishna-sat-use-cases-02] (12 pages) No Requests for Comments Secure Media Frames (sframe) ---------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Bobo Bose-Kolanu Martin Thomson Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: sframe@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sframe Archive: https://mailarchive.ietf.org/arch/browse/sframe/ Description of Working Group: Real-time conferencing sessions increasingly require end-to-end protections that prevent intermediary servers from decrypting real-time media. The PERC WG developed a “double encryption” scheme for end-to-end encryption that was deeply tied to SRTP as its underlying transport. This entanglement has prevented widespread deployment. This working group will define the SFrame secure encapsulation to provide authenticated encryption for real-time media content that is independent of the underlying transport. The encapsulation will provide the following information to drive the authenticated encryption for each encryption operation: * Selection among multiple encryption keys in use during a real-time session * An algorithm for forming a unique nonce within the scope of the key based on information in the encapsulation framing The SFrame specification will detail the specific security properties that the encapsulation provides, and discuss their implications under common usage scenarios / threat models. The transport-independence of this encapsulation means that it can be applied at a higher level than individual RTP payloads. For example, it may be desirable to encrypt whole frames that span multiple packets in order to amortize the overhead from framing and authentication tags. It may also be desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs) to allow partial frames to be usable. The working group will choose what levels of granularity can be selected in the protocol. An application using SFrame will need to choose several aspects of its operation, for example: * Selecting whether SFrame is to be used for a given media flow * Specifying which encryption algorithm should be used * Provisioning keys and key identifiers to endpoints * Selecting the granularity at which SFrame encryption is applied (if multiple options are available) This working group, however, will not specify the signaling required to arrange SFrame encryption. In particular, considerations related to SIP or SDP are out of scope. This is because SFrame is intended to be applied as an additional layer on top of the base levels of protection that these protocols provide. This working group will, however, define the guidance for how SFrame interacts with RTP (e.g., with regard to packetization, depacketization, and recovery algorithms) to ensure that it can be used in environments such as WebRTC. Other WebRTC changes such as the payload format and metadata format will be addressed by the AVTCORE working group. It is anticipated that several use cases of SFrame will involve its use with keys derived from the MLS group key exchange protocol. The working group will define a mechanism for doing SFrame encryption using keys from MLS, including, for example, the derivation of SFrame keys per MLS epoch and per sender. The availability of this mechanism for using keys from MLS does not preclude the use of other sources of key material. Goals and Milestones: Jun 2021 - Submit SFrame specification to IESG (Standards Track) Internet-Drafts: - Secure Frame (SFrame) [draft-ietf-sframe-enc-01] (34 pages) - Secure Frame (SFrame) [draft-omara-sframe-03] (31 pages) No Requests for Comments Secure Telephone Identity Revisited (stir) ------------------------------------------ Charter Last Modified: 2023-02-17 Current Status: Active Chairs: Ben Campbell Robert Sparks Russ Housley Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: https://mailarchive.ietf.org/arch/browse/stir/ Description of Working Group: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474 (replaced by RFC 8224), and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify and maintain a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will work on mechanisms for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any mechanisms that require changes to circuit-switched technologies. Moreover, the work of this group is limited to developing a solution for telephone numbers. Expansion of the authorization mechanism to identities using the user@domain or other name forms is out of scope. The group will also consider extensions that leverage STIR to solve related identity problems around telephone calls and other telephone-number based communication, including call diversion and forwarding, rich identity presentation for delivery to a called party, messaging that uses telephone numbers, connected identity (mechanisms that identify the called party reached to the calling party), and similar use cases related to fraud and security. The working group will coordinate with the Security Area on credential management and signature mechanics. The working group will coordinate with other working groups in the ART Area regarding signaling through existing deployments. The working group welcomes input from potential implementors or operators of technologies developed by this working group. For example, national numbering authorities might consider acting as credential authorities for telephone numbers within their purview. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. In order to support anonymity, the working group will provide a solution in which the called party receives an indication that the source telephone number is unavailable. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms. Goals and Milestones: - Identity Header Error Handling - Connected Identity for STIR - Messaging Use Cases and Extensions for STIR Nov 2019 - Submit PASSPorT Extension for rich call data for publication as Proposed Standard Mar 2020 - Submit Privacy analysis for Informational Done - Submit Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks as Proposed Standard Done - Submit STIR Certificate Delegation as Proposed Standard Internet-Drafts: - Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks [draft-dolly-stir-rph-emergency-services-00] (6 pages) - Enhanced JWT Claim Constraints for STIR Certificates [draft-housley-stir-enhance-rfc8226-00] (8 pages) - Secure Telephone Identity Revisited (STIR) Certificate Delegation [draft-ietf-stir-cert-delegation-04] (12 pages) - Secure Telephone Identity Credentials: Certificates [draft-ietf-stir-certificates-18] (24 pages) - OCSP Usage for Secure Telephone Identity Certificates [draft-ietf-stir-certificates-ocsp-03] (13 pages) - Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates [draft-ietf-stir-enhance-rfc8226-05] (12 pages) - Identity Header Errors Handling for STIR [draft-ietf-stir-identity-header-errors-handling-08] (8 pages) - Messaging Use Cases and Extensions for STIR [draft-ietf-stir-messaging-07] (12 pages) - Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases [draft-ietf-stir-oob-07] (24 pages) - PASSporT: Personal Assertion Token [draft-ietf-stir-passport-11] (25 pages) - Personal Assertion Token (PASSporT) Extension for Diverted Calls [draft-ietf-stir-passport-divert-09] (17 pages) - PASSporT Extension for Rich Call Data [draft-ietf-stir-passport-rcd-24] (35 pages) - Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) [draft-ietf-stir-passport-shaken-08] (9 pages) - Secure Telephone Identity Problem Statement and Requirements [draft-ietf-stir-problem-statement-05] (25 pages) - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-ietf-stir-rfc4474bis-16] (46 pages) - Connected Identity for STIR [draft-ietf-stir-rfc4916-update-02] (15 pages) - Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization [draft-ietf-stir-rph-06] (10 pages) - Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks [draft-ietf-stir-rph-emergency-services-07] (7 pages) - Out-of-Band STIR for Service Providers [draft-ietf-stir-servprovider-oob-04] (9 pages) - Secure Telephone Identity Threat Model [draft-ietf-stir-threats-04] (13 pages) - STIR Certificate Delegation [draft-peterson-stir-cert-delegation-00] (9 pages) - Messaging Use Cases and Extensions for STIR [draft-peterson-stir-messaging-01] (10 pages) - Out-of-Band STIR for Service Providers [draft-peterson-stir-servprovider-oob-01] (8 pages) Requests for Comments: RFC7340: Secure Telephone Identity Problem Statement and Requirements (25 pages) RFC7375: Secure Telephone Identity Threat Model (13 pages) RFC8224: Authenticated Identity Management in the Session Initiation Protocol (SIP) (46 pages) * Updates RFC8946 RFC8225: PASSporT: Personal Assertion Token (25 pages) RFC8226: Secure Telephone Identity Credentials: Certificates (24 pages) * Updates RFC9118 RFC8443: Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization (10 pages) RFC8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) (9 pages) RFC8816: Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases (24 pages) RFC8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls (17 pages) RFC9027: Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks (7 pages) RFC9060: Secure Telephone Identity Revisited (STIR) Certificate Delegation (12 pages) RFC9118: Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates (12 pages) Serialising Extended Data About Times and Events (sedate) --------------------------------------------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Bron Gondwana Mark McFadden Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: sedate@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sedate Archive: https://mailarchive.ietf.org/arch/browse/sedate/ Description of Working Group: RFC 3339 defines a text format as a profile of ISO 8601 that can reliably express an instant in time, either in UTC or in a local time along with the offset against UTC. However, datetime data often has additional context, such as the timezone or calendar system that was in use when that instant was recorded. Particularly when using times for interval, recurrence, or offset calculations, it is necessary to know the context in which the timepoint exists. It would be valuable to have a standard text serialisation format for this contextual data. This working group will develop and publish a format meeting that requirement, subject to the additional constraints described below. * This format must be able to round-trip through intermediate systems which do not understand the full context. * Systems which don’t understand all the contextual fields must still be able to reliably extract the instant in time. This format will be a companion to RFC 3339 rather than a replacement, embedding unaltered RFC 3339 data in a way that makes it easy to parse just the datetime data independently of the context. Changes to RFC 3339 are explicitly outside the charter for this working group. If a need for an RFC 3339bis emerges, this group must recharter before performing that work. In this case, the changes to RFC 3339 will need to be clearly motivated, evaluated and precisely scoped during the rechartering process, and will need to make only changes that keep the timestamp specification a profile of current versions of ISO 8601. Stability of the RFC 3339 timestamp format is important to existing IETF protocols and the Internet generally, and any rechartering process should frown on anything that would invalidate the existing timestamp format. The working group will coordinate with ECMA International TC39 and ISO/TC 154 to ensure that this work remains a strict extension of ISO 8601 and its various parts rather than becoming a conflicting standard. Goals and Milestones: Apr 2023 - Submit extended date and time draft to the IESG for publication Done - Adopt a draft for extended date and time handling Internet-Drafts: - Date and Time on the Internet: Timestamps with additional information [draft-ietf-sedate-datetime-extended-08] (18 pages) No Requests for Comments Session Initiation Protocol Core (sipcore) ------------------------------------------ Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Brian Rosen Jean Mahoney Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: sipcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: https://mailarchive.ietf.org/arch/browse/sipcore/ Description of Working Group: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the SIP protocol, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 6665. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications named above as well as specifications pertaining to small, self-contained SIP protocol extensions. The process and requirements for new SIP extensions are documented in RFC5727, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. 3. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 4. Simpler solutions that solve a given problem should be favored over more complex solutions. The primary source of change requirements to the core SIP specifications (enumerated above) will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the ART Area. The primary source of new protocol extensions is the DISPATCH working group, which will generally make the determination regarding whether new SIP-related work warrants a new working group or belongs in an existing one. Goals and Milestones: Dec 2017 - Request publication of mechanisms for rapid dual-stack protocol selection in SIP Jun 2023 - Multiple Reasons values per protocol (PS) to the IESG Done - INFO package framework to IESG (PS) Done - Termination of early dialog prior to final response to IESG (PS) Done - Extension for use in etags in conditional notification to IESG (PS) Done - Invite Transaction Handling Correction to IESG (PS) Done - SIP Events throttling mechanism to IESG (PS) Done - Presence Scaling Requirements to IESG as Info Done - Mechanism for indicating support for keep-alives (PS) Done - Example security flows to IESG (Informational) Done - Location Conveyance with SIP to IESG (PS) Done - Error corrections and clarifications to RFC3265 to IESG (PS) Done - Delivering request-URI and parameters to UAS via proxy to IESG (PS) Done - Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS) Done - WebSockets transport definition for SIP to the IESG (proposed standard) Done - Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs Done - Request publication of a SIP response code for unwanted communications Done - Request publication of a mechanism for labeling the nature of SIP calls Done - Request publication of a clarification of the use of Content-ID as a SIP header field Done - Request publication of a clarification of the use of the "name-addr" production in SIP header fields Dropped - WGLC on requirements for a mechanism to indicate proxy capabilities to both endpoints and other proxies in the path of a REGISTER transaction or a dialog-forming transaction. Internet-Drafts: - Session Timers in the Session Initiation Protocol (SIP) [draft-holmberg-sipcore-rfc4028bis-00] (26 pages) - Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog [draft-ietf-sipcore-199-06] (14 pages) - A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework [draft-ietf-sipcore-6665-clarification-00] (4 pages) - SIP Call-Info Parameters for Rich Call Data [draft-ietf-sipcore-callinfo-rcd-05] (22 pages) - SIP Call-Info Parameters for Labeling Calls [draft-ietf-sipcore-callinfo-spam-04] (11 pages) - Content-ID Header Field in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-content-id-10] (14 pages) - The Session Initiation Protocol (SIP) Digest Access Authentication Scheme [draft-ietf-sipcore-digest-scheme-15] (9 pages) - Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network [draft-ietf-sipcore-dns-dual-stack-08] (10 pages) - Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control [draft-ietf-sipcore-event-rate-control-09] (25 pages) - Session Initiation Protocol (SIP) INFO Method and Package Framework [draft-ietf-sipcore-info-events-10] (36 pages) - Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests [draft-ietf-sipcore-invfix-01] (20 pages) - Indication of Support for Keep-Alive [draft-ietf-sipcore-keep-12] (18 pages) - Location Conveyance for the Session Initiation Protocol [draft-ietf-sipcore-location-conveyance-09] (35 pages) - Location Source Parameter for the SIP Geolocation Header Field [draft-ietf-sipcore-locparam-06] (8 pages) - Multiple SIP Reason Header Field Values [draft-ietf-sipcore-multiple-reasons-01] (4 pages) - Clarifications for When to Use the name-addr Production in SIP Messages [draft-ietf-sipcore-name-addr-guidance-02] (6 pages) - A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-originating-cdiv-parameter-08] (15 pages) - Scaling Requirements for Presence in SIP/SIMPLE [draft-ietf-sipcore-presence-scaling-requirements-02] (9 pages) - IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field [draft-ietf-sipcore-priority-00] (3 pages) - Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-proxy-feature-12] (19 pages) - Requirements for indication of features supported by a SIP proxy [draft-ietf-sipcore-proxy-feature-reqs-03] (9 pages) - ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field [draft-ietf-sipcore-reason-q850-loc-07] (7 pages) - Clarifications for the Use of REFER with RFC 6665 [draft-ietf-sipcore-refer-clarifications-04] (6 pages) - Explicit Subscriptions for the REFER Method [draft-ietf-sipcore-refer-explicit-subscription-03] (14 pages) - Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-reinvite-08] (26 pages) - A Session Initiation Protocol (SIP) Response Code for Rejected Calls [draft-ietf-sipcore-rejected-09] (22 pages) - SIP-Specific Event Notification [draft-ietf-sipcore-rfc3265bis-09] (53 pages) - Session Timers in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-rfc4028bis-06] (26 pages) - An Extension to the Session Initiation Protocol (SIP) for Request History Information [draft-ietf-sipcore-rfc4244bis-12] (36 pages) - Session Initiation Protocol (SIP) History-Info Header Call Flow Examples [draft-ietf-sipcore-rfc4244bis-callflows-08] (52 pages) - Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms [draft-ietf-sipcore-sec-flows-09] (67 pages) - Session Initiation Protocol (SIP) Session Timer Glare Handling [draft-ietf-sipcore-sessiontimer-race-02] (7 pages) - Third-Party Authentication for Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-authn-02] (17 pages) - Push Notification with the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-push-29] (40 pages) - Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-token-authnz-17] (15 pages) - The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-websocket-10] (25 pages) - A SIP Response Code for Unwanted Calls [draft-ietf-sipcore-status-unwanted-06] (8 pages) - An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification [draft-ietf-sipcore-subnot-etags-04] (25 pages) - The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" [draft-rosen-rph-reg-policy-01] (2 pages) - The Session Initiation Protocol (SIP) Digest Authentication Scheme [draft-yusef-sipcore-digest-scheme-07] (8 pages) Requests for Comments: RFC5839: An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification (25 pages) RFC6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests (20 pages) RFC6086: Session Initiation Protocol (SIP) INFO Method and Package Framework (36 pages) RFC6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) (26 pages) RFC6216: Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms (67 pages) RFC6223: Indication of Support for Keep-Alive (18 pages) RFC6228: Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (14 pages) RFC6442: Location Conveyance for the Session Initiation Protocol (35 pages) * Updates RFC8262 * Updates RFC8787 RFC6446: Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (25 pages) RFC6665: SIP-Specific Event Notification (53 pages) * Updates RFC7621 RFC6809: Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) (19 pages) RFC6878: IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field (3 pages) RFC7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information (36 pages) RFC7118: The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) (25 pages) RFC7131: Session Initiation Protocol (SIP) History-Info Header Call Flow Examples (52 pages) RFC7134: The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" (2 pages) RFC7614: Explicit Subscriptions for the REFER Method (14 pages) RFC7621: A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework (4 pages) RFC7647: Clarifications for the Use of REFER with RFC 6665 (6 pages) RFC7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network (10 pages) RFC8197: A SIP Response Code for Unwanted Calls (8 pages) RFC8217: Clarifications for When to Use the name-addr Production in SIP Messages (6 pages) RFC8262: Content-ID Header Field in the Session Initiation Protocol (SIP) (14 pages) RFC8498: A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) (15 pages) RFC8599: Push Notification with the Session Initiation Protocol (SIP) (40 pages) RFC8606: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field (7 pages) RFC8688: A Session Initiation Protocol (SIP) Response Code for Rejected Calls (22 pages) RFC8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme (9 pages) RFC8787: Location Source Parameter for the SIP Geolocation Header Field (8 pages) RFC8898: Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) (15 pages) RFC9366: Multiple SIP Reason Header Field Values (4 pages) System for Cross-domain Identity Management (scim) -------------------------------------------------- Charter Last Modified: 2023-05-19 Current Status: Active Chairs: Aaron Parecki Nancy Cam-Winget Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Roman Danyliw Mailing Lists: General Discussion: scim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/scim Archive: https://mailarchive.ietf.org/arch/browse/scim/ Description of Working Group: The System for Cross-domain Identity Management (SCIM) specifications provide an HTTP-based protocol (RFC7643) and schema (RFC7644) that makes managing identities in multi-domain scenarios easier. Since its publication in 2015, SCIM has seen growing adoption. The first goal of this working group is to incorporate implementation experience; errata and interoperability feedback; and current security and best practices into a revised version of RFC7643 (protocol) and RFC7644 (base schema) suitable for consideration at the Internet Standard level of specification maturity. Additionally, implementation experience with SCIM has surfaced new use cases and requirements. The WG will document them in a revision of RFC7642. The WG will also consider publishing extensions to SCIM that have found broad adoption. These extensions may include profiles and schemas for interoperability in additional use cases. The scope of work for the SCIM WG is: * Revision of RFC7642 that will: * Focus on Use cases and implementation patterns * Pull vs. Push based use cases * Events and signals use cases * Deletion use cases * New use cases may be added to the revised RFC * Revision of RFC7643 and RFC7644 that will include: * Profiling SCIM relationships with other identity-centric protocols such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed * Updates to the evolution of the externalid usage * Updates to account state for capturing context of the state or change in state of the users account * Multi-Value Query Filtering and Paging (will use draft-hunt-scim-mv-paging as input) * Define a method for coordinating resources between domains: * Incremental approach to synchronization * Consider building off of RFC8417 and draft-hunt-idevent-scim * Support for deletion-related goals including: * Handling Deletes in SCIM Servers that don’t allow Deletes (Soft Deletes) (will use draft-ansari-scim-soft-delete as input) * Support for advanced automation scenarios such as: * Discovery and negotiation of client credentials * Attribute mapping * Per-attribute schema negotiation * Enhance the existing schema to support exchanging of human resources, enterprise group and privileged access management (will use draft-grizzle-scim-pam-ext as input) Goals and Milestones: Dec 2021 - Working group adoption of I-D for revising RFC7642 Dec 2021 - Working group adoption of I-Ds for Soft Delete Mar 2022 - Working group adoption of I-Ds (either new or existing) for privileged access management Mar 2022 - Working group adoption of I-Ds for Multi-valued paging Mar 2022 - Working Group adoption of I-Ds for coordination/synchronization between domains Jun 2022 - Progress I-D revising RFC7642 to WGLC Jun 2022 - Working group adoption of I-D revising RFC7643 Jun 2022 - Working group adoption of I-D revising RFC7644 Dec 2022 - Progress I-Ds for Soft Delete to WGLC Dec 2022 - Progress I-Ds for Multi-valued paging to WGLC Mar 2023 - Progress I-Ds (either new or existing) for privileged access management to WGLC Jun 2023 - Progress I-Ds for coordination/synchronization between domains to WGLC Jun 2023 - Progress I-D revising RFC7643 to WGLC Jun 2023 - Progress I-D revising RFC7644 to WGLC Internet-Drafts: - System for Cross-domain Identity Management: Protocol [draft-ietf-scim-api-19] (89 pages) - System for Cross-domain Identity Management: Core Schema [draft-ietf-scim-core-schema-22] (104 pages) - Cursor-based Pagination of SCIM Resources [draft-ietf-scim-cursor-pagination-01] (11 pages) - SCIM Profile for Security Event Tokens [draft-ietf-scim-events-01] (32 pages) - SCIM Roles and Entitlements Extension [draft-ietf-scim-roles-entitlements-00] (15 pages) - System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements [draft-ietf-scim-use-cases-08] (19 pages) Requests for Comments: RFC7642: System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements (19 pages) RFC7643: System for Cross-domain Identity Management: Core Schema (104 pages) RFC7644: System for Cross-domain Identity Management: Protocol (89 pages) Transfer dIGital cREdentialS Securely (tigress) ----------------------------------------------- Charter Last Modified: 2022-07-19 Current Status: Active Chairs: Leif Johansson Prachi Jain Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Roman Danyliw Mailing Lists: General Discussion: tigress@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tigress Archive: https://mailarchive.ietf.org/arch/browse/tigress/ Description of Working Group: There are many situations in which it is desirable to transfer a copy of a digital credential to another person. For example, a private car owner may want to provide access to their vehicle to a friend or a family member. A private homeowner may want to provide access to their home to their cat sitter. An individual staying at a hotel may want to transfer a copy of a hotel room key to their spouse. Today, no such standardized method exists in a cross-platform, credential type-agnostic capacity. The WG will standardize a protocol that will facilitate such credential transfers from one person's device to another person's device. The protocol will leverage a "relay server" to transfer data from sender to recipient. The scope of the transfer is limited to a single origin device and a single destination device. Note: neither private keys nor secret symmetric keys present on the sender's device are exchanged during the transfer operation. In the transfer protocol, the “credential” is the information issued by a credential authority for a given user and device that allows them to have access rights to a certain asset. The “share” is a data structure transferred from the sender to recipient that comprises the data both necessary and sufficient for the recipient to request a new credential from the credential authority to provision it to the receiving device. Privacy goals include: * The relay server should not see sensitive details of the share * The relay server should not be able to provision the credential itself, acting as an intermediary for the recipient (person-in-the-middle, impersonation attack) * Aside from network-level metadata, the relay server should not learn information about the sender or receiver Sufficient security measures should be embedded in the protocol in an effort to: * Ensure only the intended recipient is able to provision the credential * Ensure the credential can only be provisioned once (anti-replay) * Ensure the sender has the intent to transfer (proof of the fact that the share initiation is attributed to a valid device and a user) The solution the WG defines is expected to: * Allow a sender to initiate a share and select a relay server * Allow a recipient to view the share request, and provision the credential associated with the share upon receipt * Allow a sender and a recipient to perform multiple round trip communications within a limited time frame * Not require that both the sender and recipient have connectivity to the relay server at the same time * Support opaque message content based on the credential type * Support a variety of types of credentials, to include those adhering to public standards (e.g., Car Connectivity Consortium) and proprietary (i.e., non-public or closed community) formats The following topics are out of scope for the WG: * Defining the mechanism the receiver will use in order to provision the credential with the credential authority * The User Interface (UI) that is displayed to the sender or receiver during sending or receiving (this will depend on the device manufacturer's interface guidelines) * Defining the format or content of each field within the encrypted data (i.e., the provisioned credentials and associated information) stored on the relay server The WG will deliver a protocol to facilitate secure credential transfer. The WG must consider all Privacy and Security goals in an effort to perform the credential transfer securely. The protocol will use appropriate cryptographic mechanisms to protect the transferred credentials in accordance with the security and privacy goals described above. Goals and Milestones: Dec 2022 - WG adoption of the secure credential transfer protocol Dec 2023 - Submit secure credential transfer protocol to the IESG for publication Internet-Drafts: - Transfer Digital Credentials Securely - Requirements [draft-tigress-requirements-09] (12 pages) No Requests for Comments Using TLS in Applications (uta) ------------------------------- Charter Last Modified: 2023-02-28 Current Status: Active Chairs: Orie Steele Valery Smyslov Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: uta@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/uta Archive: https://mailarchive.ietf.org/arch/browse/uta/ Description of Working Group: There is a renewed and urgent interest in the IETF to increase the security of transmissions over the Internet. Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. However, there is a diversity of definitions and requirements, and that diversity has caused confusion for application developers and also has led to lack of interoperability or lack of deployment. Implementers and deployers are faced with multiple security issues in real-world usage of TLS, which currently does not preclude insecure ciphers and modes of operation. This WG has the following tasks: - Update the definitions for using TLS over a set of representative application protocols. This includes communication with proxies, between servers, and between peers, where appropriate, in addition to client/server communication. - Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement. - Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved. - Create a document that helps application protocol developers use TLS in future application definitions. The initial set of representative application protocols is SMTP, POP, IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use TLS might later be updated using the guidelines from this WG, and that those updates will happen through other WGs or through individual submissions. The WG will make the fewest changes needed to achieve good interoperable security for the applications using TLS. No changes to TLS itself will be made in this WG, and the WG will ensure that changes to current versions of popular TLS libaries will not be required to conform to the WG's specifications. This WG will collaborate with other IETF WGs, in particular with the TLS and DANE WGs. Goals and Milestones: Aug 2022 - TLS/DTLS 1.3 Profiles for IoT to IETF LC Done - Use of TLS for Email Submission and Access to IETF LC Done - Recommendations for Secure Use of TLS and DTLS (rfc7525-bis) to IETF LC Done - Representation and Verification of Domain-Based Application Service Identity within Internet PKI Using X.509 Certificates in the Context of TLS (rfc6125-bis) to IETF LC Internet-Drafts: - Updates to the Cipher Suites in Secure Syslog [draft-ciphersuites-in-sec-syslog-01] (8 pages) - Updates to the Cipher Suites in Secure Syslog [draft-ietf-uta-ciphersuites-in-sec-syslog-03] (8 pages) - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access [draft-ietf-uta-email-deep-12] (26 pages) - Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols [draft-ietf-uta-email-tls-certs-09] (13 pages) - SMTP MTA Strict Transport Security (MTA-STS) [draft-ietf-uta-mta-sts-21] (29 pages) - Service Identity in TLS [draft-ietf-uta-rfc6125bis-12] (30 pages) - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-uta-rfc7525bis-11] (34 pages) - SMTP Require TLS Option [draft-ietf-uta-smtp-require-tls-09] (16 pages) - SMTP TLS Reporting [draft-ietf-uta-smtp-tlsrpt-23] (34 pages) - TLS/DTLS 1.3 Profiles for the Internet of Things [draft-ietf-uta-tls13-iot-profile-06] (15 pages) - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) [draft-ietf-uta-tls-attacks-05] (13 pages) - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-ietf-uta-tls-bcp-11] (27 pages) - Deprecation of TLS 1.1 for Email Submission and Access [draft-ietf-uta-tls-for-email-05] (6 pages) - Update to Verifying TLS Server Identities with X.509 Certificates [draft-ietf-uta-use-san-00] (5 pages) - Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) [draft-ietf-uta-xmpp-07] (9 pages) - Deployable Enhanced Email Privacy (DEEP) [draft-newman-email-deep-02] (35 pages) - Update to Verifying TLS Server Identities with X.509 Certificates [draft-rsalz-use-san-01] (5 pages) - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [draft-sheffer-uta-rfc7525bis-00] (26 pages) - TLS/DTLS 1.3 Profiles for the Internet of Things [draft-tschofenig-uta-tls13-profile-04] (9 pages) Requests for Comments: BCP195: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (27 pages) RFC7457: Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) (13 pages) RFC7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (27 pages) * Updates RFC8996 * Obsoletes RFC9325 RFC7590: Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) (9 pages) RFC7817: Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols (13 pages) RFC8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access (26 pages) * Updates RFC8997 RFC8460: SMTP TLS Reporting (34 pages) RFC8461: SMTP MTA Strict Transport Security (MTA-STS) (29 pages) RFC8689: SMTP Require TLS Option (16 pages) RFC8997: Deprecation of TLS 1.1 for Email Submission and Access (6 pages) RFC9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (34 pages) WebRTC Ingest Signaling over HTTPS (wish) ----------------------------------------- Charter Last Modified: 2022-05-04 Current Status: Active Chairs: Nils Ohlmeier Sean Turner Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: wish@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/wish Archive: https://mailarchive.ietf.org/arch/browse/wish/ Description of Working Group: The WISH working group is chartered to specify a simple, extensible, HTTPS-based signaling protocol to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks. Background: WebRTC defines a set of wire protocols for real-time media transmission, as well as a profile of the Session Description Protocol (SDP) for setting up and controlling the associated media streams. Because of its typical use cases, and to increase overall flexibility, WebRTC did not specify a wire protocol for exchanging SDP messages, leaving the creation of such protocols up to the applications that use WebRTC. This works well when WebRTC clients are vertically integrated with the servers they communicate with, as it allows for rapid iteration of new features. At the same time, the use of WebRTC as a mechanism for large-scale media broadcast is gaining popularity, with companies such as Millicast, Caffeine, Janus/Meetecho, Evercast, Wowza, Liveswitch, Antmedia, and Strivecast deploying WebRTC-based media distribution networks. Unlike more vertically integrated uses of WebRTC, these networks would benefit immensely from being able to re-use the several broadcasting tools that have been developed over time (such as Wirecast, OBS, Stretchcast, NewBlue Stream, XSplit, FFSplit, Lightstream, vMix, and a host of other applications). To date, these media distribution networks have employed their own proprietary signaling protocols to establish the connection between broadcasting tools and the network, generally requiring either bespoke software or customized modifications to existing broadcasting tools. With the large number of available tools and the growing number of real-time media distribution networks, this ad-hoc approach to creating custom protocols for establishing sessions clearly does not scale. The real-time broadcasting ecosystem would benefit immensely from a single, shared protocol to meet this goal. Deliverables: The product of this working group will be a specification for a simple, extensible, HTTPS-based signaling protocol to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks. This working group will use existing HTTPS, WebRTC, and SDP mechanisms to the extent possible. While no extensions to those core protocols is expected, the working group may consider such extensions if they are necessary to meet the requirements of broadcasting tools and networks. Any such work will be coordinated with the HTTPBIS, MMUSIC, and/or MOPS working groups, as appropriate. Additionally, this working group will coordinate with HTTPBIS and HTTPAPI to assure that the HTTP protocol is being used according to current best practice. While there may be other problems that the proposed mechanism may solve or nearly solve, such as video display clients connecting to the egress of a media delivery network, adding explicit protocol support for those use cases is not in scope for the WISH working group. Goals and Milestones: Sep 2022 - Submit web ingest signaling protocol to IESG for publication Internet-Drafts: - WebRTC-HTTP ingestion protocol (WHIP) [draft-ietf-wish-whip-08] (24 pages) No Requests for Comments WebTransport (webtrans) ----------------------- Charter Last Modified: 2022-05-04 Current Status: Active Chairs: David Schinazi Dr. Bernard D. Aboba Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Applications and Real-Time Area Advisor: Francesca Palombini Mailing Lists: General Discussion: webtransport@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/webtransport Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ Description of Working Group: Description of Working Group The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport API https://wicg.github.io/web-transport. The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of reliable messages. Attention will be paid to the performance of the protocol, with particular attention to the protocol’s overhead and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new transport protocols but will instead use existing protocols such as QUIC and TLS/TCP. The group will pay attention to security issues arising from the above scenarios so as to protect against creation of new modes of attack. To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. The requirements will include those arising from the WebTransport API. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol extensions and the needs of the WebTransport API. The group will also coordinate with related working groups within the IETF, such as QUIC and HTTPBIS, as appropriate. In particular, if the working group needs any changes to or extensions of the core protocols, those issues will be raised with the relevant working groups for decisions on how best to handle them. If those decisions result in work in WebTrans, the working group last calls for that work will again be sent to the relevant working groups. The group also needs to coordinate with TAPS, as they are working on related message-based APIs and it's important to make sure there aren't conflicts and/or duplications. Goals and Milestones: Feb 2021 - Adopt a draft defining a WebTransport protocol as a WG work item Oct 2021 - Issue WG last call of the WebTransport Overview document. Mar 2022 - Issue WG last call on the first WebTransport protocol document Done - Adopt a WebTransport Overview draft as a WG work item Internet-Drafts: - WebTransport over HTTP/2 [draft-ietf-webtrans-http2-05] (28 pages) - WebTransport over HTTP/3 [draft-ietf-webtrans-http3-06] (18 pages) - The WebTransport Protocol Framework [draft-ietf-webtrans-overview-05] (12 pages) - WebTransport using HTTP/2 [draft-kinnear-webtransport-http2-02] (14 pages) - WebTransport over HTTP/3 [draft-vvv-webtransport-http3-03] (12 pages) - The WebTransport Protocol Framework [draft-vvv-webtransport-overview-01] (11 pages) No Requests for Comments General Area Dispatch (gendispatch) ----------------------------------- Charter Last Modified: 2023-04-04 Current Status: Active Chairs: Martin Vigoureux Shuping Peng General Area Directors: Lars Eggert General Area Advisor: Lars Eggert Mailing Lists: General Discussion: gendispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/gendispatch Archive: https://mailarchive.ietf.org/arch/browse/gendispatch/ Description of Working Group: The GENDISPATCH working group is a DISPATCH-style working group (see RFC 7957) chartered to consider proposals for new work in the GEN area, including proposals for changes or improvements to the IETF process and process documents. GENDISPATCH is chartered to identify, or to help create, an appropriate venue for new work. GENDISPATCH will not consider any technical standardization work. Guiding principles for proposed new work include: 1. Providing a clear problem statement, historical context, motivation, and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, enough individuals have expressed a willingness to contribute (if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap among published or ongoing work in the GEN area, the IESG, the IAB, the IETF LLC, the IRTF, other SDOs, or the wider technical community. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - Requesting that relevant bodies, including but not limited to the IESG, the IAB, the IRTF, or the IETF LLC, consider taking up the work in some form. - Deferring the decision for the new work. - Rejecting the new work. If GENDISPATCH decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Documents progressed as AD-sponsored would typically include those that are extremely simple or make minor updates to existing process documents. Proposed new work may be deferred in cases where GENDISPATCH does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient interest in GENDISPATCH or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of GENDISPATCH is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, GENDISPATCH will strive to quickly find a home for it (usually within a few months). While most new work in the GEN area is expected to be considered in GENDISPATCH, there may be times when that is not appropriate. At the discretion of the GEN AD, new efforts may follow other paths. For example, work may go directly to a BOF, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD-sponsored. While it is inevitable that some discussion of the merits of a proposal brought to GENDISPATCH are necessary in order to evaluate the appropriate disposition of the proposal, GENDISPATCH is not chartered to actually do the work proposed. As part of the dispatch, a venue for further discussion should be identified. The existence of GENDISPATCH does not change the IESG's responsibilities and discretion as described in RFC 3710. Work related to the IAB, IRTF, and RFC Editor processes is out of scope, but when discussions in GENDISPATCH identify such work items, they can be suggested to those bodies for action. Goals and Milestones: Internet-Drafts: No Requests for Comments NomCom Eligibility Update (elegy) --------------------------------- Charter Last Modified: 2022-08-31 Current Status: Active Chairs: Barry Leiba Michael Richardson General Area Directors: Lars Eggert General Area Advisor: Lars Eggert Mailing Lists: General Discussion: eligibility-discuss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eligibility-discuss/ Archive: https://mailarchive.ietf.org/arch/browse/eligibility-discuss/ Description of Working Group: The ELEGY working group will develop a document that will update Section 4.14 of RFC 8713 and become part of BCP 10, and that specifies the criteria for IETF NomCom eligibility going forward. The document will be informed by the RFC 8989 experiment and will address meetings held in person, including hybrid formats, as well as those held online only. It will cover ONLY qualification to volunteer for the NomCom (and to take roles in the recall process that are tied to that qualification). No other aspect of NomCom selection or operation is in scope. Goals and Milestones: Nov 2022 - Publication Requested for the BCP Internet-Drafts: - Nominating Committee Eligibility [draft-ietf-elegy-rfc8989bis-05] (9 pages) Requests for Comments: RFC9389: Nominating Committee Eligibility (9 pages) Stay Home Meet Occasionally Online (shmoo) ------------------------------------------ Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Mallory Knodel Suresh Krishnan General Area Directors: Lars Eggert General Area Advisor: Lars Eggert Mailing Lists: General Discussion: manycouches@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/manycouches Archive: https://mailarchive.ietf.org/arch/browse/manycouches/ Description of Working Group: The disruptions caused by the COVID-19 pandemic may have been mitigated by the time this group completes its work, but the experience of handling meeting planning during the pandemic has proven that having community consensus guidance at hand when dealing with novel conditions in the future is beneficial. The disruption of the IETF's typical schedule of three mostly-in-person meetings per year, is causing it to convert a number of such meetings to fully online meetings. Yet discussions about the possibility of fully or mostly online meetings had been occurring in the IETF community for years as a result of general increases in remote attendance, improvements in web conferencing services, concerns about the environmental impact of travel, and other reasons. It might therefore happen that in-person meeting participation will become less popular and that a significant fraction of participants will be remote. The meeting planning activities that the IESG and the IETF LLC engage in would benefit from IETF community consensus guidance concerning novel aspects raised by these developments. The SHMOO working group is therefore chartered to document high-level guidance and principles to the IESG and the IETF LLC. The guidance and principles will concern the following: - Meeting planning for fully online meetings. Similar to how RFC 8719 establishes guidance for the regional rotation of in-person meetings, the IESG and the LLC would benefit from having community consensus guidelines about the time zone selection, meeting length in days, and other high-level scheduling aspects when an in-person meeting must be canceled. This work item is expected to be fulfilled with the publication of one or more BCPs. - Meeting planning for mostly online, or “hybrid,” meetings. Meetings that have an in-person component but with significantly more remote participants than a mostly-in-person meeting need to be planned with community consensus guidelines, too. While trade-offs have often been addressed in favor of onsite attendees, the IESG and LLC would benefit from having community consensus on high-level guidance about the organization of such hybrid meetings, regarding such things as the meeting schedule, the meeting length in days, acceptable limitations on the maximum allowed or minimum expected onsite attendees, whether and how to schedule and prioritize among onsite activities such as side meetings, the terminal room, the code lounge, and others, and other scheduling aspects. - Ensuring that any fees for remote participation do not become barriers for participation. Since remote participation in mostly-in-person meetings has historically been free, IETF LLC and IESG decisions about the meeting fee structure for remote participation need to be informed by community guidelines to ensure that those for whom a fee is a barrier to participation are still able to participate. This work item is expected to be fulfilled with the publication of one or more BCPs. Suggestions for changing the IETF's overall funding model are out of scope. - The cadence of meeting scheduling and the mix of mostly-in-person, hybrid and fully online meetings going forward as well as the format of meetings, e.g., use of interims compared to components and length of the plenary meeting (week). The working group is expected to document the expected future meeting cadence and format as a BCP if consensus emerges to depart from the existing cadence of three mostly-in-person meetings per year. Notably, any such guidance will not become actionable until 3-4 years after it achieves consensus, given the length of the IETF meeting planning cycle. The work of SHMOO is expected to produce high-level principles, not detailed operational plans. The goal is to produce guidelines for the IESG and the IETF LLC to operationalize while ensuring they have substantial flexibility to continue to deliver and evolve the IETF meeting experience to best serve IETF participants and the Internet community at large. Specifications of details concerning cancellation criteria, meeting technologies, and online meeting agenda formats and content are out of scope. Aside from fee structure, discussion of financial aspects of IETF meetings and changes to RFC 8713 are both out of scope. Scheduling guidance for interim meetings is out of scope. Goals and Milestones: Aug 2022 - Adopt draft for Meeting planning guidelines for replacement online meetings Aug 2022 - Adopt Guidelines for determining meeting fees for fully online meetings Aug 2022 - Adopt draft on cadence of fully online meeting scheduling Dec 2022 - Adopt draft(s) specifying Technology requirements for fully online meetings Dec 2022 - Adopt draft for meeting planning for mostly online, or “hybrid,” meetings Done - Adopt draft for High level guidelines for evaluating cancellation/replacement of in-person meetings Internet-Drafts: - Considerations for Cancellation of IETF Meetings [draft-ietf-shmoo-cancel-meeting-06] (7 pages) - Running an IETF Hackathon [draft-ietf-shmoo-hackathon-08] (23 pages) - Guidelines for the Organization of Fully Online Meetings [draft-ietf-shmoo-online-meeting-05] (10 pages) - Open Participation Principle regarding Remote Registration Fee [draft-ietf-shmoo-remote-fee-07] (7 pages) - Guidelines for the Organization of Fully Online Meetings [draft-kuehlewind-shmoo-online-meeting-04] (10 pages) Requests for Comments: RFC9137: Considerations for Cancellation of IETF Meetings (7 pages) RFC9311: Running an IETF Hackathon (23 pages) Adaptive DNS Discovery (add) ---------------------------- Charter Last Modified: 2022-05-03 Current Status: Active Chairs: David C Lawrence Glenn Deen Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: add@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/add Archive: https://mailarchive.ietf.org/arch/browse/add/ Description of Working Group: Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs, supporting both encrypted and unencrypted resolvers. It is chartered solely to develop technical mechanisms. Making any recommendations about specific policies for clients or servers is out of scope. Clients adopting encrypted DNS protocols need to determine which DNS servers support those protocols, and which server to use for specific queries if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. Network operators that start offering DNS encryption on their servers also need a way to indicate this support to clients. Communicating information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a resolver may be able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the following deliverables: - Define a mechanism that allows clients to discover DNS resolvers that support encryption and that are available to the client either on the public Internet or on private or local networks. - Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions. This could be part of the mechanism used for discovery, above. - Develop an informational document that describes mechanisms for clients to detect specific network environments (such as captive portal and split horizon) and to use that information to inform their DNS configuration. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols and will make sure that those groups are included in major document reviews at appropriate times. It will also work with capport to ensure that solutions are applicable to captive networks. Goals and Milestones: Internet-Drafts: - Requirements for Discovering Designated Resolvers [draft-box-add-requirements-02] (13 pages) - DHCP and Router Advertisement Options for Encrypted DNS Discovery [draft-btw-add-home-12] (32 pages) - Discovery of Designated Resolvers [draft-ietf-add-ddr-10] (20 pages) - DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) [draft-ietf-add-dnr-16] (27 pages) - Requirements for Discovering Designated Resolvers [draft-ietf-add-requirements-00] (13 pages) - DNS Resolver Information [draft-ietf-add-resolver-info-02] (9 pages) - Establishing Local DNS Authority in Validated Split-Horizon Environments [draft-ietf-add-split-horizon-authority-04] (20 pages) - Service Binding Mapping for DNS Servers [draft-ietf-add-svcb-dns-08] (12 pages) - Discovery of Equivalent Encrypted Resolvers [draft-pauly-add-deer-00] (11 pages) - Establishing Local DNS Authority in Split-Horizon Environments [draft-reddy-add-enterprise-split-dns-10] (16 pages) - DNS Resolver Information [draft-reddy-add-resolver-info-06] (8 pages) - Reputation Verified Selection of Upstream Encrypted Resolvers [draft-schwartz-add-ddr-forwarders-02] (13 pages) - Service Binding Mapping for DNS Servers [draft-schwartz-svcb-dns-04] (9 pages) No Requests for Comments Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2022-05-04 Current Status: Active Chairs: Dapeng Liu Satoru Matsushima Sri Gundavelli Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: dmm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmm Archive: https://mailarchive.ietf.org/arch/browse/dmm/ Description of Working Group: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic between mobile and correspondent nodes can take an optimal route. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flattening network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. For example, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. When extending protocols that are not based on Mobile IP, DMM solutions will have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. The working group will produce one or more documents on the following work item topics. o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network-side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit into the overall DMM charter scope as outlined above. Goals and Milestones: Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. Nov 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. Mar 2016 - 'RFC4283bis on MN-IDs as a working group document' submitted to the IESG. Nov 2016 - RFC5149bis on Service Selection as a working group document Mar 2017 - RFC5149bis submitted to IESG. Done - Submit 'Forwarding path and signaling management' as a working group document. Done - Submit 'Enhanced mobility anchoring' as a working group document. Done - Submit 'RFC4283bis on MN-IDs as a working group document'. Done - Submit 'Exposing mobility state to mobile nodes and network nodes' as a working group document(s). Internet-Drafts: - Distributed Mobility Anchoring [draft-chan-dmm-distributed-mobility-anchoring-08] (27 pages) - LMA Controlled MAG Session Parameters [draft-gundavelli-dmm-lma-controlled-mag-params-00] (12 pages) - Mobile Node Identifier Types for MIPv6 [draft-ietf-dmm-4283mnids-08] (16 pages) - User Plane Protocol and Architectural Analysis on 3GPP 5G System [draft-ietf-dmm-5g-uplane-analysis-04] (42 pages) - Distributed Mobility Management: Current Practices and Gap Analysis [draft-ietf-dmm-best-practices-gap-analysis-09] (34 pages) - DMM Deployment Models and Architectural Considerations [draft-ietf-dmm-deployment-models-04] (15 pages) - Distributed Mobility Anchoring [draft-ietf-dmm-distributed-mobility-anchoring-15] (18 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-ietf-dmm-fpc-cpdp-14] (34 pages) - YANG for Protocol for Forwarding Policy Configuration (FPC) [draft-ietf-dmm-fpc-yang-00] (82 pages) - Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) [draft-ietf-dmm-hnprenum-07] (10 pages) - Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor [draft-ietf-dmm-lma-controlled-mag-params-05] (14 pages) - Mobile Access Gateway (MAG) Multipath Options [draft-ietf-dmm-mag-multihoming-07] (15 pages) - On-Demand Mobility Management [draft-ietf-dmm-ondemand-mobility-18] (12 pages) - Proxy Mobile IPv6 Extensions for Distributed Mobility Management [draft-ietf-dmm-pmipv6-dlif-06] (25 pages) - Requirements for Distributed Mobility Management [draft-ietf-dmm-requirements-17] (24 pages) - Segment Routing IPv6 for Mobile User Plane [draft-ietf-dmm-srv6-mobile-uplane-24] (33 pages) - Mobility aware Transport Network Slicing for 5G [draft-ietf-dmm-tn-aware-mobility-06] (26 pages) - MN Identifier Types for RFC 4283 Mobile Node Identifier Option [draft-perkins-dmm-4283mnids-01] (7 pages) - Privacy considerations for DMM [draft-perkins-dmm-privacy-00] (6 pages) - MAG Multipath Binding Option [draft-seite-dmm-rg-multihoming-02] (13 pages) - DMM Deployment Models and Architectural Considerations [draft-wt-dmm-deployment-models-00] (15 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-wt-dmm-fpc-cpdp-00] (26 pages) - Home Network Prefix Renumbering in PMIPv6 [draft-yan-dmm-hnprenum-03] (8 pages) - On Demand Mobility Management [draft-yegin-dmm-ondemand-mobility-03] (10 pages) Requests for Comments: RFC7333: Requirements for Distributed Mobility Management (24 pages) RFC7429: Distributed Mobility Management: Current Practices and Gap Analysis (34 pages) RFC8127: Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor (14 pages) RFC8191: Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) (10 pages) RFC8278: Mobile Access Gateway (MAG) Multipath Options (15 pages) RFC8371: Mobile Node Identifier Types for MIPv6 (16 pages) RFC8653: On-Demand Mobility Management (12 pages) RFC8818: Distributed Mobility Anchoring (18 pages) RFC8885: Proxy Mobile IPv6 Extensions for Distributed Mobility Management (25 pages) DNS PRIVate Exchange (dprive) ----------------------------- Charter Last Modified: 2023-02-02 Current Status: Active Chairs: Brian Haberman Tim Wicinski Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dns-privacy@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy Archive: https://mailarchive.ietf.org/arch/browse/dns-privacy/ Description of Working Group: The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to provide confidentiality to DNS transactions in order to address concerns surrounding pervasive monitoring (RFC 7258). The set of DNS requests that an individual makes can provide an attacker with a large amount of information about that individual. DPRIVE aims to deprive the attacker of this information (The IETF defines pervasive monitoring as an attack [RFC7258]). 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. DPRIVE is chartered to work on mechanisms that add confidentiality to the DNS. While it may be tempting to solve other DNS issues while adding confidentiality, DPRIVE is not the working group to do this. DPRIVE will not work on any integrity-only mechanisms. Examples of the sorts of risks that DPRIVE will address can be found in [RFC 7626], and include both passive wiretapping and more active attacks, such as MITM attacks. DPRIVE will address risks to end-users' privacy (for example, which websites an end user is accessing). DPRIVE Work Items: - Develop requirements for adding confidentiality to DNS exchanges between recursive resolvers and authoritative servers (unpublished document). - Investigate potential solutions for adding confidentiality to DNS exchanges involving authoritative servers (Experimental). - Define, collect and publish performance data measuring effectiveness of DPRIVE-published technologies against pervasive monitoring attacks. - Document Best Current Practices for operating DNS Privacy services. Goals and Milestones: Aug 2020 - Submit draft on DNS privacy exchanges involving authoritative servers (Exp) Done - Unpublished document on requirements for DNS privacy services between recursive and authoritative servers (Wiki) Internet-Drafts: - DNS privacy considerations [draft-bortzmeyer-dnsop-dns-privacy-02] (12 pages) - DNS Privacy Considerations [draft-bortzmeyer-dprive-rfc7626-bis-02] (23 pages) - Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS [draft-dgr-dprive-dtls-and-tls-profiles-00] (17 pages) - Recommendations for DNS Privacy Service Operators [draft-dickinson-dprive-bcp-op-01] (32 pages) - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS [draft-dkgjsal-dprive-unilateral-probing-02] (24 pages) - Using Early Data in DNS over TLS [draft-ghedini-dprive-early-data-02] (6 pages) - Authoritative DNS-over-TLS Operational Considerations [draft-hal-adot-operational-considerations-02] (14 pages) - Specification of DNS over Dedicated QUIC Connections [draft-huitema-dprive-dnsoquic-00] (19 pages) - TLS for DNS: Initiation and Performance Considerations [draft-hzhwm-dprive-start-tls-for-dns-02] (15 pages) - DNS Zone Transfer-over-TLS [draft-hzpa-dprive-xfr-over-tls-02] (18 pages) - Recommendations for DNS Privacy Service Operators [draft-ietf-dprive-bcp-op-14] (34 pages) - DNS over Datagram Transport Layer Security (DTLS) [draft-ietf-dprive-dnsodtls-15] (13 pages) - DNS over Dedicated QUIC Connections [draft-ietf-dprive-dnsoquic-12] (27 pages) - Specification for DNS over Transport Layer Security (TLS) [draft-ietf-dprive-dns-over-tls-09] (19 pages) - Usage Profiles for DNS over TLS and DNS over DTLS [draft-ietf-dprive-dtls-and-tls-profiles-11] (27 pages) - Using Early Data in DNS over TLS [draft-ietf-dprive-early-data-00] (6 pages) - The EDNS(0) Padding Option [draft-ietf-dprive-edns0-padding-03] (5 pages) - Evaluation of Privacy for DNS Private Exchange [draft-ietf-dprive-eval-00] (22 pages) - Recursive to Authoritative DNS with Unauthenticated Encryption [draft-ietf-dprive-opportunistic-adotq-02] (10 pages) - Padding Policies for Extension Mechanisms for DNS (EDNS(0)) [draft-ietf-dprive-padding-policy-06] (9 pages) - DNS Privacy Requirements for Exchanges between Recursive Resolvers and Authoritative Servers [draft-ietf-dprive-phase2-requirements-02] (10 pages) - DNS Privacy Considerations [draft-ietf-dprive-problem-statement-06] (17 pages) - DNS Privacy Considerations [draft-ietf-dprive-rfc7626-bis-09] (22 pages) - TLS for DNS: Initiation and Performance Considerations [draft-ietf-dprive-start-tls-for-dns-01] (18 pages) - Recursive to Authoritative DNS with Unauthenticated Encryption [draft-ietf-dprive-unauth-to-authoritative-04] (11 pages) - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS [draft-ietf-dprive-unilateral-probing-06] (30 pages) - DNS Zone Transfer over TLS [draft-ietf-dprive-xfr-over-tls-12] (32 pages) - Padding Profiles for EDNS(0) [draft-mayrhofer-dprive-padding-profile-00] (6 pages) - Recursive to Authoritative DNS with Opportunistic Encryption [draft-pp-recursive-authoritative-opportunistic-04] (9 pages) - DNS over DTLS (DNSoD) [draft-wing-dprive-dnsodtls-01] (13 pages) Requests for Comments: BCP232: Recommendations for DNS Privacy Service Operators (34 pages) RFC7626: DNS Privacy Considerations (17 pages) * Obsoletes RFC9076 RFC7830: The EDNS(0) Padding Option (5 pages) RFC7858: Specification for DNS over Transport Layer Security (TLS) (19 pages) * Updates RFC8310 RFC8094: DNS over Datagram Transport Layer Security (DTLS) (13 pages) RFC8310: Usage Profiles for DNS over TLS and DNS over DTLS (27 pages) RFC8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0)) (9 pages) RFC8932: Recommendations for DNS Privacy Service Operators (34 pages) RFC9076: DNS Privacy Considerations (22 pages) RFC9103: DNS Zone Transfer over TLS (32 pages) RFC9250: DNS over Dedicated QUIC Connections (27 pages) Drone Remote ID Protocol (drip) ------------------------------- Charter Last Modified: 2023-02-23 Current Status: Active Chairs: Daniel Migault Mohamed Boucadair Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: tm-rid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tm-rid Archive: https://mailarchive.ietf.org/arch/browse/tm-rid/ Description of Working Group: Civil Aviation Authorities (CAAs) worldwide have initiated rule making for Unmanned Aircraft Systems (UAS) Remote Identification (RID). CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry-consensus technical standards as acceptable means of compliance. One key standard is ASTM International (formerly the American Society for Testing and Materials) WK65041 [1]. This technical specification defines UAS RID message formats, and transmission methods. Network RID defines a set of information for UAS to be made available globally via the Internet. Broadcast RID defines a set of messages for UAS to send locally one-way over Bluetooth or Wi-Fi. WK65041 does not address how to populate/query registries, how to ensure trustworthiness of information, nor how to make the information useful. DRIP’s goal is to specify how RID can be made trustworthy and available in both Internet and local-only connected scenarios, especially in emergency situations. Some UAS operate in environments where the network or the devices or both are severely constrained [2] in terms of processing, bandwidth (e.g., Bluetooth 4 beacon payload is 25 bytes long), or battery life, and DRIP aims to function in these environments. The specifications produced by the WG will need to balance public safety authorities’ need to know trustworthy information with UAS operators’ and other involved parties’ privacy. The working group will primarily leverage Internet standards (including HIP, EPP, RDAP, and DNS) and infrastructure as well as domain name registration business models. The WG will track and align with the requirements being developed by regulatory authorities, e.g., the International Civil Aviation Organization the European Union Aviation Safety Agency (EASA) delegated [3] and implementing [4] regulations, and the US Federal Aviation Administration (US FAA) [5]. The working group will work on the following items: * Requirements: the WG is expected to provide an informational document that lists the technical requirements for applying IETF protocols to the UAS Remote Identification (UAS RID) - that is the system for identifying Unmanned Aircraft (UA) during flight by other parties. These requirements also include showing that new or adapted identifiers from existing protocols conform and meet the specifications to be certified as a UAS RID. * Architecture: the WG will propose a standard document that describes the architecture that address the technical requirements and that will attempt to re-use protocols or architectures already standardized at the IETF. * Protocol design: while the primary purpose of DRIP WG is to leverage existing protocols, the specificities of the UAS environment are likely to require existing protocols to be extended or new protocols to be designed. The WG will focus on getting these protocols or extensions standardized, coordinating with other WGs relevant for the protocol(s) in question on the most appropriate home for any given piece of work. References: [1] ASTM International F38 Committee Work Item WK65041 “Standard Specification for UAS Remote ID and Tracking” https://www.astm.org/DATABASE.CART/WORKITEMS/WK65041.htm [2] UAS Identification and Tracking Aviation Rulemaking Committee Recommendations Final Report 2017 SEP 30 https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf [3] https://eur-lex.europa.eu/eli/reg_del/2019/945/oj [4] https://eur-lex.europa.eu/eli/reg_impl/2019/947/ojeg_impl/2019/947/oj [5] Notice of Proposed Rule Making (NPRM) https://www.federalregister.gov/documents/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems Goals and Milestones: Jun 2022 - Submit DRIP Authentication Formats to the IESG Dec 2022 - Submit DRIP Registries to the IESG Done - Requirements and architecture drafts adopted by the WG Done - Requirements and architecture drafts in the WGLC Done - Solution space documents adopted by the WG Done - Submit Requirements Document to the IESG Done - Submit DRIP Architecture Document to the IESG Done - Submit DRIP UAS Remote ID to the IESG Internet-Drafts: - Drone Remote Identification Protocol (DRIP) Architecture [draft-card-drip-arch-02] (16 pages) - Drone Remote Identification Protocol (DRIP) Requirements [draft-card-drip-reqs-02] (18 pages) - Drone Remote Identification Protocol (DRIP) Architecture [draft-ietf-drip-arch-31] (31 pages) - DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID [draft-ietf-drip-auth-30] (48 pages) - DRIP Entity Tag (DET) Identity Management Architecture [draft-ietf-drip-registries-09] (38 pages) - Drone Remote Identification Protocol (DRIP) Requirements and Terminology [draft-ietf-drip-reqs-18] (41 pages) - DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) [draft-ietf-drip-rid-37] (34 pages) - UAS Remote ID [draft-ietf-drip-uas-rid-01] (19 pages) - DRIP Authentication Formats [draft-wiethuechter-drip-auth-06] (22 pages) - DRIP Registries [draft-wiethuechter-drip-registries-01] (36 pages) Requests for Comments: RFC9153: Drone Remote Identification Protocol (DRIP) Requirements and Terminology (41 pages) RFC9374: DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) (34 pages) Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Bernie Volz Timothy Winters Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: https://mailarchive.ietf.org/arch/browse/dhcwg/ Description of Working Group: The Dynamic Host Configuration Working Group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses, IPv6 prefixes, IP protocol stack and other parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is being updated. The WG plans to advance the DHCPv6 protocol to Internet standard. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are generally outside of scope for the DHC WG. Such options should be defined within their respective WGs or sponsored by an appropriate AD and reviewed by DHCP experts in the Internet Area Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Work on informational documents providing operational or implementation advice about DHCPv6, as well as documents specifying standard mechanisms for operating, administering and managing DHCPv6 servers, clients, and relay agents. 2. Assist other WGs and independent submissions in defining options (that follow RFC 7227 guidelines) and to assure DHCP operational considerations are properly documented. 3. Issue an updated version of the DHCPv6 base specification, and after an appropriate interval following publication, advance to Internet standard. Goals and Milestones: Jan 2023 - Advance 3315bis RFC to Internet Standard Mar 2023 - Recharter or close down WG Done - WGLC draft-ietf-dhc-dhcp4o6-saddr-opt Done - WGLC SLAP quadrant selection options for DHCPv6 Done - WGLC Link-Layer Addresses Assignment Mechanism for DHCPv6 Done - Adopt DHCPv6 Prefix Delegating relay Done - Adopt IPv6-Only-Preferred Option for DHCP Done - WGLC Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Done - WGLC IPv6-Only-Preferred Option for DHCP Done - WGLC DHCPv6 Prefix Delegating relay Done - WGLC draft-ietf-dhc-dhcpv6-yang Internet-Drafts: - SLAP quadrant selection options for DHCPv6 [draft-bernardos-dhc-slap-quadrant-01] (15 pages) - Access-Network-Identifier Option in DHCP [draft-bhandari-dhc-access-network-identifier-04] (17 pages) - Link-Layer Addresses Assignment Mechanism for DHCPv6 [draft-bvtm-dhc-mac-assign-02] (18 pages) - Dynamic Allocation of Shared IPv4 Addresses [draft-csf-dhc-dynamic-shared-v4allocation-00] (13 pages) - Handling Unknown DHCPv6 Messages [draft-csl-dhc-dhcpv6-unknown-msg-3315update-00] (4 pages) - DHCPv6 Prefix Length Hint Issues [draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03] (9 pages) - YANG Data Model for DHCPv6 Configuration [draft-cui-dhc-dhcpv6-yang-04] (81 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis [draft-dhcwg-dhc-rfc3315bis-04] (126 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-dhcwg-dhc-rfc8415bis-00] (135 pages) - Forcerenew Reconfiguration Extensions for DHCPv4 [draft-fang-dhc-dhcpv4-forcerenew-extensions-02] (7 pages) - DHCPv6 Prefix Delegating relay [draft-fkhp-dhc-dhcpv6-pd-relay-requirements-03] (11 pages) - DHCPv4 over DHCPv6 Source Address Option [draft-fsc-softwire-dhcp4o6-saddr-opt-07] (9 pages) - DHCP Relay Initiated Release [draft-gandhewar-dhc-relay-initiated-release-01] (11 pages) - DHCPv6 Relay Initiated Release [draft-gandhewar-dhc-v6-relay-initiated-release-01] (14 pages) - A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-gont-dhc-stable-privacy-addresses-01] (8 pages) - Anonymity profile for DHCP clients [draft-huitema-dhc-anonymity-profile-02] (19 pages) - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) [draft-ietf-dhc-3315id-for-v4-05] (12 pages) - IEEE 802.11 parameters DHCP Option [draft-ietf-dhc-80211-option-01] (5 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - Access-Network-Identifier Option in DHCP [draft-ietf-dhc-access-network-identifier-13] (20 pages) - Registering Self-generated IPv6 Addresses in DNS using DHCPv6 [draft-ietf-dhc-addr-registration-07] (10 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-11] (14 pages) - The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option [draft-ietf-dhc-agentoptions-device-class-04] (5 pages) - Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option [draft-ietf-dhc-agentopt-radius-08] (8 pages) - Link Selection sub-option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-subnet-selection-04] (9 pages) - Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-vpn-id-06] (11 pages) - Anonymity Profiles for DHCP Clients [draft-ietf-dhc-anonymity-profile-08] (26 pages) - The Autonomous System Option for DHCP [draft-ietf-dhc-asnum-00] (5 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - DHCP RSA/DSA Authentication using DNS KEY records [draft-ietf-dhc-auth-sigzero-00] (0 pages) - The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-auth-suboption-05] (15 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-04] (9 pages) - Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-05] (11 pages) - DHCPv4 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv4-option-00] (12 pages) - DHCPv6 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv6-option-00] (14 pages) - Interoperation Between DHCP and BOOTP [draft-ietf-dhc-between-bootp-02] (4 pages) - Clarifications and Extensions for the Bootstrap Protocol [draft-ietf-dhc-bootp-01] (22 pages) - DHCP Options for Call Control Servers [draft-ietf-dhc-callcontrolserv-00] (4 pages) - Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 [draft-ietf-dhc-cga-config-dhcpv6-04] (10 pages) - Client Identifier Option in DHCP Server Replies [draft-ietf-dhc-client-id-07] (5 pages) - Interpreting Client Options for the Dynamic Host Configuration Protocol [draft-ietf-dhc-client-options-00] (24 pages) - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) [draft-ietf-dhc-concat-05] (9 pages) - IP Connectivity Status Notifications for DHCPv6 [draft-ietf-dhc-conn-status-00] (10 pages) - Container Option for Server Configuration [draft-ietf-dhc-container-opt-07] (9 pages) - The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 [draft-ietf-dhc-csr-07] (9 pages) - Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients [draft-ietf-dhc-ddns-resolution-12] (13 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-dhcp-08] (45 pages) - Softwire Provisioning Using DHCPv4 over DHCPv6 [draft-ietf-dhc-dhcp4o6-saddr-opt-08] (18 pages) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 pages) - Privacy Considerations for DHCP [draft-ietf-dhc-dhcp-privacy-05] (14 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - Active DHCPv4 Lease Query [draft-ietf-dhc-dhcpv4-active-leasequery-07] (28 pages) - DHCPv4 Bulk Leasequery [draft-ietf-dhc-dhcpv4-bulk-leasequery-07] (41 pages) - Forcerenew Reconfiguration Extensions for DHCPv4 [draft-ietf-dhc-dhcpv4-forcerenew-extensions-02] (7 pages) - DHCPv4-over-DHCPv6 (DHCP 4o6) Transport [draft-ietf-dhc-dhcpv4-over-dhcpv6-09] (16 pages) - DHCPv4 over IPv6 Transport [draft-ietf-dhc-dhcpv4-over-ipv6-09] (14 pages) - DHCPv4 Vendor-specific Message [draft-ietf-dhc-dhcpv4-vendor-message-01] (7 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-28] (101 pages) - DHCPv6 Active Leasequery [draft-ietf-dhc-dhcpv6-active-leasequery-04] (30 pages) - DHCPv6 Relay Agent Assignment Notification (RAAN) Option [draft-ietf-dhc-dhcpv6-agentopt-delegate-05] (9 pages) - DHCPv6 Bulk Leasequery [draft-ietf-dhc-dhcpv6-bulk-leasequery-06] (18 pages) - Clarifications on DHCPv6 Authentication [draft-ietf-dhc-dhcpv6-clarify-auth-01] (14 pages) - Client Link-Layer Address Option in DHCPv6 [draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05] (7 pages) - Configured Tunnel End Point Option for DHCPv6 [draft-ietf-dhc-dhcpv6-ctep-opt-02] (6 pages) - DHCPv6 Relay Agent Echo Request Option [draft-ietf-dhc-dhcpv6-ero-01] (6 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - DHCPv6 Failover Design [draft-ietf-dhc-dhcpv6-failover-design-04] (59 pages) - DHCPv6 Failover Protocol [draft-ietf-dhc-dhcpv6-failover-protocol-06] (96 pages) - DHCPv6 Failover Requirements [draft-ietf-dhc-dhcpv6-failover-requirements-07] (17 pages) - The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option [draft-ietf-dhc-dhcpv6-fqdn-05] (15 pages) - Results from Interoperability Tests of DHCPv6 Implementations [draft-ietf-dhc-dhcpv6-interop-01] (12 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-03] (17 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcpv6-leasequery-01] (23 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-02] (6 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-load-balancing-02] (6 pages) - DHCPv6 Options for LWM2M bootstrap information [draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options-00] (10 pages) - Client Preferred Prefix option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01] (6 pages) - DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-opt-dnsconfig-04] (7 pages) - Domain Suffix Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsdomain-04] (7 pages) - DSTM Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-01] (7 pages) - DSTM Ports Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-ports-01] (4 pages) - DHCPv6 Options for Network Boot [draft-ietf-dhc-dhcpv6-opt-netboot-10] (11 pages) - Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-opt-nisconfig-05] (7 pages) - The Name Service Search Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nss-00] (6 pages) - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 [draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05] (19 pages) - DHCPv6 Support for Remote Boot [draft-ietf-dhc-dhcpv6-opt-rboot-00] (6 pages) - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-sntp-01] (5 pages) - Time Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-timeconfig-03] (8 pages) - Timezone Specifier Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-tz-00] (6 pages) - DHCPv6 Prefix Delegating Relay Requirements [draft-ietf-dhc-dhcpv6-pd-relay-requirements-05] (11 pages) - DHCPv6 Prefix-Length Hint Issues [draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06] (9 pages) - Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers [draft-ietf-dhc-dhcpv6-prefix-pool-opt-03] (13 pages) - Privacy Considerations for DHCPv6 [draft-ietf-dhc-dhcpv6-privacy-05] (18 pages) - RADIUS Option for the DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-radius-opt-14] (10 pages) - Rebind Capability in DHCPv6 Reconfigure Messages [draft-ietf-dhc-dhcpv6-reconfigure-rebind-10] (10 pages) - DHCPv6 Redundancy Deployment Considerations [draft-ietf-dhc-dhcpv6-redundancy-consider-03] (16 pages) - Relay-Supplied DHCP Options [draft-ietf-dhc-dhcpv6-relay-supplied-options-09] (8 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option [draft-ietf-dhc-dhcpv6-remoteid-01] (6 pages) - Time Protocol Servers and Time Offset Options for IPv6 DHCP [draft-ietf-dhc-dhcpv6-rfc868-servers-00] (6 pages) - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT [draft-ietf-dhc-dhcpv6-solmaxrt-update-05] (7 pages) - DHCPv6 Server Reply Sequence Number Option [draft-ietf-dhc-dhcpv6-srsn-option-02] (7 pages) - Issues and Recommendations with Multiple Stateful DHCPv6 Options [draft-ietf-dhc-dhcpv6-stateful-issues-12] (24 pages) - Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 [draft-ietf-dhc-dhcpv6-stateless-04] (9 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option [draft-ietf-dhc-dhcpv6-subid-01] (6 pages) - DHCPv6 through Tunnels [draft-ietf-dhc-dhcpv6-tunnel-01] (5 pages) - Handling Unknown DHCPv6 Messages [draft-ietf-dhc-dhcpv6-unknown-msg-08] (7 pages) - DHCPv6 Vendor-specific Message [draft-ietf-dhc-dhcpv6-vendor-message-01] (6 pages) - A YANG Data Model for DHCPv6 Configuration [draft-ietf-dhc-dhcpv6-yang-25] (92 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - Detecting Network Attachment in IPv4 (DNAv4) [draft-ietf-dhc-dna-ipv4-18] (15 pages) - Populating the DNS Reverse Tree for DHCP Delegated Prefixes [draft-ietf-dhc-dns-pd-01] (13 pages) - The Domain Search Option for DHCP [draft-ietf-dhc-domsrch-02] (4 pages) - Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues [draft-ietf-dhc-dual-stack-04] (14 pages) - Dual-stack clients and merging of data from DHCPv4 and DHCPv6 [draft-ietf-dhc-dual-stack-merge-01] (8 pages) - Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) [draft-ietf-dhc-duid-uuid-03] (5 pages) - Dynamic Allocation of Shared IPv4 Addresses [draft-ietf-dhc-dynamic-shared-v4allocation-09] (15 pages) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - Requirements for Extending DHCP into New Environments [draft-ietf-dhc-enhance-requirements-00] (15 pages) - Extending DHCP Options Codes [draft-ietf-dhc-extended-optioncodes-00] (9 pages) - DHCP Failover Protocol [draft-ietf-dhc-failover-12] (133 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-07] (12 pages) - An option for FQDNs in DHCP options [draft-ietf-dhc-fqdn-opt-03] (4 pages) - The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option [draft-ietf-dhc-fqdn-option-13] (17 pages) - Prefix Assignment in DHCPv6 [draft-ietf-dhc-host-gen-id-05] (11 pages) - Considerations for the use of the Host Name option [draft-ietf-dhc-host-option-considerations-02] (8 pages) - Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)" [draft-ietf-dhc-implementation-02] (41 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-02] (89 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-alt-00] (53 pages) - Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network [draft-ietf-dhc-ipv4-autoconfig-05] (8 pages) - The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service [draft-ietf-dhc-isnsoption-13] (13 pages) - Wireless Key Management using DHCP [draft-ietf-dhc-key-management-00] (0 pages) - Layer 2 Relay Agent Information [draft-ietf-dhc-l2ra-06] (13 pages) - Extensions to Layer 2 Relay Agent [draft-ietf-dhc-l2ra-extensions-01] (22 pages) - LDAP Schema for DHCP [draft-ietf-dhc-ldap-schema-00] (18 pages) - Dynamic Host Configuration Protocol (DHCP) Leasequery [draft-ietf-dhc-leasequery-09] (27 pages) - DHCPv4 Lease Query by Relay Agent Remote ID [draft-ietf-dhc-leasequery-by-remote-id-09] (13 pages) - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-lifetime-03] (8 pages) - DHC Load Balancing Algorithm [draft-ietf-dhc-loadb-03] (10 pages) - Link-Layer Address Assignment Mechanism for DHCPv6 [draft-ietf-dhc-mac-assign-09] (18 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 pages) - The Named Pool Request Option for DHCP [draft-ietf-dhc-namedpool-00] (4 pages) - NetWare/IP Domain Name and Information [draft-ietf-dhc-netware-options-00] (6 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-05] (5 pages) - Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-02] (7 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - DHCP Next Server Option [draft-ietf-dhc-nextserver-02] (0 pages) - The Name Service Search Option for DHCP [draft-ietf-dhc-nsso-05] (5 pages) - The Extended Remote Boot Option for DHCPv4 [draft-ietf-dhc-opt-extrboot-00] (7 pages) - Guidelines for Creating New DHCPv6 Options [draft-ietf-dhc-option-guidelines-17] (35 pages) - New Option Review Guidelines and Additional Option Namespace [draft-ietf-dhc-option-review-and-namespace-02] (14 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-03] (30 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-1533update-05] (34 pages) - DHCP Continuation Option Code [draft-ietf-dhc-options-cont-01] (3 pages) - An Extension to the DHCP Option Codes [draft-ietf-dhc-options-opt127-03] (3 pages) - DHCP Option for The Open Group's User Authentication Protocol [draft-ietf-dhc-options-uap-02] (4 pages) - DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents [draft-ietf-dhc-paa-option-05] (8 pages) - Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration [draft-ietf-dhc-packetcable-06] (13 pages) - Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude-04] (10 pages) - PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option [draft-ietf-dhc-pktc-kerb-tckt-03] (7 pages) - DHCPv6 Extension Practices and Considerations [draft-ietf-dhc-problem-statement-of-mredhcpv6-08] (15 pages) - Dynamic Configuration of Internet Hosts [draft-ietf-dhc-problem-stmt-00] (0 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-protocol-06] (39 pages) - DHCP Option for Proxy Server Configuration [draft-ietf-dhc-proxyserver-opt-05] (8 pages) - DHCP reconfigure extension [draft-ietf-dhc-pv4-reconfigure-06] (6 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-03] (14 pages) - Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-03] (7 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-rapid-commit-opt-05] (10 pages) - Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options [draft-ietf-dhc-reclassify-options-01] (7 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-relay-agent-auth-01] (16 pages) - The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption [draft-ietf-dhc-relay-agent-flags-03] (7 pages) - Authentication of DHCP Relay Agent Options Using IPsec [draft-ietf-dhc-relay-agent-ipsec-02] (10 pages) - The DHCPv4 Relay Agent Identifier Sub-Option [draft-ietf-dhc-relay-id-suboption-13] (8 pages) - Generalized UDP Source Port for DHCP Relay [draft-ietf-dhc-relay-port-10] (10 pages) - Security of Messages Exchanged between Servers and Relay Agents [draft-ietf-dhc-relay-server-security-05] (8 pages) - Graceful renumbering of networks with DHCP [draft-ietf-dhc-renumbering-00] (8 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-rfc3315bis-13] (154 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-rfc8415bis-00] (135 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Secure DHCPv6 Using CGAs [draft-ietf-dhc-secure-dhcpv6-07] (18 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 pages) - Security Requirements for the DHCP protocol [draft-ietf-dhc-security-requirements-00] (12 pages) - Secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21] (31 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB [draft-ietf-dhc-server-mib-10] (37 pages) - DHCP Server Identifier Override Suboption [draft-ietf-dhc-server-override-05] (7 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 [draft-ietf-dhc-slap-quadrant-12] (16 pages) - DHCP Options for Service Location Protocol [draft-ietf-dhc-slp-07] (6 pages) - Service-Oriented Address Assignment using DHCPv6 [draft-ietf-dhc-soa-option-00] (9 pages) - The Server Selection Option for DHCP [draft-ietf-dhc-sso-03] (14 pages) - A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-stable-privacy-addresses-02] (10 pages) - Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-stateless-dhcpv6-renumbering-02] (8 pages) - Description of Cisco Systems' Subnet Allocation Option for DHCPv4 [draft-ietf-dhc-subnet-alloc-13] (24 pages) - The IPv4 Subnet Selection Option for DHCP [draft-ietf-dhc-subnet-option-07] (7 pages) - Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option [draft-ietf-dhc-suboptions-kdc-serveraddress-04] (7 pages) - Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-subscriber-id-07] (7 pages) - Subnet Selection Option for DHCP [draft-ietf-dhc-subsel-00] (5 pages) - DHCP Option for IEEE 1003.1 POSIX Timezone Specifications [draft-ietf-dhc-timezone-03] (3 pages) - Timezone Options for DHCP [draft-ietf-dhc-timezone-option-05] (10 pages) - Customizing DHCP Configuration on the Basis of Network Topology [draft-ietf-dhc-topo-conf-09] (20 pages) - Triggering DHCPv6 Reconfiguration from Relay Agents [draft-ietf-dhc-triggered-reconfigure-07] (13 pages) - Unused Dynamic Host Configuration Protocol (DHCP) Option Codes [draft-ietf-dhc-unused-optioncodes-07] (8 pages) - DHCP Use of the User Class Option for Address Assignment [draft-ietf-dhc-useraddr-00] (5 pages) - The User Class Option for DHCP [draft-ietf-dhc-userclass-10] (6 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-ietf-dhc-v4configuration-06] (17 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - IPv6-Only Preferred Option for DHCPv4 [draft-ietf-dhc-v6only-08] (12 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-vendor-03] (9 pages) - Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-vendor-suboption-00] (7 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-15] (26 pages) - Privacy considerations for DHCP [draft-jiang-dhc-dhcp-privacy-00] (12 pages) - Secure DHCPv6 with Public Key [draft-jiang-dhc-sedhcpv6-02] (16 pages) - Privacy considerations for DHCPv6 [draft-krishnan-dhc-dhcpv6-privacy-00] (14 pages) - Customizing DHCP Configuration on the Basis of Network Topology [draft-lemon-dhc-topo-conf-01] (9 pages) - secure DHCPv6 deployment [draft-li-dhc-secure-dhcpv6-deployment-03] (7 pages) - IPv6-Only-Preferred Option for DHCP [draft-link-dhc-v6only-01] (10 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-01] (5 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-rajtar-dhc-v4configuration-02] (13 pages) - Problem Statement of Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ren-dhc-problem-statement-of-mredhcpv6-01] (11 pages) - DHCPv4 over DHCPv6 Transport [draft-scskf-dhc-dhcpv4-over-dhcpv6-01] (8 pages) - Generalized Source UDP Port of DHCP Relay [draft-shen-dhc-client-port-03] (7 pages) - The IPv6 Address-based DHCPv6 Unique Identifier (DUID-V6ADDR) [draft-templin-duid-ipv6-01] (7 pages) - Security of Messages Exchanged Between Servers and Relay Agents [draft-volz-dhc-relay-server-security-02] (8 pages) - DHCPv6 Dynamic Reconfiguration [draft-wing-dhc-dns-reconfigure-02] (9 pages) - Registering Self-generated IPv6 Addresses using DHCPv6 [draft-wkumari-dhc-addr-notification-07] (11 pages) Requests for Comments: BCP180: DHCPv6 Redundancy Deployment Considerations (16 pages) BCP187: Guidelines for Creating New DHCPv6 Options (35 pages) BCP29: Procedure for Defining New DHCP Options (5 pages) BCP43: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) RFC1531: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1541 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Obsoletes RFC1542 RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC2132 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC2131: Dynamic Host Configuration Protocol (45 pages) * Updates RFC3396 * Updates RFC4361 * Updates RFC5494 * Updates RFC6842 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Updates RFC3442 * Updates RFC3942 * Updates RFC4361 * Updates RFC4833 * Updates RFC5494 RFC2241: DHCP Options for Novell Directory Services (5 pages) RFC2242: NetWare/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (4 pages) RFC2489: Procedure for Defining New DHCP Options (5 pages) * Obsoletes RFC2939 RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) * Updates RFC8925 RFC2610: DHCP Options for Service Location Protocol (6 pages) RFC2937: The Name Service Search Option for DHCP (5 pages) RFC2939: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) RFC3004: The User Class Option for DHCP (6 pages) RFC3011: The IPv4 Subnet Selection Option for DHCP (7 pages) RFC3046: DHCP Relay Agent Information Option (14 pages) * Updates RFC6607 RFC3074: DHC Load Balancing Algorithm (10 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) * Updates RFC6704 RFC3256: The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option (5 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (101 pages) * Updates RFC4361 * Updates RFC5494 * Updates RFC6221 * Updates RFC6422 * Updates RFC6644 * Updates RFC7083 * Updates RFC7227 * Updates RFC7283 * Updates RFC7550 * Obsoletes RFC8415 RFC3396: Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) (9 pages) RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (13 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (9 pages) RFC3594: PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option (7 pages) RFC3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 (19 pages) * Updates RFC6603 * Updates RFC7550 * Obsoletes RFC8415 RFC3634: Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option (7 pages) RFC3646: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (7 pages) RFC3679: Unused Dynamic Host Configuration Protocol (DHCP) Option Codes (8 pages) * Updates RFC8910 RFC3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 (9 pages) * Obsoletes RFC8415 RFC3898: Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (7 pages) RFC3925: Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) (9 pages) RFC3942: Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options (7 pages) RFC3993: Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (7 pages) RFC4014: Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (8 pages) RFC4030: The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (15 pages) RFC4039: Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (10 pages) RFC4075: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (5 pages) RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4174: The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service (13 pages) * Updates RFC7146 RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) * Obsoletes RFC8415 RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (7 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (11 pages) RFC4361: Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (12 pages) * Updates RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) * Updates RFC6148 RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (15 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (7 pages) RFC4580: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (6 pages) RFC4649: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (6 pages) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (13 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4833: Timezone Options for DHCP (10 pages) RFC4994: DHCPv6 Relay Agent Echo Request Option (6 pages) RFC5007: DHCPv6 Leasequery (23 pages) RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (7 pages) RFC5071: Dynamic Host Configuration Protocol Options Used by PXELINUX (14 pages) RFC5107: DHCP Server Identifier Override Suboption (7 pages) RFC5192: DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents (8 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) * Updates RFC7653 RFC5970: DHCPv6 Options for Network Boot (11 pages) RFC6148: DHCPv4 Lease Query by Relay Agent Remote ID (13 pages) RFC6221: Lightweight DHCPv6 Relay Agent (17 pages) RFC6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (5 pages) RFC6422: Relay-Supplied DHCP Options (8 pages) RFC6603: Prefix Exclude Option for DHCPv6-based Prefix Delegation (10 pages) RFC6607: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (26 pages) RFC6644: Rebind Capability in DHCPv6 Reconfigure Messages (10 pages) RFC6656: Description of Cisco Systems' Subnet Allocation Option for DHCPv4 (24 pages) RFC6704: Forcerenew Nonce Authentication (12 pages) RFC6842: Client Identifier Option in DHCP Server Replies (5 pages) RFC6853: DHCPv6 Redundancy Deployment Considerations (16 pages) RFC6925: The DHCPv4 Relay Agent Identifier Sub-Option (8 pages) RFC6926: DHCPv4 Bulk Leasequery (41 pages) * Updates RFC7724 RFC6939: Client Link-Layer Address Option in DHCPv6 (7 pages) RFC6977: Triggering DHCPv6 Reconfiguration from Relay Agents (13 pages) RFC7031: DHCPv6 Failover Requirements (17 pages) RFC7037: RADIUS Option for the DHCPv6 Relay Agent (10 pages) RFC7083: Modification to Default Values of SOL_MAX_RT and INF_MAX_RT (7 pages) * Obsoletes RFC8415 RFC7227: Guidelines for Creating New DHCPv6 Options (35 pages) RFC7283: Handling Unknown DHCPv6 Messages (7 pages) * Obsoletes RFC8415 RFC7341: DHCPv4-over-DHCPv6 (DHCP 4o6) Transport (16 pages) RFC7550: Issues and Recommendations with Multiple Stateful DHCPv6 Options (24 pages) * Obsoletes RFC8415 RFC7618: Dynamic Allocation of Shared IPv4 Addresses (15 pages) RFC7653: DHCPv6 Active Leasequery (30 pages) RFC7724: Active DHCPv4 Lease Query (28 pages) RFC7819: Privacy Considerations for DHCP (14 pages) RFC7824: Privacy Considerations for DHCPv6 (18 pages) RFC7839: Access-Network-Identifier Option in DHCP (20 pages) RFC7844: Anonymity Profiles for DHCP Clients (26 pages) RFC7969: Customizing DHCP Configuration on the Basis of Network Topology (20 pages) RFC8156: DHCPv6 Failover Protocol (96 pages) RFC8168: DHCPv6 Prefix-Length Hint Issues (9 pages) RFC8213: Security of Messages Exchanged between Servers and Relay Agents (8 pages) RFC8357: Generalized UDP Source Port for DHCP Relay (10 pages) RFC8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (154 pages) RFC8539: Softwire Provisioning Using DHCPv4 over DHCPv6 (18 pages) RFC8925: IPv6-Only Preferred Option for DHCPv4 (12 pages) RFC8947: Link-Layer Address Assignment Mechanism for DHCPv6 (18 pages) RFC8948: Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 (16 pages) RFC8987: DHCPv6 Prefix Delegating Relay Requirements (11 pages) RFC9243: A YANG Data Model for DHCPv6 Configuration (92 pages) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- Charter Last Modified: 2023-02-02 Current Status: Active Chairs: Chris Box David Schinazi Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: dnssd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd Archive: https://mailarchive.ietf.org/arch/browse/dnssd/ Description of Working Group: Background ---------- Zero configuration networking protocols are currently well suited to discover services within the scope of a single link. In particular, the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes referred to using Apple Computer Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery and host name resolution on a single link. The DNS-SD/mDNS protocol suite is used in many scenarios including home, campus, and enterprise networks. However, the zero configuration mDNS protocol is constrained to link-local multicast scope by design, and therefore cannot be used to discover services on remote links. In a home network that consists of a single (possibly bridged) link, users experience the expected discovery behavior; available services appear because all devices share a common link. However, in multi-link home networks (as envisaged by the homenet WG) or in routed campus or enterprise networks, devices and users can only discover services on the same link, which is a significant limitation. This has led to calls, such as the Educause petition, to develop an appropriate service discovery solution to span multiple links or to perform discovery across a wide area, not necessarily on directly connected links. In addition, the "Smart Energy Profile 2 Application Protocol Standard", published by ZigBee Alliance and HomePlug Powerline Alliance specifies the DNS-SD/mDNS protocol suite as the basis for its method of zero configuration service discovery. However, its use of wireless mesh multi-link subnets in conjunction with traditional routed networks will require extensions to the DNS-SD/mDNS protocols to allow operation across multiple links. The scenarios in which multi-link service discovery is required may be zero configuration environments, environments where administrative configuration is supported, or a mixture of the two. As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship proprietary solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towards producing a single, standards-based solution. Working Group Description ------------------------- The focus of the WG is to develop a solution for extended, scalable DNS-SD. This work is likely to highlight problems and challenges with naming protocols, as some level of coexistence will be required between local zero configuration name services and those forming part of the global DNS. It is important that these issues are captured and documented for further analysis; solving those problems is however not within the scope of this WG. The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG. Current zero configuration discovery protocols are constrained to operate within a single link, which implicitly limits the scope of discovery. In extending service discovery protocols to operate over multiple links, devices will inherently become discoverable over a wider area, which may introduce security or privacy concerns. The WG will consider such concerns when exploring the solution space for multi-link service discovery. To that end, the primary goals of the dnssd WG are as follows: 1. To document a set of requirements for scalable, autonomous DNS-based service discovery in routed, multi-link networks in the following five scenarios: (A) Personal Area networks, e.g., one laptop and one printer. This is the simplest example of a service discovery network, and may or may not have external connectivity. (B) Home networks, as envisaged by the homenet WG, consisting of one or more exit routers, with one or more upstream providers or networks, and an arbitrary internal topology with heterogeneous media where routing is automatically configured. The home network would typically be a single zero configuration administrative domain with a relatively limited number of devices. (C) Wireless 'hotspot' networks, which may include wireless networks made available in public places, or temporary or permanent infrastructures targeted towards meeting or conference style events, e.g., as provided for IETF meetings. In such environments other devices may be more likely to be 'hostile' to the user. (D) Enterprise networks, consisting of larger routed networks, with large numbers of devices, which may be deployments spanning over multiple sites with multiple upstreams, and one more more administrative domains (depending on internal administrative delegation). The large majority of the forwarding and security devices are configured. These may be commercial or academic networks, with differing levels of administrative control over certain devices on the network, and BYOD devices commonplace in the campus scenario. (E) Mesh networks such as RPL/6LoWPAN, with one or more links per routable prefix, which may or may not have external connectivity. The topology may use technologies including 802.11 wireless, HomePlug AV and GP, and ZigBee IP. In the above scenarios, the aim is to facilitate service discovery across the defined site. It is also desirable that a user or device, when away from such a site, is still able to discover services within that site, e.g. a user discovering services in their home network while remote from it. It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a specified scope or advertisement within a specified scope, and being able to discover (enumerate) the set of scopes such that an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus might have no correlation to network topology. 2. To develop an improved, scalable solution for service discovery that can operate in multi-link networks, where devices may be in neighboring or non-neighboring links, applicable to the scenarios above. The solution will consider tradeoffs between reusing/extending existing protocols and developing entirely new protocols. The solution should include documentation or definition of the interfaces that can be implemented, separately to transport of the information. 3. To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. It is important that the dnssd WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the dnssd WG, but coordination between the WGs is desirable. Goals and Milestones: Dec 2017 - Submit DNS-SD Advertising Proxy draft to the IESG as Standards Track RFC Done - Formation of the WG Done - Adopt requirements draft as WG document Done - Submit requirements draft to the IESG as an Informational RFC Done - Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services Done - Adopt wide-area service discovery solution draft as WG document Done - Confirm long-lived queries draft as WG document Done - Submit the zeroconf and unicast DNS "problems and challenges" draft to the IESG as Informational Done - Adopt privacy extensions for DNS-SD draft as a WG document Done - Adopt device pairing mechanism draft as a WG document Done - Submit DNS Push draft to the IESG as Standards Track RFC Done - Submit wide-area service discovery solution draft to the IESG as Standards Track RFC Done - Adopt hybrid-proxy implementation draft as WG document Done - Adopt DNS-SD Advertising Proxy draft as a WG document Internet-Drafts: - Service Discovery Road Map [draft-cheshire-dnssd-roadmap-03] (20 pages) - DNS-SD Privacy and Security Requirements [draft-huitema-dnssd-prireq-00] (15 pages) - Privacy Extensions for DNS-SD [draft-huitema-dnssd-privacy-02] (20 pages) - DNS-SD Privacy Scaling Tradeoffs [draft-huitema-dnssd-privacyscaling-01] (13 pages) - Advertising Proxy for DNS-SD Service Registration Protocol [draft-ietf-dnssd-advertising-proxy-02] (13 pages) - Discovery Proxy for Multicast DNS-Based Service Discovery [draft-ietf-dnssd-hybrid-10] (33 pages) - Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery [draft-ietf-dnssd-mdns-dns-interop-04] (11 pages) - Multicast DNS Discovery Relay [draft-ietf-dnssd-mdns-relay-04] (30 pages) - Device Pairing Using Short Authentication Strings [draft-ietf-dnssd-pairing-05] (11 pages) - Device Pairing Design Issues [draft-ietf-dnssd-pairing-info-02] (17 pages) - DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements [draft-ietf-dnssd-prireq-08] (17 pages) - Privacy Extensions for DNS-SD [draft-ietf-dnssd-privacy-05] (21 pages) - DNS-SD Privacy Scaling Tradeoffs [draft-ietf-dnssd-privacyscaling-00] (13 pages) - DNS Push Notifications [draft-ietf-dnssd-push-25] (32 pages) - Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions [draft-ietf-dnssd-requirements-06] (14 pages) - Service Registration Protocol for DNS-Based Service Discovery [draft-ietf-dnssd-srp-19] (34 pages) - Automatic Replication of DNS-SD Service Registration Protocol Zones [draft-ietf-dnssd-srp-replication-00] (24 pages) - An EDNS(0) option to negotiate Leases on DNS Updates [draft-ietf-dnssd-update-lease-07] (12 pages) - Device Pairing Using Short Authentication Strings [draft-kaiser-dnssd-pairing-00] (20 pages) - Automatic Replication of DNS-SD Service Registration Protocol Zones [draft-lemon-srp-replication-03] (24 pages) - Advertising Proxy for DNS-SD Service Registration Protocol [draft-sctl-advertising-proxy-02] (10 pages) - Multicast DNS Discovery Relay [draft-sctl-dnssd-mdns-relay-04] (20 pages) - An EDNS0 option to negotiate Leases on DNS Updates [draft-sekar-dns-ul-03] (7 pages) Requests for Comments: RFC7558: Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions (14 pages) RFC8222: Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery (11 pages) RFC8765: DNS Push Notifications (32 pages) RFC8766: Discovery Proxy for Multicast DNS-Based Service Discovery (33 pages) RFC8882: DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements (17 pages) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2023-02-17 Current Status: Active Chairs: Juan-Carlos Zúñiga Wassim Haddad Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: int-area@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/int-area Archive: https://mailarchive.ietf.org/arch/browse/int-area/ Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: May 2010 - Submission of IPID document to the IESG as PS Aug 2010 - Submission of tunneling issues document to the IESG as Info Aug 2010 - Submission of tunneling security issues document to the IESG as Info Internet-Drafts: - Multi-hop Ad Hoc Wireless Communication [draft-baccelli-intarea-adhoc-wireless-com-01] (11 pages) - Extended Ping (Xping) [draft-bonica-intarea-eping-04] (17 pages) - Discovering Provisioning Domain Names and Data [draft-bruneau-intarea-provisioning-domains-02] (20 pages) - Current Hostname Practice Considered Harmful [draft-huitema-privsec-harmfulname-01] (9 pages) - Multi-hop Ad Hoc Wireless Communication [draft-ietf-intarea-adhoc-wireless-com-02] (12 pages) - Privacy Considerations for Protocols Relying on IP Broadcast or Multicast [draft-ietf-intarea-broadcast-consider-09] (13 pages) - Using the IPv6 Flow Label for Load Balancing in Server Farms [draft-ietf-intarea-flow-label-balancing-03] (13 pages) - IP Fragmentation Considered Fragile [draft-ietf-intarea-frag-fragile-17] (23 pages) - IPv6 Support for Generic Routing Encapsulation (GRE) [draft-ietf-intarea-gre-ipv6-14] (11 pages) - A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem [draft-ietf-intarea-gre-mtu-05] (12 pages) - Generic UDP Encapsulation [draft-ietf-intarea-gue-09] (43 pages) - Extensions for Generic UDP Encapsulation [draft-ietf-intarea-gue-extensions-06] (39 pages) - Current Hostname Practice Considered Harmful [draft-ietf-intarea-hostname-practice-05] (12 pages) - IP over Intentionally Partially Partitioned Links [draft-ietf-intarea-ippl-00] (16 pages) - Updated Specification of the IPv4 ID Field [draft-ietf-intarea-ipv4-id-update-07] (19 pages) - IPv6 Support Required for All IP-Capable Nodes [draft-ietf-intarea-ipv6-required-02] (6 pages) - Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments [draft-ietf-intarea-nat-reveal-analysis-10] (24 pages) - PROBE: A Utility for Probing Interfaces [draft-ietf-intarea-probe-10] (19 pages) - Discovering Provisioning Domain Names and Data [draft-ietf-intarea-provisioning-domains-11] (27 pages) - IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters [draft-ietf-intarea-rfc7042bis-05] (35 pages) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-10] (19 pages) - Internet Protocol Number for SCHC [draft-ietf-intarea-schc-ip-protocol-number-00] (7 pages) - Protocol Numbers for SCHC [draft-ietf-intarea-schc-protocol-numbers-00] (9 pages) - Logging Recommendations for Internet-Facing Servers [draft-ietf-intarea-server-logging-recommendations-04] (5 pages) - Issues with IP Address Sharing [draft-ietf-intarea-shared-addressing-issues-05] (29 pages) - IP Tunnels in the Internet Architecture [draft-ietf-intarea-tunnels-13] (52 pages) - IP over Intentionally Partially Partitioned Links [draft-nordmark-intarea-ippl-05] (12 pages) Requests for Comments: BCP162: Logging Recommendations for Internet-Facing Servers (5 pages) BCP168: IP Router Alert Considerations and Usage (19 pages) BCP177: IPv6 Support Required for All IP-Capable Nodes (6 pages) BCP230: IP Fragmentation Considered Fragile (23 pages) RFC6269: Issues with IP Address Sharing (29 pages) RFC6302: Logging Recommendations for Internet-Facing Servers (5 pages) RFC6398: IP Router Alert Considerations and Usage (19 pages) RFC6540: IPv6 Support Required for All IP-Capable Nodes (6 pages) RFC6864: Updated Specification of the IPv4 ID Field (19 pages) RFC6967: Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments (24 pages) RFC7098: Using the IPv6 Flow Label for Load Balancing in Server Farms (13 pages) RFC7588: A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem (12 pages) RFC7676: IPv6 Support for Generic Routing Encapsulation (GRE) (11 pages) RFC8117: Current Hostname Practice Considered Harmful (12 pages) RFC8335: PROBE: A Utility for Probing Interfaces (19 pages) RFC8386: Privacy Considerations for Protocols Relying on IP Broadcast or Multicast (13 pages) RFC8801: Discovering Provisioning Domain Names and Data (27 pages) RFC8900: IP Fragmentation Considered Fragile (23 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2022-07-23 Current Status: Active Chairs: Bob Hinden Jen Linkova Ole Trøan Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: https://mailarchive.ietf.org/arch/browse/ipv6/ Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. 6man is the design authority for extensions and modifications to the IPv6 protocol. The working group may, at its discretion, review any document produced in another working group that extends or modifies the IPv6 protocol and, in consultation with the responsible ADs of both working groups, may recommend to the IESG that 6man working group consensus is needed before any of those documents can progress for publication. Goals and Milestones: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Done - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Done - Determine way forward for ULA-C specification Done - Resolve open issues with "U/G" bits in Interface Identifiers Done - Develop approach for IPv6 Fragmentation Done - Develop approaches for IPv6 Extension Headers (Hop-by-Hop and Destination) Done - Plan for advancing core IPv6 core specifications to Internet Standard Internet-Drafts: - Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) [draft-ali-6man-spring-srv6-oam-03] (23 pages) - IPv6 Hop-by-Hop Header Handling [draft-baker-6man-hbh-header-handling-03] (9 pages) - Host routing in a multi-prefix network [draft-baker-6man-multi-homed-host-03] (9 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-carpenter-6man-rfc6874bis-03] (11 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-carpenter-6man-why64-01] (20 pages) - IPv6 Node Requirements [draft-clw-rfc6434-bis-01] (34 pages) - Republishing the IPV6-MIB modules as obsolete [draft-fenner-ipv6-mibs-obsolete-02] (63 pages) - ICMPv6 errors for discarding packets due to processing limits [draft-herbert-6man-icmp-limits-03] (11 pages) - IPv6 Minimum Path MTU Hop-by-Hop Option [draft-hinden-6man-mtu-option-02] (14 pages) - Path MTU Discovery for IP version 6 [draft-hinden-6man-rfc1981bis-01] (16 pages) - Internet Protocol, Version 6 (IPv6) Specification [draft-hinden-6man-rfc2460bis-07] (36 pages) - IP Version 6 Addressing Architecture [draft-hinden-6man-rfc4291bis-06] (29 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-hinden-ipv4flag-04] (9 pages) - RFC 3627 to Historic Status [draft-ietf-6man-3627-historic-01] (3 pages) - Transmission of IPv6 over MS/TP Networks [draft-ietf-6man-6lobac-01] (20 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-05] (18 pages) - Distributing Address Selection Policy Using DHCPv6 [draft-ietf-6man-addr-select-opt-13] (12 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-03] (17 pages) - Duplicate Address Detection Proxy [draft-ietf-6man-dad-proxy-07] (16 pages) - Recommendation on Stable IPv6 Interface Identifiers [draft-ietf-6man-default-iids-16] (9 pages) - Generation of IPv6 Atomic Fragments Considered Harmful [draft-ietf-6man-deprecate-atomfrag-generation-08] (12 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-08] (19 pages) - Limits on Sending and Processing IPv6 Extension Headers [draft-ietf-6man-eh-limits-04] (21 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-15] (11 pages) - Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header [draft-ietf-6man-enhanced-vpn-vtn-id-04] (12 pages) - A Uniform Format for IPv6 Extension Headers [draft-ietf-6man-exthdr-06] (6 pages) - Transmission and Processing of IPv6 Extension Headers [draft-ietf-6man-ext-transmit-05] (10 pages) - IPv6 Flow Label Specification [draft-ietf-6man-flow-3697bis-07] (15 pages) - Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels [draft-ietf-6man-flow-ecmp-05] (9 pages) - Rationale for Update to the IPv6 Flow Label Specification [draft-ietf-6man-flow-update-07] (13 pages) - Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers [draft-ietf-6man-grand-07] (20 pages) - IPv6 Hop-by-Hop Options Extension Header [draft-ietf-6man-hbh-header-handling-03] (10 pages) - IPv6 Hop-by-Hop Options Processing Procedures [draft-ietf-6man-hbh-processing-08] (17 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-00] (3 pages) - ICMPv6 Errors for Discarding Packets Due to Processing Limits [draft-ietf-6man-icmp-limits-08] (15 pages) - IPv6 Query for Enabled In-situ OAM Capabilities [draft-ietf-6man-icmpv6-ioam-conf-state-00] (15 pages) - Neighbor Unreachability Detection Is Too Impatient [draft-ietf-6man-impatient-nud-07] (8 pages) - Security and Privacy Considerations for IPv6 Address Generation Mechanisms [draft-ietf-6man-ipv6-address-generation-privacy-08] (18 pages) - IPv6 Application of the Alternate-Marking Method [draft-ietf-6man-ipv6-alt-mark-17] (20 pages) - Processing of IPv6 "Atomic" Fragments [draft-ietf-6man-ipv6-atomic-fragments-04] (9 pages) - The IPv6-Specific MIB Modules Are Obsolete [draft-ietf-6man-ipv6-mibs-obsolete-02] (65 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-ietf-6man-ipv6only-flag-05] (15 pages) - Architecture and Framework for IPv6 over Non-Broadcast Access [draft-ietf-6man-ipv6-over-wireless-01] (52 pages) - IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-12] (11 pages) - The Line-Identification Option [draft-ietf-6man-lineid-08] (17 pages) - Support for Adjustable Maximum Router Lifetimes per Link [draft-ietf-6man-maxra-04] (7 pages) - IPv6 Minimum Path MTU Hop-by-Hop Option [draft-ietf-6man-mtu-option-15] (20 pages) - Updates to the IPv6 Multicast Addressing Architecture [draft-ietf-6man-multicast-addr-arch-update-08] (10 pages) - IPv6 Multicast Address Scopes [draft-ietf-6man-multicast-scopes-07] (6 pages) - First-Hop Router Selection by Hosts in a Multi-Prefix Network [draft-ietf-6man-multi-homed-host-10] (13 pages) - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery [draft-ietf-6man-nd-extension-headers-05] (10 pages) - Validation of IPv6 Neighbor Discovery Options [draft-ietf-6man-nd-opt-validation-00] (15 pages) - IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags [draft-ietf-6man-ndpioiana-04] (4 pages) - Interface Identifier Assignment in IPv6 SLAAC [draft-ietf-6man-neighbor-inform-00] (17 pages) - IPv6 Node Requirements [draft-ietf-6man-node-req-bis-11] (30 pages) - Handling of Overlapping IPv6 Fragments [draft-ietf-6man-overlap-fragment-03] (6 pages) - Implications of Oversized IPv6 Header Chains [draft-ietf-6man-oversized-header-chain-09] (8 pages) - Security Implications of Predictable Fragment Identification Values [draft-ietf-6man-predictable-fragment-id-10] (20 pages) - Using 127-Bit IPv6 Prefixes on Inter-Router Links [draft-ietf-6man-prefixlen-p2p-01] (8 pages) - Discovering PREF64 in Router Advertisements [draft-ietf-6man-ra-pref64-09] (10 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-rdnss-rfc6106bis-16] (19 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-03] (6 pages) - Packet-Loss Resiliency for Router Solicitations [draft-ietf-6man-resilient-rs-06] (6 pages) - Path MTU Discovery for IP version 6 [draft-ietf-6man-rfc1981bis-08] (19 pages) - Internet Protocol, Version 6 (IPv6) Specification [draft-ietf-6man-rfc2460bis-13] (42 pages) - Default Address Selection for Internet Protocol Version 6 (IPv6) [draft-ietf-6man-rfc3484bis-06] (32 pages) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - IP Version 6 Addressing Architecture [draft-ietf-6man-rfc4291bis-09] (35 pages) - Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [draft-ietf-6man-rfc4941bis-12] (20 pages) - IPv6 Node Requirements [draft-ietf-6man-rfc6434-bis-09] (42 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-rfc6874bis-08] (20 pages) - The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams [draft-ietf-6man-rpl-option-06] (9 pages) - An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-6man-rpl-routing-header-07] (13 pages) - IPv6 Neighbor Discovery Optional RS/RA Refresh [draft-ietf-6man-rs-refresh-02] (13 pages) - IPv6 Segment Routing Header (SRH) [draft-ietf-6man-segment-routing-header-26] (27 pages) - Segment Identifiers in SRv6 [draft-ietf-6man-sids-03] (8 pages) - Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events [draft-ietf-6man-slaac-renum-07] (15 pages) - Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) [draft-ietf-6man-spring-srv6-oam-13] (19 pages) - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [draft-ietf-6man-stable-privacy-addresses-17] (19 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-07] (14 pages) - IPv6 and UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-08] (12 pages) - Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums [draft-ietf-6man-udpzero-12] (40 pages) - Significance of IPv6 Interface Identifiers [draft-ietf-6man-ug-06] (10 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-uri-zoneid-06] (10 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-ietf-6man-why64-08] (24 pages) - Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-02] (7 pages) - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-jeong-6man-rdnss-rfc6106-bis-00] (18 pages) - Support for adjustable maximum router lifetimes per-link [draft-krishnan-6man-maxra-03] (6 pages) - Packet loss resiliency for Router Solicitations [draft-krishnan-6man-resilient-rs-01] (6 pages) - Segment Identifiers in SRv6 [draft-krishnan-6man-sids-00] (7 pages) - Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers [draft-linkova-6man-grand-01] (10 pages) - Discovering PREF64 in Router Advertisements [draft-pref64folks-6man-ra-pref64-02] (8 pages) - IPv6 Segment Routing Header (SRH) [draft-previdi-6man-segment-routing-header-08] (30 pages) - Architecture and Framework for IPv6 over Non-Broadcast Access [draft-thubert-6man-ipv6-over-wireless-15] (50 pages) - IPv6 ND PIO Flags IANA considerations [draft-troan-6man-ndpioiana-01] (4 pages) - IPv6 Query for Enabled In-situ OAM Capabilities [draft-xiao-6man-icmpv6-ioam-conf-state-02] (15 pages) Requests for Comments: BCP220: IPv6 Node Requirements (42 pages) RFC5172: Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol (7 pages) RFC5453: Reserved IPv6 Interface Identifiers (6 pages) RFC5722: Handling of Overlapping IPv6 Fragments (6 pages) * Updates RFC6946 RFC5871: IANA Allocation Guidelines for the IPv6 Routing Header (3 pages) RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (11 pages) RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) RFC6106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC8106 RFC6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links (8 pages) * Updates RFC6547 RFC6434: IPv6 Node Requirements (30 pages) * Obsoletes RFC8504 RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) RFC6437: IPv6 Flow Label Specification (15 pages) RFC6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (9 pages) RFC6547: RFC 3627 to Historic Status (3 pages) RFC6553: The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams (9 pages) * Updates RFC9008 RFC6554: An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) (13 pages) RFC6564: A Uniform Format for IPv6 Extension Headers (6 pages) RFC6724: Default Address Selection for Internet Protocol Version 6 (IPv6) (32 pages) RFC6788: The Line-Identification Option (17 pages) RFC6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (10 pages) RFC6935: IPv6 and UDP Checksums for Tunneled Packets (12 pages) RFC6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums (40 pages) RFC6946: Processing of IPv6 "Atomic" Fragments (9 pages) RFC6957: Duplicate Address Detection Proxy (16 pages) RFC6980: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery (10 pages) RFC7045: Transmission and Processing of IPv6 Extension Headers (10 pages) RFC7048: Neighbor Unreachability Detection Is Too Impatient (8 pages) RFC7078: Distributing Address Selection Policy Using DHCPv6 (12 pages) RFC7112: Implications of Oversized IPv6 Header Chains (8 pages) RFC7136: Significance of IPv6 Interface Identifiers (10 pages) RFC7217: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (19 pages) RFC7346: IPv6 Multicast Address Scopes (6 pages) RFC7371: Updates to the IPv6 Multicast Addressing Architecture (10 pages) RFC7421: Analysis of the 64-bit Boundary in IPv6 Addressing (24 pages) RFC7527: Enhanced Duplicate Address Detection (11 pages) RFC7559: Packet-Loss Resiliency for Router Solicitations (6 pages) RFC7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms (18 pages) RFC7739: Security Implications of Predictable Fragment Identification Values (20 pages) RFC8021: Generation of IPv6 Atomic Fragments Considered Harmful (12 pages) RFC8028: First-Hop Router Selection by Hosts in a Multi-Prefix Network (13 pages) RFC8064: Recommendation on Stable IPv6 Interface Identifiers (9 pages) RFC8096: The IPv6-Specific MIB Modules Are Obsolete (65 pages) RFC8106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) RFC8200: Internet Protocol, Version 6 (IPv6) Specification (42 pages) RFC8201: Path MTU Discovery for IP version 6 (19 pages) RFC8319: Support for Adjustable Maximum Router Lifetimes per Link (7 pages) RFC8425: IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags (4 pages) RFC8504: IPv6 Node Requirements (42 pages) RFC8754: IPv6 Segment Routing Header (SRH) (27 pages) RFC8781: Discovering PREF64 in Router Advertisements (10 pages) RFC8883: ICMPv6 Errors for Discarding Packets Due to Processing Limits (15 pages) RFC8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 (20 pages) RFC9131: Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers (20 pages) RFC9259: Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) (19 pages) RFC9268: IPv6 Minimum Path MTU Hop-by-Hop Option (20 pages) RFC9343: IPv6 Application of the Alternate-Marking Method (20 pages) STD86: Internet Protocol, Version 6 (IPv6) Specification (42 pages) STD87: Path MTU Discovery for IP version 6 (19 pages) IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Alexander Pelov Pascal Thubert Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: lp-wan@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lp-wan Archive: https://mailarchive.ietf.org/arch/browse/lp-wan/ Description of Working Group: A new generation of wireless technologies has emerged under the generic name of Low-Power Wide-Area (LPWA), with a number of common characteristics, which make these technologies unique and disruptive for Internet of Things applications. Those common traits include an optimized radio modulation, a star topology, frame sizes in the order of tens of bytes transmitted a few times per day at ultra-low speeds and sometimes variable MTUs, and, though downstream may be supported, a mostly upstream transmission pattern that allows the devices to spend most of their time in low- energy deep-sleep mode. This enables a range of several kilometers and a long battery lifetime, possibly ten years operating on a single coin-cell. This also enables simple and scalable deployments with low-cost devices and thin infrastructures. Those benefits come at a price: the layer 2 frame formats are optimized and specific to each individual technology. There is no network layer and the application is often hard wired to the layer 2 frame format, leading to siloed deployments that must be managed, secured and operated individually. Migrating from one LPWA technology to another implies rebuilding the whole chain. There is a need to allow an integration of different LPWAN technologies in order to couple them with their related ecosystems. This will guarantee the inter-working by introducing a network layer, and enable common components for management and security, as well as shared application profiles. The IETF can contribute by providing IPv6 connectivity, and propose technologies to secure the operations and manage the devices and their gateways. The Working Group will focus on enabling IPv6 connectivity over the following selection of Low-Power Wide-Area technologies: SIGFOX, LoRa, WI-SUN and NB-IOT. These technologies will be used as the baseline technologies for future work. These technologies present similar characteristics of rare and widely unbalanced over-the-air transmissions, with little capability to alter the frame formats to accommodate this work, which makes it so that existing IETF work (6lo) cannot be trivially applied. The Working Group will leverage cross-participation with the associated set of stakeholders, including users and SDOs working on the baseline technologies, to ensure that the work taking place corresponds to real demands and that the proposed solutions are indeed applicable. The group has produced documents providing an overview of the baseline LPWA technologies (RFC8376) as well as a document specifying a Generic Framework for Static Context Header Compression and Fragmentation (SCHC), which provides both a header compression mechanism and an optional fragmentation mechanism (RFC8724). The group will continue to produce new standards track work to optimize IPv6-based communications to the end devices. The group will: 1. Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols. 2. Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline technologies. 3. Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs. 4. Produce a Standards Track document to enable  operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping). Goals and Milestones: May 2020 - Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols Dec 2020 - Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline technologies Feb 2021 - Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs Oct 2021 - Produce a Standards Track document for SCHC over SigFox Feb 2022 - Produce a Standards Track document for SCHC over NBIOT Dec 2022 - Produce a Standards Track document to enable operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping) Internet-Drafts: - LPWAN Static Context Header Compression (SCHC) Architecture [draft-ietf-lpwan-architecture-02] (14 pages) - Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) [draft-ietf-lpwan-coap-static-context-hc-19] (30 pages) - SCHC: Generic Framework for Static Context Header Compression and Fragmentation [draft-ietf-lpwan-ipv6-static-context-hc-24] (71 pages) - Low-Power Wide Area Network (LPWAN) Overview [draft-ietf-lpwan-overview-10] (43 pages) - SCHC Compound ACK [draft-ietf-lpwan-schc-compound-ack-17] (23 pages) - Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN [draft-ietf-lpwan-schc-over-lorawan-14] (26 pages) - Static Context Header Compression over Narrowband Internet of Things [draft-ietf-lpwan-schc-over-nbiot-15] (22 pages) - SCHC over Sigfox LPWAN [draft-ietf-lpwan-schc-over-sigfox-23] (41 pages) - A YANG Data Model for Static Context Header Compression (SCHC) [draft-ietf-lpwan-schc-yang-data-model-21] (47 pages) Requests for Comments: RFC8376: Low-Power Wide Area Network (LPWAN) Overview (43 pages) RFC8724: SCHC: Generic Framework for Static Context Header Compression and Fragmentation (71 pages) RFC8824: Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) (30 pages) RFC9011: Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN (26 pages) RFC9363: A YANG Data Model for Static Context Header Compression (SCHC) (47 pages) RFC9391: Static Context Header Compression over Narrowband Internet of Things (22 pages) IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ Charter Last Modified: 2022-07-25 Current Status: Active Chairs: Carles Gomez Shwetha Bhandari Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: 6lo@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6lo Archive: https://mailarchive.ietf.org/arch/browse/6lo/ Description of Working Group: 6lo focuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of: * limited power, memory and processing resources * hard upper bounds on state, code space and processing cycles * optimization of energy and network bandwidth usage * lack of some layer 2 services like complete device connectivity and broadcast/multicast Specifically, 6lo will work on: 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks 2. Information and data models (e.g., MIB modules) for these adaptation layers for basic monitoring and troubleshooting. 3. Specifications, such as low-complexity header compression, that are applicable to more than one adaptation layer specification 4. Maintenance and informational documents required for the existing IETF specifications in this space. Only specifications targeting constrained node networks are in scope. 6lo will work closely with the 6man working group, which will continue to work on IP-over-foo documents outside the constrained node network space and will continue to be the focal point for IPv6 maintenance. For adaptation layer specifications that do not have implications on IPv6 architecture, 6man will be notified about 6lo's working group last call. Specifications that might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing new ND options or by exposing to IPv6 a link model different from either Ethernet or 6lowpan) will be closely coordinated with 6man, and/or specific parts will be fanned out to 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and INTAREA. 6lo works on small, focused pieces of work, but does not take on larger cross-layer efforts. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Security and management work that is not specific to the link layers being worked on is out of scope. Work related to routing is out of scope. 6lo will coordinate closely with the working groups in other areas that focus on constrained node networks, such as ROLL (RTG) and CoRE (APP). Goals and Milestones: Mar 2015 - WG last call for draft-ietf-6lo-6lobac Mar 2015 - WG LC for draft-ietf-6lo-dect-ule Apr 2015 - WG adoption call for 6lo security related draft Done - WG decision on adoption for draft-schoenw-6lo-lowpan-mib Done - WG decision on adoption for draft-bormann-6lo-ghc Done - WG decision on adoption for draft-brandt-6man-lowpanz Done - WG decision on adoption for draft-ietf-6man-6lobac Done - WG decision on adoption of draft-mariager-6lowpan-v6over-dect-ule Done - WG adoption call for draft-hong-6lo-ipv6-over-nfc Done - WG LC for draft-ietf-6lo-btle Internet-Drafts: - Transmission of IPv6 Packets over PLC Networks [draft-hou-6lo-plc-05] (20 pages) - Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks [draft-ietf-6lo-6lobac-08] (27 pages) - Address-Protected Neighbor Discovery for Low-Power and Lossy Networks [draft-ietf-6lo-ap-nd-23] (29 pages) - IPv6 Backbone Router [draft-ietf-6lo-backbone-router-20] (32 pages) - IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) [draft-ietf-6lo-blemesh-10] (14 pages) - IPv6 over BLUETOOTH(R) Low Energy [draft-ietf-6lo-btle-17] (21 pages) - Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lo-deadline-time-05] (19 pages) - Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) [draft-ietf-6lo-dect-ule-09] (22 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines [draft-ietf-6lo-dispatch-iana-registry-07] (9 pages) - Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation [draft-ietf-6lo-ethertype-request-01] (5 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery [draft-ietf-6lo-fragment-recovery-21] (28 pages) - 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lo-ghc-05] (24 pages) - Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lo-lowpan-mib-04] (27 pages) - Transmission of IPv6 Packets over ITU-T G.9959 Networks [draft-ietf-6lo-lowpanz-08] (21 pages) - Mesh Link Establishment [draft-ietf-6lo-mesh-link-establishment-00] (19 pages) - On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network [draft-ietf-6lo-minimal-fragment-15] (12 pages) - An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol Diet Exchange (HIP DEX) [draft-ietf-6lo-mle-hip-dex-01] (11 pages) - IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription [draft-ietf-6lo-multicast-registration-14] (38 pages) - Transmission of IPv6 Packets over Near Field Communication [draft-ietf-6lo-nfc-22] (17 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch [draft-ietf-6lo-paging-dispatch-05] (8 pages) - Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks [draft-ietf-6lo-path-aware-semantic-addressing-01] (32 pages) - Transmission of IPv6 Packets over Power Line Communication (PLC) Networks [draft-ietf-6lo-plc-11] (20 pages) - Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [draft-ietf-6lo-privacy-considerations-04] (10 pages) - Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery [draft-ietf-6lo-rfc6775-update-21] (47 pages) - 6LoWPAN Routing Header [draft-ietf-6lo-routing-dispatch-05] (33 pages) - Transmission of SCHC-compressed packets over IEEE 802.15.4 networks [draft-ietf-6lo-schc-15dot4-01] (22 pages) - IPv6 over Constrained Node Networks (6lo) Applicability & Use cases [draft-ietf-6lo-use-cases-16] (30 pages) - Packet Delivery Deadline time in 6LoWPAN Routing Header [draft-lijo-6lo-expiration-time-04] (13 pages) - 6LoWPAN Selective Fragment Recovery [draft-thubert-6lo-fragment-recovery-01] (21 pages) - An Update to 6LoWPAN ND [draft-thubert-6lo-rfc6775-update-01] (22 pages) - LLN Minimal Fragment Forwarding [draft-watteyne-6lo-minimal-fragment-02] (7 pages) Requests for Comments: RFC7388: Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (27 pages) RFC7400: 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (24 pages) RFC7428: Transmission of IPv6 Packets over ITU-T G.9959 Networks (21 pages) RFC7668: IPv6 over BLUETOOTH(R) Low Energy (21 pages) RFC7973: Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation (5 pages) RFC8025: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch (8 pages) RFC8065: Privacy Considerations for IPv6 Adaptation-Layer Mechanisms (10 pages) RFC8066: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines (9 pages) RFC8105: Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) (22 pages) RFC8163: Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks (27 pages) RFC8505: Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (47 pages) * Updates RFC8928 * Updates RFC8929 * Updates RFC9010 RFC8928: Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (29 pages) RFC8929: IPv6 Backbone Router (32 pages) RFC8930: On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network (12 pages) RFC8931: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery (28 pages) RFC9034: Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (19 pages) RFC9159: IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) (14 pages) RFC9354: Transmission of IPv6 Packets over Power Line Communication (PLC) Networks (20 pages) IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- Charter Last Modified: 2023-02-17 Current Status: Active Chairs: Pascal Thubert Thomas Watteyne Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: 6tisch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch Archive: https://mailarchive.ietf.org/arch/browse/6tisch/ Description of Working Group: 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e". Background/Introduction: ------------------------ Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios. The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT). The nodes in a IEEE802.15.4 TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow- band interference and multi-path fading. These techniques enable a new range of use cases for LLNs, including: - Control loops in a wireless process control network, in which high reliability and a fully deterministic behavior are required. - Service Provider networks transporting data from different independent clients, and for which an operator needs flow isolation and traffic shaping. - Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption. IEEE802.15.4 only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network. Description of Working Group: ----------------------------- The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4 standard. The extent of the problem space for the WG is one or more LLNs, possibly federated through a common backbone link via one or more LLN Border Routers (LBRs). The WG will rely on, and if necessary extend, existing mechanisms for authenticating LBRs. Initially, the WG has limited its scope to distributed routing over a static schedule using the Routing Protocol for LLNs (RPL) on the resulting network. This new charter allows for the dynamic allocation of cells and their exchange between adjacent peers to accommodate the available bandwidth to the variations of throughput in IP traffic. The WG will continue working on securing the join process and making that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH. Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is envisioned that 6TiSCH will benefit from the work of DetNet WG to establish the so-called deterministic tracks. The group will define the objects and methods that need to be configured, and provide the associated requirements to DetNet. The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas. Work Items: ----------- The group will: - Produce a specification of the 6top sublayer that describes the protocol for neighbor nodes to negotiate adding/removing cells. This work will leverage cross participation from IEEE members including the IEEE 6TiSCH Interest Group (IG 6T) to define protocol elements and associated frame formats. - Produce a specification for a default 6top Scheduling Function including the policy to enable distributed dynamic scheduling of timeslots for IP traffic. This may include the capability for nodes to appropriate chunks of the matrix without starving, or interfering with other 6TiSCH nodes. This particular work will focus on IP traffic since the work on tracks is not yet advanced enough to specify their requirements. - Produce requirements to the DetNet WG, detailing 6TiSCH chunks and tracks, and the data models to manipulate them from an external controller such as a PCE. - Produce a specification for a secure 6TiSCH network bootstrap, adapted to the constraints of 6TiSCH nodes and leveraging existing art when possible. - Keep updating the "6TiSCH architecture" that describes the design of 6TiSCH networks. This document highlights the different architectural blocks, signaling and data flows, including the operation of the network in the presence of multiple LBRs. The existing document will be augmented to cover dynamic scheduling and application of the DetNet work but will not be delivered within this round of chartering. - Producing YANG Data Models to manage 6tisch is foreseen, but left to a later phase. Non-milestone work items: ------------------------- The Working Group regularly organizes interoperability events with support from ETSI (i.e., ETSI 6TiSCH Plugtests) to get feedback from implementers early on in the standardization process, and produce better standards. Goals and Milestones: Oct 2018 - Initial submission of draft-ietf-6tisch-dtsecurity-zerotouch-join to the IESG Dec 2018 - Evaluate WG progress, propose new charter to the IESG Done - Second submission of draft-ietf-6tisch-minimal to the IESG Done - WG call to adopt draft-ietf-6tisch-6top-sf0 Done - WG call to adopt draft-ietf-6tisch-6top-sublayer Done - ETSI 6TiSCH #3 plugtests Done - Initial submission of draft-ietf-6tisch-6top-protocol to the IESG Done - Initial submission of draft-ietf-6tisch-minimal-security to the IESG Done - Initial submission of 6TiSCH architecture to the IESG Done - 6TiSCH architecture and terminology in RFC publication queue Internet-Drafts: - 6TiSCH Minimal Scheduling Function (MSF) [draft-chang-6tisch-msf-02] (19 pages) - 6TiSCH Operation Sublayer (6top) Interface [draft-ietf-6tisch-6top-interface-04] (34 pages) - 6TiSCH Operation Sublayer (6top) Protocol (6P) [draft-ietf-6tisch-6top-protocol-12] (50 pages) - 6TiSCH 6top Scheduling Function Zero (SF0) [draft-ietf-6tisch-6top-sf0-05] (14 pages) - 6TiSCH Experimental Scheduling Function (SFX) [draft-ietf-6tisch-6top-sfx-01] (12 pages) - An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH) [draft-ietf-6tisch-architecture-30] (57 pages) - 6TiSCH Resource Management and Interaction using CoAP [draft-ietf-6tisch-coap-03] (16 pages) - 6tisch Secure Join protocol [draft-ietf-6tisch-dtsecurity-secure-join-01] (16 pages) - 6tisch Zero-Touch Secure Join protocol [draft-ietf-6tisch-dtsecurity-zerotouch-join-04] (27 pages) - Encapsulation of 6TiSCH Join and Enrollment Information Elements [draft-ietf-6tisch-enrollment-enhanced-beacon-14] (10 pages) - Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [draft-ietf-6tisch-minimal-21] (28 pages) - Constrained Join Protocol (CoJP) for 6TiSCH [draft-ietf-6tisch-minimal-security-15] (41 pages) - 6TiSCH Minimal Scheduling Function (MSF) [draft-ietf-6tisch-msf-18] (20 pages) - Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e [draft-ietf-6tisch-terminology-10] (9 pages) - Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement [draft-ietf-6tisch-tsch-06] (23 pages) - IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information [draft-richardson-6tisch-enrollment-enhanced-beacon-01] (8 pages) - Enabling secure network enrollment in RPL networks [draft-richardson-6tisch-roll-enrollment-priority-03] (6 pages) - 6TiSCH Resource Management and Interaction using CoAP [draft-sudhaakar-6tisch-coap-01] (14 pages) Requests for Comments: BCP210: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration (28 pages) RFC7554: Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement (23 pages) RFC8180: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration (28 pages) RFC8480: 6TiSCH Operation Sublayer (6top) Protocol (6P) (50 pages) RFC9030: An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH) (57 pages) RFC9031: Constrained Join Protocol (CoJP) for 6TiSCH (41 pages) RFC9032: Encapsulation of 6TiSCH Join and Enrollment Information Elements (10 pages) RFC9033: 6TiSCH Minimal Scheduling Function (MSF) (20 pages) Light-Weight Implementation Guidance (lwig) ------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Mohit Sethi Zhen Cao Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: lwip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lwip Archive: https://mailarchive.ietf.org/arch/browse/lwip/ Description of Working Group: Communications technology is being embedded into our environment. Different types of devices in our buildings, vehicles, equipment and other objects have a need to communicate. It is expected that most of these devices will employ the Internet Protocol suite. However, there is a lot of variation in the capabilities between different types of devices, and it is not always easy to embed all the necessary features. The Light-Weight Implementation Guidance (LWIG) Working Group focuses on helping the implementors of the smallest devices. The goal is to be able to build minimal yet interoperable IP-capable devices for the most constrained environments. Building a small implementation does not have to be hard. Many small devices use stripped down versions of general purpose operating systems and their TCP/IP stacks. However, there are implementations that go even further in minimization and can exist in as few as a couple of kilobytes of code, as on some devices this level of optimization is necessary. Technical and cost considerations may limit the computing power, battery capacity, available memory, or communications bandwidth that can be provided. To overcome these limitations the implementors have to employ the right hardware and software mechanisms. For instance, certain types of memory management or even fixed memory allocation may be required. It is also useful to understand what is necessary from the point of view of the communications protocols and the application employing them. For instance, a device that only acts as a client or only requires one connection can simplify its TCP implementation. The purpose of the LWIG working group is to collect experiences from implementors of IP stacks in constrained devices. The group shall focus only on techniques that have been used in actual implementations and do not impact interoperability with other devices. The techniques shall also not affect conformance to the relevant specifications. The output of this work is a document that describes implementation techniques for reducing complexity, memory footprint, or power usage. The topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF protocols. This document will be helpful for the implementors of new devices or for the implementors of new general-purpose small IP stacks. It is also expected that the document increases our knowledge of what existing small implementations do, and helps in the further optimization of the existing implementations. On areas where the considerations for small implementations have already been documented the group shall make an effort to refer to those documents instead of developing its own. Generic hardware design advice and software implementation techniques are outside the scope of this work, as such expertise is not within the IETF domain. Protocol implementation experience, however, is within the IETF domain. The group shall also not develop any new protocols or protocol behavior modifications beyond what is already allowed by existing RFCs, because it is important to ensure that different types of devices can work together. The group shall not develop assumptions or profiles about the operating environment of the devices, because, in general, it is not possible to guarantee any special configuration. Finally, while implementation techniques relating to security mechanisms are within scope, mere removal of security functionality from a protocol is not an acceptable recommendation. Given that the group works on both IP and transport layer protocols it is necessary to ensure that expertise in both aspects is present in the group. Participation from the implementors of existing small IP stacks is also required. Goals and Milestones: Dec 2022 - Submit the CoAP security comparison document to the IESG for publication as an Information RFC Mar 2023 - Submit the Terminology for Constrained-Node Networks document to the IESG for publication as Informational RFC Done - Submit the terminology document to the IESG for publication as an Informational RFC Done - Submit the implementation guidance document to the IESG for publication as an Informational RFC Done - Submit the minimal IKEv2 implementation document to the IESG for publication as an Informational RFC Done - Submit the energy efficient implementation guidance document to the IESG for publication as an Informational RFC Done - Submit the lightweight crypto implementation document to the IESG for publication as an Informational RFC Done - Submit the TCP over constrained networks guidance document to the IESG for publication as an Informational RFC Done - Submit the minimal ESP guidance document to the IESG for publication as an Informational RFC Internet-Drafts: - Virtual reassembly buffers in 6LoWPAN [draft-bormann-lwig-6lowpan-virtual-reassembly-00] (5 pages) - Terminology for Constrained-Node Networks [draft-bormann-lwig-7228bis-08] (27 pages) - TCP over Constrained-Node Networks [draft-gomez-lwig-tcp-constrained-node-networks-03] (17 pages) - Virtual reassembly buffers in 6LoWPAN [draft-ietf-lwig-6lowpan-virtual-reassembly-02] (6 pages) - Terminology for Constrained-Node Networks [draft-ietf-lwig-7228bis-00] (27 pages) - Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks [draft-ietf-lwig-cellular-06] (14 pages) - CoAP Implementation Guidance [draft-ietf-lwig-coap-06] (31 pages) - Practical Considerations and Implementation Experiences in Securing Smart Object Networks [draft-ietf-lwig-crypto-sensors-06] (33 pages) - Alternative Elliptic Curve Representations [draft-ietf-lwig-curve-representations-23] (150 pages) - Energy-Efficient Features of Internet of Things Protocols [draft-ietf-lwig-energy-efficient-08] (24 pages) - Guidance for Light-Weight Implementations of the Internet Protocol Suite [draft-ietf-lwig-guidance-03] (34 pages) - Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation [draft-ietf-lwig-ikev2-minimal-05] (41 pages) - Minimal IP Encapsulating Security Payload (ESP) [draft-ietf-lwig-minimal-esp-12] (13 pages) - Neighbor Management Policy for 6LoWPAN [draft-ietf-lwig-nbr-mgmt-policy-03] (20 pages) - Comparison of CoAP Security Protocols [draft-ietf-lwig-security-protocol-comparison-07] (47 pages) - TCP Usage Guidance in the Internet of Things (IoT) [draft-ietf-lwig-tcp-constrained-node-networks-13] (24 pages) - Terminology for Constrained-Node Networks [draft-ietf-lwig-terminology-07] (17 pages) - A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks [draft-ietf-lwig-tls-minimal-01] (15 pages) - Neighbor Management Policy for 6LoWPAN [draft-jadhav-lwig-nbr-mgmt-policy-01] (18 pages) - Minimal ESP [draft-mglt-lwig-minimal-esp-07] (13 pages) Requests for Comments: RFC7228: Terminology for Constrained-Node Networks (17 pages) RFC7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation (41 pages) RFC8352: Energy-Efficient Features of Internet of Things Protocols (24 pages) RFC8387: Practical Considerations and Implementation Experiences in Securing Smart Object Networks (33 pages) RFC9006: TCP Usage Guidance in the Internet of Things (IoT) (24 pages) RFC9178: Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks (14 pages) RFC9333: Minimal IP Encapsulating Security Payload (ESP) (13 pages) MAC Address Device Identification for Network and Application Services (madinas) -------------------------------------------------------------------------------- Charter Last Modified: 2023-05-25 Current Status: Active Chairs: Carlos J. Bernardos Juan-Carlos Zúñiga Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: madinas@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/madinas Archive: https://mailarchive.ietf.org/arch/browse/madinas/ Description of Working Group: The Medium Access Control (MAC) address is the Link Layer address used in IEEE 802 technologies. It was originally assigned statically for each physical network card by the Network Interface Card manufacturer, out of the space reserved by the IEEE Registration Authority Committee (RAC) for globally unique MAC addresses. The MAC address is used as source or destination target when sending and receiving frames. The default static assignment of the MAC address raises privacy concerns for personal devices. These concerns have recently started to be mitigated by SDOs specifying the use of Randomized and Changing MAC addresses (RCM) and end-device vendors implementing RCM. Device identity is important in scenarios where the network needs to know the device or user identity in order to offer, operate and maintain certain services. Currently, many use cases and applications make an implicit assumption that a device is represented by an IEEE 802 Layer 2 permanent and unique MAC address. This assumption is being used in both control plane and data plane functions and protocols. RCM breaks this assumption. This requires updating applications to function across MAC address changes. The MADINAS Working Group will document the current RCM state of affairs by : (i) identifying relevant network and application services scenarios and examining the effect of RCM schemes on them; (ii) analyzing various existing identifiers (i.e., beyond the MAC address) that can be used by the network to provide seamless services, and (iii) identifying scenarios where device identity is not required. The group will generate a Best Current Practices (BCP) document recommending means to reduce the impact of RCM on the documented use cases while ensuring that the privacy achieved with RCM is not compromised. For scenarios where device identity stability is desirable, the BCP document will recommend existing protocols that can be used to protect the request and exchange of identifiers between the client and the service provider. The Working Group will work together with other IETF WGs (e.g., DHC, IntArea), and will liaise with other relevant organizations, such as IEEE 802 and the Wireless Broadband Alliance (WBA), by coordinating on the different recommendations, as well as potential follow-up activities within or outside the IETF. MADINAS is expected to be a short timeframe (12-18 months) Working Group to quickly assess these needs. Additional solution space documents would only be published if identified as necessary, requiring a rechartering process in coordination with other relevant SDOs. The group will produce the following deliverables: 1. Document Current State of Affairs: An Informational use cases and identity requirements document An Informational MAC Address Randomization current state-of-affairs document 2. Document Best Practices handling RCM A Best Current Practices document Goals and Milestones: Jun 2022 - MAC Address Randomization current state-of-affairs (informational) document submitted to the IESG for publication Sep 2022 - Use Cases and Identity Requirements (informational) document submitted to the IESG for publication Mar 2023 - Best Current Practices handling RCM document submitted to the IESG for publication Internet-Drafts: - Randomized and Changing MAC Address Use Cases [draft-henry-madinas-framework-03] (15 pages) - Randomized and Changing MAC Address [draft-ietf-madinas-mac-address-randomization-06] (16 pages) - Randomized and Changing MAC Address Use Cases and Requirements [draft-ietf-madinas-use-cases-05] (19 pages) - MAC address randomization [draft-zuniga-madinas-mac-address-randomization-01] (15 pages) No Requests for Comments Network Time Protocols (ntp) ---------------------------- Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Dieter Sibold Karen O'Donoghue Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: ntp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ntp Archive: https://mailarchive.ietf.org/arch/browse/ntp/ Description of Working Group: Network Time Protocols working group Accurate, precise, and reliable time is an important function relied upon by modern systems, devices, and applications. This requires reliable and accurate network time synchronization over modern IP-based networks. Additionally, accurate time is fundamental to implementing many important security properties, and therefore often must be (cryptographically, or otherwise) secured. The Network Time Protocols working group is focused on enhancing existing network time synchronization protocols, such as the Network Time Protocol (NTP), and specifying new network-time-related protocols or extensions for purposes that the existing protocols are not well suited to address. NTP was first defined in the IETF in RFC 958 in 1985. It has been through several iterations in the IETF. The latest, NTPv4 (RFC 5905) was published in 2010. Today, it is a widely used time synchronization protocol for the synchronization of clocks of various digital systems including computers, networks, and a myriad of devices. Despite NTP's wide-spread success, it has become apparent that it needs further development in order to adequately meet the modern requirements of time synchronization protocols and to meet the increasing security threats on the Internet. The working group will continue to address the maintenance of NTPv4, including extensions and corrections. This includes the introduction of an interleave mode in order to enhance the accuracy of the network time synchronization and the introduction of alternative clock selection algorithms in order to enhance robustness against delay attacks. NTP remains vulnerable to many types of attacks. Therefore, in 2020, the working group published Network Time Security (NTS) as RFC 8915. NTS extends NTP with an authentication approach to ensure authenticity of NTP time servers and protects the integrity of exchanged NTP packets. The working group will work on extending NTS to cover the remaining modes of service for NTP not covered by the initial specification. The working group will also work on extending NTS for PTP [1] in collaboration with the IEEE 1588 working group. The working group will also develop an updated version of NTP (preliminarily known as NTPv5), addressing a number of identified weaknesses. The new specification will consist of a set of documents, separating the on-wire protocol engine and the timing engine of NTP clients and servers. The updated version of NTP will address the security requirements specified in RFC 7384 and leverage the work completed in RFC 8915. Finally, the working group will address other network-time-related protocols in the IETF (e.g., roughtime) as well as work on items brought to the group from other standards bodies (e.g. IEEE 1588), with the acknowledged request to do so from that body. Working group items: * YANG model for NTPv4 * interleaved mode for NTPv4 * alternative clock selection algorithms * NTS for PTP * NTPv5 requirements * NTPv5 specification(s) * roughtime specification [1] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems," in IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008) , pp.1-499, 16 June 2020, doi: 10.1109/IEEESTD.2020.9120376. Goals and Milestones: May 2022 - NTPv4 YANG data model Jun 2022 - roughtime core specification Dec 2022 - NTS for PTP Dec 2022 - NTPv5 requirements Internet-Drafts: - Message Authentication Codes for the Network Time Protocol [draft-aanchal4-ntp-mac-03] (12 pages) - On Implementing Time [draft-aanchal-time-implementation-guidance-02] (9 pages) - Network Time Security for the Network Time Protocol [draft-dansarie-nts-00] (36 pages) - NTP Client Data Minimization [draft-dfranke-ntp-data-minimization-02] (5 pages) - Network Time Security for the Unicast Mode of the Precision Time Protocol [draft-gerstung-nts4uptp-03] (21 pages) - Port Randomization in the Network Time Protocol Version 4 [draft-gont-ntp-port-randomization-04] (10 pages) - NTPv5 use cases and requirements [draft-gruessing-ntp-ntpv5-requirements-05] (9 pages) - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-haberman-ntpwg-mode-6-cmds-02] (15 pages) - Alternative NTP port [draft-ietf-ntp-alternative-port-02] (7 pages) - Network Time Protocol Version 4: Autokey Specification [draft-ietf-ntp-autokey-08] (58 pages) - Network Time Protocol Best Current Practices [draft-ietf-ntp-bcp-13] (26 pages) - UDP Checksum Complement in the Network Time Protocol (NTP) [draft-ietf-ntp-checksum-trailer-07] (14 pages) - A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos [draft-ietf-ntp-chronos-13] (14 pages) - Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS) [draft-ietf-ntp-cms-for-nts-message-06] (19 pages) - NTP Client Data Minimization [draft-ietf-ntp-data-minimization-04] (6 pages) - Network Time Protocol (NTP) Server Option for DHCPv6 [draft-ietf-ntp-dhcpv6-ntp-opt-06] (9 pages) - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-ietf-ntp-extension-field-07] (8 pages) - On Implementing Time [draft-ietf-ntp-implementation-guidance-00] (9 pages) - NTP Interleaved Modes [draft-ietf-ntp-interleaved-modes-07] (15 pages) - Message Authentication Code for the Network Time Protocol [draft-ietf-ntp-mac-06] (5 pages) - Control Messages Protocol for Use with Network Time Protocol Version 4 [draft-ietf-ntp-mode-6-cmds-11] (21 pages) - Network Time Security [draft-ietf-ntp-network-time-security-15] (39 pages) - The Network Time Protocol Version 4 Algorithm Specification [draft-ietf-ntp-ntpv4-algorithms-01] (25 pages) - Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) [draft-ietf-ntp-ntpv4-mib-07] (26 pages) - Network Time Protocol Version 4: Protocol and Algorithms Specification [draft-ietf-ntp-ntpv4-proto-13] (110 pages) - NTPv5 use cases and requirements [draft-ietf-ntp-ntpv5-requirements-01] (9 pages) - Guidelines for Defining Packet Timestamps [draft-ietf-ntp-packet-timestamps-09] (17 pages) - Network Time Protocol Version 4: Port Randomization [draft-ietf-ntp-port-randomization-08] (9 pages) - Network Time Protocol REFID Updates [draft-ietf-ntp-refid-updates-05] (8 pages) - Requirements for Network Time Protocol Version 4 [draft-ietf-ntp-reqs-01] (16 pages) - Roughtime [draft-ietf-ntp-roughtime-07] (21 pages) - Roughtime Ecosystem [draft-ietf-ntp-roughtime-ecosystem-01] (4 pages) - Updating the NTP Registries [draft-ietf-ntp-update-registries-06] (10 pages) - Network Time Security for the Network Time Protocol [draft-ietf-ntp-using-nts-for-ntp-28] (33 pages) - A YANG Data Model for NTP [draft-ietf-ntp-yang-data-model-17] (56 pages) - The Network Time Protocol Version 4 (NTPv4) MAC Extension Field [draft-mayer-ntp-mac-extension-field-00] (6 pages) - Guidelines for Defining Packet Timestamps [draft-mizrahi-intarea-packet-timestamps-01] (14 pages) - Using UDP Checksum Trailers in the Network Time Protocol (NTP) [draft-mizrahi-ntp-checksum-trailer-02] (10 pages) - Using NTP Extension Fields without Authentication [draft-mizrahi-ntp-extension-field-03] (9 pages) - Alternative NTP port [draft-mlichvar-ntp-alternative-port-02] (6 pages) - NTP Correction Field [draft-mlichvar-ntp-correction-field-04] (7 pages) - NTP Interleaved Modes [draft-mlichvar-ntp-interleaved-modes-01] (9 pages) - Network Time Protocol Version 5 [draft-mlichvar-ntp-ntpv5-07] (28 pages) - NTP Over PTP [draft-mlichvar-ntp-over-ptp-03] (6 pages) - Network Time Protocol Best Current Practices [draft-reilly-ntp-bcp-02] (18 pages) - Roughtime [draft-roughtime-aanchal-04] (17 pages) - The update registries draft [draft-rsalz-update-registries-02] (11 pages) - A Secure Selection and Filtering Mechanism for the Network Time Protocol Version 4 [draft-schiff-ntp-chronos-03] (8 pages) - Network Time Protocol Extended Information Extension Field [draft-stenn-ntp-extended-information-04] (5 pages) - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-stenn-ntp-extension-fields-09] (13 pages) - Network Time Protocol I-Do Extension Field [draft-stenn-ntp-i-do-06] (7 pages) - Network Time Protocol IPv6 REFID Hash [draft-stenn-ntp-ipv6-refid-hash-00] (4 pages) - Network Time Protocol Last Extension Field [draft-stenn-ntp-last-extension-00] (4 pages) - Network Time Protocol Leap Smear REFID [draft-stenn-ntp-leap-smear-refid-02] (5 pages) - Network Time Protocol MAC/Last Extension Fields [draft-stenn-ntp-mac-last-ef-04] (8 pages) - Network Time Protocol Suggested REFID Extension Field [draft-stenn-ntp-suggest-refid-05] (7 pages) Requests for Comments: BCP223: Network Time Protocol Best Current Practices (26 pages) RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (110 pages) * Updates RFC7822 * Updates RFC8573 * Updates RFC9109 RFC5906: Network Time Protocol Version 4: Autokey Specification (58 pages) RFC5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) (26 pages) RFC5908: Network Time Protocol (NTP) Server Option for DHCPv6 (9 pages) RFC7821: UDP Checksum Complement in the Network Time Protocol (NTP) (14 pages) RFC7822: Network Time Protocol Version 4 (NTPv4) Extension Fields (8 pages) RFC8573: Message Authentication Code for the Network Time Protocol (5 pages) RFC8633: Network Time Protocol Best Current Practices (26 pages) RFC8877: Guidelines for Defining Packet Timestamps (17 pages) RFC8915: Network Time Security for the Network Time Protocol (33 pages) RFC9109: Network Time Protocol Version 4: Port Randomization (9 pages) RFC9249: A YANG Data Model for NTP (56 pages) RFC9327: Control Messages Protocol for Use with Network Time Protocol Version 4 (21 pages) Static Context Header Compression (schc) ---------------------------------------- Charter Last Modified: 2023-03-17 Current Status: Active Chairs: Alexander Pelov Pascal Thubert Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: schc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/schc Archive: https://mailarchive.ietf.org/arch/browse/schc/ Description of Working Group: The scope of the Static Context Header Compression (SCHC) Working Group (to be pronounced as "chic" in French) is to extend the benefits of the RFC 8724 SCHC technology in Low-Power Wide-Area (LPWA) and non-LPWA networks, including Low Power devices such as zero-energy / scavenging devices that may operate in Delay Tolerant mode. To that effect, the group will provide specifications for the application of SCHC over underlying layers, where underlying layers include but are not limited to UDP tunnels, IP, PPP, and Ethernet, as well as the use of SCHC by upper-layer protocols. To extend SCHC over multi-hop networks with remote endpoints, there is a need in the data plane to signal the SCHC session and some operational values in the packets. For instance, the INT-AREA WG is working on a SCHC protocol type for IP and a SCHC Ethertype (in coordination with IEEE) for Ethernet. The WG will provide standards track specifications for a SCHC Header that conveys the SCHC Session Info over IP. A complete SCHC solution also requires control plane technologies to secure the operations and manage the SCHC sessions, devices, and gateways. The group will provide specifications to securely identify the rule sets and negotiate the associated parameters between the pair of endpoints. The group will also work on the rules provisioning to the nodes, including the instantiation of generic rules to the nodes and networks in which they are applied. The WG will work on: 1) Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols, and providing additional reliability mechanisms such as FEC for fragments. 2) Produce a Standards Track document to enable Operations, Administration, and Maintenance (OAM), including support for delayed (as some devices can be asleep) or proxied (via the gateway) reachability verification. 3) Produce Standard Track documents for SCHC over underlying layers and carried protocols over SCHC where underlying layers includes but is not limited to IP, UDP tunnels, PPP, and Ethernet and carried protocols may include IPv4, ICMPv6-based protocols, TCP, IP tunnels, DLMS, and other protocols over CoAP such as LwM2M; define and maintain data models for the protocols supported by SCHC. 4) Produce an informational document describing how a carried protocol can use SCHC. 5) Define in a Standard Track document the SCHC Protocol Header to convey SCHC Session Info over IP 6) Produce Standard Track documents for SCHC Rule Discovery and Parameter Negotiation, including the specification of how work from the IETF security area is leveraged to secure these operations 7) Produce Standard Track documents for SCHC Rule Provisioning, including the specification of generic SCHC rules that can be instantiated, e.g., to apply to a certain node or within a certain network. The SCHC WG will coordinate with INTAREA WG for the IP protocol type definition, 6MAN WG for possible ICMPv6 code(s), and with other WGs for possible Protocols-over-SCHC or SCHC-over-protocol activities (e.g., in TSV area). It will work with the relevant security area WGs to appropriately secure the SCHC session. If required, the SCHC WG will liaise and coordinate with other Standard Development Organisations when SCHC will be used over or under protocols not defined with IETF. Goals and Milestones: Feb 2023 - WG adoption of a standard track specification for SCHC over PPP May 2023 - WG adoption of an information document about SCHC architecture Jul 2023 - WG adoption of a standard track specification of Operations, Administration, and Maintenance (OAM) Nov 2023 - WG adoption of a standard track specification SCHC over IP Nov 2023 - WG adoption of a standard track specification for generic SCHC header Dec 2023 - WG adoption of a standard track specification of FEC for fragments Dec 2023 - WG adoption of a standard track specification for rules discovery and parameters negotiation Dec 2023 - WG adoption of a standard track specification for rules provisioning Mar 2024 - Request for publication of an information document about SCHC architecture Mar 2024 - Request for publication of a standard track specification for SCHC over PPP Dec 2024 - Request for publication of a standard track specification of FEC for fragments Dec 2024 - Request for publication of a standard track specification of Operations, Administration, and Maintenance (OAM) Feb 2025 - Request for publication of a standard track specification for generic SCHC header Mar 2025 - Request for publication of a standard track specification of a standard track specification SCHC over IP Mar 2025 - Request for publication of a standard track specification for rules provisioning Mar 2025 - Request for publication of a standard track specification for rules discovery and parameters negotiation Internet-Drafts: - LPWAN Static Context Header Compression (SCHC) Architecture [draft-ietf-schc-architecture-00] (14 pages) No Requests for Comments Stub Network Auto Configuration for IPv6 (snac) ----------------------------------------------- Charter Last Modified: 2022-10-20 Current Status: Active Chairs: Kiran Makhijani Marc Blanchet Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: snac@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/snac Archive: https://mailarchive.ietf.org/arch/browse/snac/ Description of Working Group: Stub Network AutoConfiguration proposed charter A stub network is a network that can be connected to an existing infrastructure network and, to the extent possible, participate as part of that infrastructure. A stub network must be able to connect to an infrastructure network without modifications to that infrastructure network, even if MAC address lengths differ (e.g., IEEE 802.15.4). Hosts connected to the stub network should be able to do anything that hosts directly connected to the infrastructure network can do. Stub networks are leaf networks: they do not support the attachment of additional stub networks. The simplest use case for a stub network (e.g., a IEEE 802.15.4-based entertainment or lighting system) is to connect to an infrastructure network (e.g., a home network) that is a single layer-2 link (hence not running any routing protocol), without requiring any new behaviour from this infrastructure network. Hence, a solution that only provides transparent connectivity between the stub network and the infrastructure link to which it is directly connected is an important first step. Multiple distinct stub networks should be able to connect to the same infrastructure network. A more involved use case is to connect to an infrastructure network that can delegate an IPv6 prefix to the stub network and support unicast service discovery. The infrastructure network may be a single-link unmanaged network (e.g., a home network) or a managed multi-link network infrastructure. The multi-link use case may require the stub network prefix to be included in the routing plane of the infrastructure network. Both use cases are in scope for the working group. For all types of stub networks, the working group documents will allow IPv6-only stub networks to connect automatically to an infrastructure network, without any address translation (e.g., NPTv6 RFC 6296), so that hosts and services on the stub network can communicate as if they were connected directly to the infrastructure network. Hosts on the stub network(s) and the infrastructure network must be mutually discoverable, and mutually reachable. Discoverability refers to service discovery, e.g., DNSSD (RFC6763). In addition, hosts on the stub network should be able to connect to the Internet (via the infrastructure network), if desired, just as well as hosts on the infrastructure network are able to. The working group will coordinate with other relevant working groups, such as DNSSD or 6MAN or DHC, for any changes required in protocols and will make sure that those groups are included in major document reviews at appropriate times. Deliverables: * A framework document that explains how one or more stub routers connect one or more stub networks to a single unmanaged infrastructure link. This includes providing IP addresses required for communication, routes and routing required for communication, and providing service discovery for the stub network and the adjacent infrastructure link. * A document describing the set of services that must be provided by a multi-link infrastructure network in order for stub networks to be added to the infrastructure providing full mutual reachability, addressability, and discoverability between stub network hosts and hosts on adjacent and non-adjacent infrastructure links. This would address, for example, a building management network or an enterprise network. Goals and Milestones: Jan 2023 - Framework I-D adopted by the WG Jun 2023 - Services for multi-link adopted by the WG Nov 2023 - Framework I-D publication requested to the IESG Nov 2024 - Services for multi-link publication requested to the IESG Internet-Drafts: - Automatically Connecting Stub Networks to Unmanaged Infrastructure [draft-ietf-snac-simple-01] (26 pages) - Automatically Connecting Stub Networks to Unmanaged Infrastructure [draft-lemon-stub-networks-07] (21 pages) No Requests for Comments Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Karen O'Donoghue Yaakov (J) Stein Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: tictoc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tictoc Archive: https://mailarchive.ietf.org/arch/browse/tictoc/ Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. The security of time transfer, including the authentication of the time reference is an important consideration and must be designed in from the beginning. The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own. The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution. First phase Objectives: - To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. - To develop a document defining the modular breakdown of functionality within the solution space. - To determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 within each use case, along with an associated gap analysis for what requirements are not met without adaptation or extension of these protocols. - To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. - To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on (2). - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP. - To document threat analyses and security mechanisms for all protocols developed by the WG. - To document media mappings for link layer technologies of interest. Second phase Objectives (requiring re-charter of the WG): To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management. Goals and Milestones: Mar 2016 - 1588v2 profile, if needed, document exits WGLC Apr 2016 - MIB for IEEE 1588v2 profile and NTPv4 extensions (TICTOC MIB) document exits WGLC May 2016 - Prioritize second phase deliverables and add milestones or re-charter document exits WGLC Jun 2016 - IEEE 1588v2 YANG Model exits WGLC Jun 2016 - Publish Experimental RFC on multi-path time synchronization Jul 2016 - Publish Experimental RFC on transporting time over MPLS Done - Security document(s) document exits WGLC Internet-Drafts: - TICTOC Problem Statement [draft-bryant-tictoc-probstat-02] (16 pages) - Problem Statements of Scalable Synchronization Networks [draft-hjxl-ssn-ps-00] (9 pages) - Transporting Timing messages over MPLS Networks [draft-ietf-tictoc-1588overmpls-07] (19 pages) - YANG Data Model for the Precision Time Protocol (PTP) [draft-ietf-tictoc-1588v2-yang-11] (30 pages) - Multipath Time Synchronization [draft-ietf-tictoc-multi-path-synchronization-07] (17 pages) - Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages [draft-ietf-tictoc-ptp-enterprise-profile-22] (13 pages) - Precision Time Protocol Version 2 (PTPv2) Management Information Base [draft-ietf-tictoc-ptp-mib-12] (64 pages) - TICTOC Requirement [draft-ietf-tictoc-requirements-01] (32 pages) - Security Requirements of Time Protocols in Packet Switched Networks [draft-ietf-tictoc-security-requirements-12] (36 pages) - YANG Data Model for IEEE 1588v2 [draft-jlx-tictoc-1588v2-yang-04] (22 pages) - Multi-Path Time Synchronization [draft-shpiner-multi-path-synchronization-03] (16 pages) - Architecture for the Transmission of Timing over Packet Networks [draft-stein-tictoc-modules-03] (22 pages) Requests for Comments: RFC7384: Security Requirements of Time Protocols in Packet Switched Networks (36 pages) RFC8039: Multipath Time Synchronization (17 pages) RFC8173: Precision Time Protocol Version 2 (PTPv2) Management Information Base (64 pages) RFC8575: YANG Data Model for the Precision Time Protocol (PTP) (30 pages) Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Sheng Jiang Toerless Eckert Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Tech Advisor: Nancy Cam-Winget Secretary: Michael Richardson Mailing Lists: General Discussion: anima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/anima Archive: https://mailarchive.ietf.org/arch/browse/anima/ Description of Working Group: The Autonomic Networking Integrated Model and Approach (ANIMA) working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of professionally-managed networks. The vision is a network that configures, heals, optimizes and protects itself. The strategy is the incremental introduction of components to smoothly evolve existing and new networks accordingly. ANIMA work will rely on the framework described in draft-ietf-anima-reference-model already approved for publication. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The two concrete areas of the reference model are (1) the Autonomic Networking Infrastructure (ANI), and (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA). The ANI is specified through prior ANIMA work. It is composed of the Autonomic Control Plane (ACP; RFC 8368), Bootstrap over Secure Key Infrastructures (BRSKI) including Vouchers (RFC8366), and the Generic Autonomic Signaling Protocol (GRASP). ANIMA will work on closing gaps and extending the ANI and its components. ANIMA will start to define Autonomic Functions (AF) to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management, coordination and dependency management. The reference model also discusses Intent, but ANIMA will not work on this without explicit rechartering. It will rely on the Network Management Research Group (NMRG) to define the next steps for this topic. ANIMA will coordinate with other IETF and IRTF groups as needed. The scope of possible work items are (additional works are subject to extra approval from the responsible AD): - Extensions to the ANI, including variations of ANI deployment (e.g. in virtualised environments), information distribution within an AN, ANI OAMP interfaces (Operations, Administration, Management, Provisioning), interaction with YANG-based mechanisms, defining the domain boundary and membership management of the domain. - Support for Autonomic Service Agents, including design and implementation guidelines for ASAs, life cycle management, authorization and coordination of ASA. - BRSKI features, including proxies, enrollment, adaptions over various network protocols, variations of voucher formats. - Generic use cases of Autonomic Network and new GRASP extensions/options for them, including bulk transfer, DNS-SD interworking, autonomic resource management, autonomic SLA assurance, autonomic multi-tenant management, autonomic network measurement. - Integration with Network Operations Centers (NOCs), including autonomic discovery/connectivity to NOC, YANG-based ANI/ASA management by the NOC and reporting AF from node to NOC. Goals and Milestones: Nov 2019 - Submit Information distribution over GRASP to the IESG Dec 2019 - Submit Constrained Voucher Artifacts for Bootstrapping Protocols to the IESG Dec 2019 - Submit Constrained Join Proxy for Bootstrapping Protocols to the IESG Mar 2020 - Submit Lifecycle and Management of Autonomic Service Agents to the IESG Mar 2020 - Submit Guidelines for Developing Autonomic Service Agents to the IESG Jul 2020 - Recharter or close the WG Internet-Drafts: - Guidelines for Autonomic Service Agents [draft-ietf-anima-asa-guidelines-07] (23 pages) - An Autonomic Control Plane (ACP) [draft-ietf-anima-autonomic-control-plane-30] (128 pages) - Bootstrapping Remote Secure Key Infrastructure (BRSKI) [draft-ietf-anima-bootstrapping-keyinfra-45] (116 pages) - BRSKI-AE: Alternative Enrollment Protocols in BRSKI [draft-ietf-anima-brski-ae-04] (37 pages) - BRSKI-AE: Alternative Enrollment Protocols in BRSKI [draft-ietf-anima-brski-async-enroll-05] (30 pages) - BRSKI Cloud Registrar [draft-ietf-anima-brski-cloud-06] (20 pages) - BRSKI with Pledge in Responder Mode (BRSKI-PRM) [draft-ietf-anima-brski-prm-08] (83 pages) - Constrained Join Proxy for Bootstrapping Protocols [draft-ietf-anima-constrained-join-proxy-14] (26 pages) - Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) [draft-ietf-anima-constrained-voucher-20] (83 pages) - GeneRic Autonomic Signaling Protocol (GRASP) [draft-ietf-anima-grasp-15] (55 pages) - GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-ietf-anima-grasp-api-10] (29 pages) - Information Distribution over GRASP [draft-ietf-anima-grasp-distribution-07] (25 pages) - JWS signed Voucher Artifacts for Bootstrapping Protocols [draft-ietf-anima-jws-voucher-06] (15 pages) - A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services [draft-ietf-anima-network-service-auto-deployment-04] (15 pages) - Autonomic IPv6 Edge Prefix Management in Large-Scale Networks [draft-ietf-anima-prefix-management-07] (19 pages) - A Reference Model for Autonomic Networking [draft-ietf-anima-reference-model-10] (26 pages) - A Voucher Artifact for Bootstrapping Protocols [draft-ietf-anima-rfc8366bis-07] (36 pages) - Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) [draft-ietf-anima-stable-connectivity-10] (24 pages) - A Voucher Artifact for Bootstrapping Protocols [draft-ietf-anima-voucher-07] (23 pages) - Delegated Authority for Bootstrap Voucher Artifacts [draft-ietf-anima-voucher-delegation-02] (16 pages) - Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-liu-anima-grasp-api-06] (25 pages) - Constrained Voucher Profile for Bootstrapping Protocols [draft-richardson-anima-ace-constrained-voucher-03] (20 pages) Requests for Comments: RFC8366: A Voucher Artifact for Bootstrapping Protocols (23 pages) RFC8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (24 pages) RFC8990: GeneRic Autonomic Signaling Protocol (GRASP) (55 pages) RFC8991: GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) (29 pages) RFC8992: Autonomic IPv6 Edge Prefix Management in Large-Scale Networks (19 pages) RFC8993: A Reference Model for Autonomic Networking (26 pages) RFC8994: An Autonomic Control Plane (ACP) (128 pages) RFC8995: Bootstrapping Remote Secure Key Infrastructure (BRSKI) (116 pages) RFC9222: Guidelines for Autonomic Service Agents (23 pages) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Al Morton Sarah Banks Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bmwg Archive: https://mailarchive.ietf.org/arch/browse/bmwg/ Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. The scope of BMWG has been extended to develop methods for virtual network functions (VNF) and their unique supporting infrastructure (such as SDN Controllers and vSwitches). Benchmarks for platform capacity and performance characteristics of virtual routers, firewalls (and other security functions), signaling control gateways, and other forms of gateways are included. The benchmarks will foster comparisons between physical and virtual network functions, and also cover unique features of Network Function Virtualization systems. Also, with the emergence of virtualized test systems, specifications for test system calibration are also in-scope. Each recommendation will describe the class of network function, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the community of users (e.g., network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminologies will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the description of the task. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for development and advancement of measurements which provide insight on the capabilities and operation of implementations of inter-networking technology. Ideally, BMWG should communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT, and consult with/inform other IETF WGs (as is the current practice). Goals and Milestones: Aug 2020 - Methodology for Next-Gen Firewall Benchmarking to IESG Review Aug 2023 - Draft on Selecting and Applying Model(s) for Benchmarking to IESG Review Dec 2023 - Draft on General VNF Benchmarking Automation to IESG Review Dec 2023 - Considerations for Benchmarking Network Virtualization Platforms to IESG Review Done - Update to RFC2544 Back-to-back Frame Benchmarking to IESG Review Done, But did not progress at IESG - Methodology for EVPN Benchmarking to IESG Review Internet-Drafts: - Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-08] (11 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (127 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-00] (32 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (16 pages) - Updates for the Back-to-Back Frame Benchmark in RFC 2544 [draft-ietf-bmwg-b2b-frame-04] (13 pages) - Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers [draft-ietf-bmwg-benchmarking-stateful-02] (28 pages) - Benchmarking Methodology for Routers Supporting Resource Reservation [draft-ietf-bmwg-benchres-method-00] (15 pages) - Benchmarking Terminology for Resource Reservation Capable Routers [draft-ietf-bmwg-benchres-term-08] (24 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence [draft-ietf-bmwg-bgp-basic-convergence-05] (35 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-04] (19 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-06] (36 pages) - Data Center Benchmarking Methodology [draft-ietf-bmwg-dcbench-methodology-18] (19 pages) - Data Center Benchmarking Terminology [draft-ietf-bmwg-dcbench-terminology-19] (20 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-13] (34 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Benchmarking Methodology for EVPN and PBB-EVPN [draft-ietf-bmwg-evpntest-09] (28 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (15 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (34 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-08] (26 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-17] (6 pages) - Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-23] (42 pages) - Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-23] (29 pages) - IMIX Genome: Specification of Variable Packet Sizes for Additional Testing [draft-ietf-bmwg-imix-genome-05] (10 pages) - IP Flow Information Accounting and Export Benchmarking Methodology [draft-ietf-bmwg-ipflow-meth-10] (39 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-05] (20 pages) - Benchmarking the Neighbor Discovery Protocol [draft-ietf-bmwg-ipv6-nd-06] (17 pages) - Benchmarking Methodology for IPv6 Transition Technologies [draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08] (30 pages) - Benchmarking Methodology for In-Service Software Upgrade (ISSU) [draft-ietf-bmwg-issu-meth-02] (16 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-06] (25 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-08] (16 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-14] (31 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-02] (30 pages) - Multiple Loss Ratio Search [draft-ietf-bmwg-mlrsearch-03] (14 pages) - MPLS Forwarding Benchmarking Methodology for IP Flows [draft-ietf-bmwg-mpls-forwarding-meth-06] (27 pages) - Benchmarking Methodology for LAN Switching Devices [draft-ietf-bmwg-mswitch-04] (35 pages) - A YANG Data Model for Network Tester Management [draft-ietf-bmwg-network-tester-cfg-02] (28 pages) - Benchmarking Methodology for Network Security Device Performance [draft-ietf-bmwg-ngfw-performance-15] (51 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-07] (11 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-10] (16 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-10] (9 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection [draft-ietf-bmwg-protection-meth-14] (35 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-09] (33 pages) - Device Reset Characterization [draft-ietf-bmwg-reset-06] (17 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-meth-09] (64 pages) - Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-term-10] (23 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-08] (26 pages) - Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration [draft-ietf-bmwg-sip-bench-meth-12] (21 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration [draft-ietf-bmwg-sip-bench-term-12] (20 pages) - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-01] (12 pages) - Traffic Management Benchmarking [draft-ietf-bmwg-traffic-management-06] (51 pages) - Considerations for Benchmarking Virtual Network Functions and Their Infrastructure [draft-ietf-bmwg-virtual-net-05] (15 pages) - Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) [draft-ietf-bmwg-vswitch-opnfv-04] (24 pages) - Benchmarking Methodology for EVPN and PBB-EVPN [draft-kishjac-bmwg-evpntest-10] (22 pages) - Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers [draft-lencse-bmwg-benchmarking-stateful-04] (22 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (12 pages) * Updates RFC6201 RFC1944: Benchmarking Methodology for Network Interconnect Devices (30 pages) * Obsoletes RFC2544 RFC2285: Benchmarking Terminology for LAN Switching Devices (25 pages) RFC2432: Terminology for IP Multicast Benchmarking (16 pages) RFC2647: Benchmarking Terminology for Firewall Performance (26 pages) RFC2761: Terminology for ATM Benchmarking (32 pages) RFC2889: Benchmarking Methodology for LAN Switching Devices (35 pages) RFC3116: Methodology for ATM Benchmarking (127 pages) RFC3133: Terminology for Frame Relay Benchmarking (24 pages) RFC3134: Terminology for ATM ABR Benchmarking (16 pages) RFC3222: Terminology for Forwarding Information Base (FIB) based Router Performance (15 pages) RFC3511: Benchmarking Methodology for Firewall Performance (34 pages) * Obsoletes RFC9411 RFC3918: Methodology for IP Multicast Benchmarking (31 pages) RFC4061: Benchmarking Basic OSPF Single Router Control Plane Convergence (16 pages) RFC4062: OSPF Benchmarking Terminology and Concepts (9 pages) RFC4063: Considerations When Using Basic OSPF Convergence Benchmarks (11 pages) RFC4098: Terminology for Benchmarking BGP Device Convergence in the Control Plane (36 pages) RFC4689: Terminology for Benchmarking Network-layer Traffic Control Mechanisms (34 pages) RFC4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking (26 pages) RFC4883: Benchmarking Terminology for Resource Reservation Capable Routers (24 pages) RFC5180: IPv6 Benchmarking Methodology for Network Interconnect Devices (20 pages) RFC5695: MPLS Forwarding Benchmarking Methodology for IP Flows (27 pages) RFC6201: Device Reset Characterization (17 pages) RFC6412: Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence (29 pages) RFC6413: Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence (42 pages) RFC6414: Benchmarking Terminology for Protection Performance (33 pages) RFC6645: IP Flow Information Accounting and Export Benchmarking Methodology (39 pages) RFC6815: Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful (11 pages) RFC6894: Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection (35 pages) RFC6985: IMIX Genome: Specification of Variable Packet Sizes for Additional Testing (10 pages) RFC7501: Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration (20 pages) RFC7502: Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration (21 pages) RFC7640: Traffic Management Benchmarking (51 pages) RFC7654: Benchmarking Methodology for In-Service Software Upgrade (ISSU) (16 pages) RFC7747: Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence (35 pages) RFC8161: Benchmarking the Neighbor Discovery Protocol (17 pages) RFC8172: Considerations for Benchmarking Virtual Network Functions and Their Infrastructure (15 pages) RFC8204: Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) (24 pages) RFC8219: Benchmarking Methodology for IPv6 Transition Technologies (30 pages) RFC8238: Data Center Benchmarking Terminology (20 pages) RFC8239: Data Center Benchmarking Methodology (19 pages) RFC8455: Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance (23 pages) RFC8456: Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance (64 pages) RFC9004: Updates for the Back-to-Back Frame Benchmark in RFC 2544 (13 pages) RFC9411: Benchmarking Methodology for Network Security Device Performance (51 pages) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Jouni Korhonen Lionel Morand Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: https://mailarchive.ietf.org/arch/browse/dime/ Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. - Diameter overload control. The aim of this work is to identify the limitations of the Diameter protocol level overload control provided by the current Diameter Base protocol. A set of requirements will be provided to define a new Diameter level overload control mechanism. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard Jan 2016 - Submit I-D 'Diameter Overload Control Rate Abatement Algorithm' to the IESG for consideration as a Proposed Standard Oct 2016 - Submit RFC4006bis as a working group document. Aug 2017 - Submit RFC4006bis to the IESG. Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Done - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item Done - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Done - Submit I-D 'Diameter Overload Control Requirements' as a working group document. To be Informational RFC Done - Submit I-D 'Diameter Overload Control' as a working group document. To be Standards Track RFC Done - Submit I-D 'Diameter Overload Control Requirements' to the IESG for consideration as a Informational Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Done - Submit I-D 'Diameter Overload Control' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Congestion and Filter Attributes' to the IESG for considerations as a Proposed Standard Done - Submit a document on 'Diameter Overload Control Rate Abatement Algorithm' as a working group item Done - Submit a document on 'Diameter Agent Overload' as a working group item Done - Submit a document on 'Diameter Load Information' as a working group item Done - Submit I-D 'Diameter Agent Overload' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Load Information' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Routing Message Priority' to the IESG for considerations as a Proposed Standard Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Internet-Drafts: - Diameter Credit-Control Application [draft-bertz-dime-rfc4006bis-01] (113 pages) - Diameter Overload Indication Conveyance [draft-docdt-dime-ovli-01] (41 pages) - Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions [draft-ietf-dime-4over6-provisioning-06] (23 pages) - Diameter Agent Overload and the Peer Overload Report [draft-ietf-dime-agent-overload-11] (19 pages) - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-28] (29 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-07] (6 pages) - Diameter Congestion and Filter Attributes [draft-ietf-dime-congestion-flow-attributes-02] (9 pages) - The Diameter API [draft-ietf-dime-diameter-api-08] (46 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-06] (51 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-01] (5 pages) - Diameter Quality-of-Service Application [draft-ietf-dime-diameter-qos-15] (51 pages) - Diameter Overload Rate Control [draft-ietf-dime-doic-rate-control-11] (20 pages) - Diameter Routing Message Priority [draft-ietf-dime-drmp-07] (18 pages) - Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements [draft-ietf-dime-e2e-sec-req-05] (11 pages) - Diameter Support for the EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-17] (18 pages) - Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage [draft-ietf-dime-extended-naptr-09] (14 pages) - Diameter Group Signaling [draft-ietf-dime-group-signaling-14] (21 pages) - Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers [draft-ietf-dime-ikev2-psk-diameter-11] (17 pages) - Diameter Load Information Conveyance [draft-ietf-dime-load-09] (23 pages) - Diameter Attribute-Value Pairs for Cryptographic Key Transport [draft-ietf-dime-local-keytran-14] (7 pages) - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-12] (17 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-17] (34 pages) - Clarifications on the Routing of Diameter Requests Based on the Username and the Realm [draft-ietf-dime-nai-routing-04] (11 pages) - Diameter Network Address and Port Translation Control Application [draft-ietf-dime-nat-control-17] (58 pages) - Diameter Overload Control Requirements [draft-ietf-dime-overload-reqs-13] (29 pages) - Diameter Overload Indication Conveyance [draft-ietf-dime-ovli-10] (42 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-04] (20 pages) - Diameter Support for Proxy Mobile IPv6 Localized Routing [draft-ietf-dime-pmip6-lr-18] (11 pages) - Diameter Priority Attribute-Value Pairs [draft-ietf-dime-priority-avps-06] (10 pages) - Traffic Classification and Quality of Service (QoS) Attributes for Diameter [draft-ietf-dime-qos-attributes-15] (43 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-11] (12 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-13] (10 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-34] (152 pages) - Diameter Network Access Server Application [draft-ietf-dime-rfc4005bis-14] (70 pages) - Diameter Credit-Control Application [draft-ietf-dime-rfc4006bis-12] (130 pages) - Diameter AVP Level Security: Scenarios and Requirements [draft-tschofenig-dime-e2e-sec-req-01] (8 pages) - Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions [draft-zhou-dime-4over6-provisioning-05] (19 pages) Requests for Comments: BCP193: Diameter Applications Design Guidelines (29 pages) RFC5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (17 pages) RFC5624: Quality of Service Parameters for Usage with Diameter (12 pages) RFC5719: Updated IANA Considerations for Diameter Command Code Allocations (5 pages) * Obsoletes RFC6733 RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (11 pages) RFC5777: Traffic Classification and Quality of Service (QoS) Attributes for Diameter (43 pages) RFC5778: Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (34 pages) RFC5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (20 pages) RFC5866: Diameter Quality-of-Service Application (51 pages) RFC6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage (14 pages) RFC6733: Diameter Base Protocol (152 pages) * Updates RFC7075 * Updates RFC8553 RFC6734: Diameter Attribute-Value Pairs for Cryptographic Key Transport (7 pages) RFC6735: Diameter Priority Attribute-Value Pairs (10 pages) RFC6736: Diameter Network Address and Port Translation Control Application (58 pages) RFC6737: The Diameter Capabilities Update Application (6 pages) RFC6738: Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers (17 pages) RFC6942: Diameter Support for the EAP Re-authentication Protocol (ERP) (18 pages) RFC7068: Diameter Overload Control Requirements (29 pages) RFC7075: Realm-Based Redirection In Diameter (10 pages) RFC7155: Diameter Network Access Server Application (70 pages) RFC7156: Diameter Support for Proxy Mobile IPv6 Localized Routing (11 pages) RFC7423: Diameter Applications Design Guidelines (29 pages) RFC7660: Diameter Congestion and Filter Attributes (9 pages) RFC7678: Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions (23 pages) RFC7683: Diameter Overload Indication Conveyance (42 pages) * Updates RFC8581 RFC7944: Diameter Routing Message Priority (18 pages) RFC7966: Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements (11 pages) RFC8506: Diameter Credit-Control Application (130 pages) RFC8581: Diameter Agent Overload and the Peer Overload Report (19 pages) RFC8582: Diameter Overload Rate Control (20 pages) RFC8583: Diameter Load Information Conveyance (23 pages) RFC9390: Diameter Group Signaling (21 pages) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2023-04-16 Current Status: Active Chairs: Benno Overeinder Suzanne Woolf Tim Wicinski Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: https://mailarchive.ietf.org/arch/browse/dnsop/ Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software and services and for the administration of DNS zones. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Describe practices by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, TLD name servers, or any other resolver or server functioning as part of the global DNS. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software and services, including root, TLD, and recursive servers. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning DNS operational procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation and guidance on DNS-related IPv6 transition and coexistence issues. 4. Publish documents to address operational issues with the DNS protocols by extending or performing protocol maintenance on them. Act as focal-point for operator discussion and provide advice to the Ops ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a home for drafts that document the problem space around existing or new DNS issues. The group, with the advice and consent of the responsible AD in coordination with other areas, will then decide whether these issues belong in DNSOP under the existing charter and, if not, will work with the authors and appropriate ADs to determine the proper place for the work to be carried out. 6. Publish documents that attempt to better define the overlapping area among the public DNS root, DNS-like names as used in local or restricted naming scopes, and the 'special names' registry that IETF manages, perhaps including how they might interact. This work must take into consideration issues that are strictly beyond the operation of the DNS itself, and the working group will consult with IETF liaisons to other organizations as appropriate. Goals and Milestones: Done - IESG Appoval for dnssec-key-timing Internet-Drafts: - A Common Operational Problem in DNS Servers - Failure To Respond. [draft-andrews-dns-no-response-issue-16] (16 pages) - Glue In DNS Referral Responses Is Not Optional [draft-andrews-dnsop-glue-is-not-optional-01] (5 pages) - The .onion Special-Use Domain Name [draft-appelbaum-dnsop-onion-tld-01] (6 pages) - DNS Error Reporting [draft-arends-dns-error-reporting-00] (10 pages) - Top-level Domains for Private Internets [draft-arends-private-use-tld-02] (12 pages) - DNS Multiple QTYPEs [draft-bellis-dnsext-multi-qtypes-07] (7 pages) - DNS Session Signaling [draft-bellis-dnsop-session-signal-02] (13 pages) - Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-belyavskiy-rfc5933-bis-02] (8 pages) - NXDOMAIN really means there is nothing underneath [draft-bortzmeyer-dnsop-nxdomain-cut-02] (9 pages) - DNS query name minimisation to improve privacy [draft-bortzmeyer-dns-qname-minimisation-02] (6 pages) - DNS Query Name Minimisation to Improve Privacy [draft-bortzmeyer-rfc7816bis-00] (12 pages) - DNS Scoped Data Through '_Underscore' Attribute Leaves [draft-crocker-dns-attrleaf-07] (13 pages) - DNS Transport over TCP - Implementation Requirements [draft-dickinson-dnsop-5966-bis-00] (12 pages) - C-DNS: A DNS Packet Capture Format [draft-dickinson-dnsop-dns-capture-format-00] (37 pages) - Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY [draft-dnsop-refuse-any-00] (16 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-dupont-dnsop-rfc2845bis-01] (23 pages) - Negative Caching of DNS Resolution Failures [draft-dwmtwc-dnsop-caching-resolution-failures-01] (13 pages) - Domain Name System (DNS) Cookies [draft-eastlake-dnsext-cookies-05] (27 pages) - Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE [draft-fanf-dnsop-rfc2317bis-01] (22 pages) - Fragmentation Avoidance in DNS [draft-fujiwara-dnsop-avoid-fragmentation-03] (10 pages) - Aggressive use of NSEC/NSEC3 [draft-fujiwara-dnsop-nsec-aggressiveuse-03] (14 pages) - Updating Resolver Algorithm [draft-fujiwara-dnsop-resolver-update-00] (9 pages) - Security Considerations for RFC5011 Publishers [draft-hardaker-rfc5011-security-considerations-04] (9 pages) - DNS Security Extensions (DNSSEC) [draft-hoffman-dnssec-00] (7 pages) - Revised IANA Considerations for DNSSEC [draft-hoffman-dnssec-iana-cons-01] (4 pages) - Terminology for DNS Transports and Location [draft-hoffman-dns-terminology-ter-02] (3 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-howard-isp-ip6rdns-08] (13 pages) - Address-specific DNS Name Redirection (ANAME) [draft-hunt-dnsop-aname-00] (10 pages) - Compact Denial of Existence in DNSSEC [draft-huque-dnsop-compact-lies-01] (8 pages) - Multi Provider DNSSEC models [draft-huque-dnsop-multi-provider-dnssec-04] (11 pages) - Delegation Revalidation by DNS Resolvers [draft-huque-dnsop-ns-revalidation-01] (7 pages) - A Sentinel for Detecting Trusted Keys in DNSSEC [draft-huston-kskroll-sentinel-04] (8 pages) - DNS Transport over TCP - Implementation Requirements [draft-ietf-dnsop-5966bis-06] (19 pages) - Running a Root Server Local to a Resolver [draft-ietf-dnsop-7706bis-12] (12 pages) - Algorithm Implementation Requirements and Usage Guidance for DNSSEC [draft-ietf-dnsop-algorithm-update-10] (11 pages) - The ALT Special Use Top Level Domain [draft-ietf-dnsop-alt-tld-25] (13 pages) - AS112 Redirection Using DNAME [draft-ietf-dnsop-as112-dname-06] (16 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-09] (18 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-06] (8 pages) - Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves [draft-ietf-dnsop-attrleaf-16] (15 pages) - DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names [draft-ietf-dnsop-attrleaf-fix-07] (15 pages) - Fragmentation Avoidance in DNS [draft-ietf-dnsop-avoid-fragmentation-12] (12 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-06] (18 pages) - Negative Caching of DNS Resolution Failures [draft-ietf-dnsop-caching-resolution-failures-02] (15 pages) - Child-to-Parent Synchronization in DNS [draft-ietf-dnsop-child-syncronization-07] (15 pages) - Compact Denial of Existence in DNSSEC [draft-ietf-dnsop-compact-denial-of-existence-00] (8 pages) - Domain Name System (DNS) Cookies [draft-ietf-dnsop-cookies-10] (25 pages) - Locally Served DNS Zones [draft-ietf-dnsop-default-local-zones-15] (10 pages) - The DELEGATION_ONLY DNSKEY flag [draft-ietf-dnsop-delegation-only-02] (11 pages) - Automating DNSSEC Delegation Trust Maintenance [draft-ietf-dnsop-delegation-trust-maintainance-14] (18 pages) - Compacted-DNS (C-DNS): A Format for DNS Packet Capture [draft-ietf-dnsop-dns-capture-format-10] (79 pages) - DNS Catalog Zones [draft-ietf-dnsop-dns-catalog-zones-09] (24 pages) - DNS Error Reporting [draft-ietf-dnsop-dns-error-reporting-04] (10 pages) - DNSSEC automation [draft-ietf-dnsop-dnssec-automation-01] (12 pages) - DNS Security Extensions (DNSSEC) [draft-ietf-dnsop-dnssec-bcp-06] (10 pages) - Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator [draft-ietf-dnsop-dnssec-bootstrapping-04] (16 pages) - A Framework for DNSSEC Policies and DNSSEC Practice Statements [draft-ietf-dnsop-dnssec-dps-framework-11] (27 pages) - Revised IANA Considerations for DNSSEC [draft-ietf-dnsop-dnssec-iana-cons-05] (5 pages) - DNSSEC Key Rollover Timing Considerations [draft-ietf-dnsop-dnssec-key-timing-06] (31 pages) - DNSSEC Operational Practices [draft-ietf-dnsop-dnssec-operational-practices-08] (35 pages) - DNSSEC Roadblock Avoidance [draft-ietf-dnsop-dnssec-roadblock-avoidance-05] (19 pages) - Recommendations for DNSSEC Resolvers Operators [draft-ietf-dnsop-dnssec-validator-requirements-04] (26 pages) - DNS Transport over TCP - Operational Requirements [draft-ietf-dnsop-dns-tcp-requirements-15] (29 pages) - DNS Terminology [draft-ietf-dnsop-dns-terminology-05] (27 pages) - Message Digest for DNS Zones [draft-ietf-dnsop-dns-zone-digest-14] (31 pages) - Domain Verification Techniques using DNS [draft-ietf-dnsop-domain-verification-techniques-01] (11 pages) - CHAIN Query Requests in DNS [draft-ietf-dnsop-edns-chain-query-07] (16 pages) - Client Subnet in DNS Queries [draft-ietf-dnsop-edns-client-subnet-08] (30 pages) - Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) [draft-ietf-dnsop-edns-key-tag-05] (13 pages) - The edns-tcp-keepalive EDNS0 Option [draft-ietf-dnsop-edns-tcp-keepalive-06] (11 pages) - Extended DNS Errors [draft-ietf-dnsop-extended-error-16] (13 pages) - DNS Glue Requirements in Referral Responses [draft-ietf-dnsop-glue-is-not-optional-08] (12 pages) - Distributing Authoritative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (11 pages) - YANG Types for DNS Classes and Resource Record Types [draft-ietf-dnsop-iana-class-type-yang-05] (14 pages) - IPv6 Host Configuration of DNS Server Information Approaches [draft-ietf-dnsop-ipv6-dns-configuration-06] (26 pages) - Operational Considerations and Issues with IPv6 DNS [draft-ietf-dnsop-ipv6-dns-issues-12] (29 pages) - DNS IPv6 Transport Operational Guidelines [draft-ietf-dnsop-ipv6-transport-guidelines-02] (5 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-ietf-dnsop-isp-ip6rdns-07] (15 pages) - A Root Key Trust Anchor Sentinel for DNSSEC [draft-ietf-dnsop-kskroll-sentinel-17] (19 pages) - Let 'localhost' be localhost. [draft-ietf-dnsop-let-localhost-be-localhost-02] (10 pages) - Managing DS Records from the Parent via CDS/CDNSKEY [draft-ietf-dnsop-maintain-ds-06] (10 pages) - Common Misbehavior Against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-02] (6 pages) - Multi-Signer DNSSEC Models [draft-ietf-dnsop-multi-provider-dnssec-05] (13 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-05] (17 pages) - Definition and Use of DNSSEC Negative Trust Anchors [draft-ietf-dnsop-negative-trust-anchors-13] (16 pages) - A Common Operational Problem in DNS Servers: Failure to Communicate [draft-ietf-dnsop-no-response-issue-23] (24 pages) - Guidance for NSEC3 Parameter Settings [draft-ietf-dnsop-nsec3-guidance-10] (10 pages) - Aggressive Use of DNSSEC-Validated Cache [draft-ietf-dnsop-nsec-aggressiveuse-10] (13 pages) - NSEC and NSEC3: TTLs and Aggressive Use [draft-ietf-dnsop-nsec-ttl-05] (8 pages) - Delegation Revalidation by DNS Resolvers [draft-ietf-dnsop-ns-revalidation-04] (7 pages) - NXDOMAIN: There Really Is Nothing Underneath [draft-ietf-dnsop-nxdomain-cut-05] (10 pages) - Moving DNSSEC Lookaside Validation (DLV) to Historic Status [draft-ietf-dnsop-obsolete-dlv-02] (6 pages) - The ".onion" Special-Use Domain Name [draft-ietf-dnsop-onion-tld-01] (7 pages) - Top-level Domains for Private Internets [draft-ietf-dnsop-private-use-tld-01] (14 pages) - DNS Query Name Minimisation to Improve Privacy [draft-ietf-dnsop-qname-minimisation-09] (11 pages) - Preventing Use of Recursive Nameservers in Reflector Attacks [draft-ietf-dnsop-reflectors-are-evil-06] (7 pages) - Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY [draft-ietf-dnsop-refuse-any-07] (10 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-11] (7 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-15] (21 pages) - Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE [draft-ietf-dnsop-rfc2317bis-00] (22 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsop-rfc2845bis-09] (22 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-13] (71 pages) - Security Considerations for RFC5011 Publishers [draft-ietf-dnsop-rfc5011-security-considerations-13] (20 pages) - Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsop-rfc5933-bis-13] (11 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-rfc6304bis-06] (24 pages) - Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry [draft-ietf-dnsop-rfc6598-rfc6303-05] (6 pages) - DNS Query Name Minimisation to Improve Privacy [draft-ietf-dnsop-rfc7816bis-11] (11 pages) - DNS Terminology [draft-ietf-dnsop-rfc8499bis-07] (56 pages) - Decreasing Access Time to Root Servers by Running One on Loopback [draft-ietf-dnsop-root-loopback-05] (12 pages) - Root Name Server Operational Requirements [draft-ietf-dnsop-root-opreq-04] (10 pages) - The "RRSERIAL" EDNS option for the SOA serial of a RR's zone [draft-ietf-dnsop-rrserial-01] (6 pages) - Interoperable Domain Name System (DNS) Server Cookies [draft-ietf-dnsop-server-cookies-05] (16 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-08] (8 pages) - Serving Stale Data to Improve DNS Resiliency [draft-ietf-dnsop-serve-stale-10] (12 pages) - DNS Stateful Operations [draft-ietf-dnsop-session-signal-20] (64 pages) - Structured Error Data for Filtered DNS [draft-ietf-dnsop-structured-dns-error-03] (21 pages) - Special-Use Domain Names Problem Statement [draft-ietf-dnsop-sutld-ps-08] (25 pages) - Using Service Bindings with DANE [draft-ietf-dnsop-svcb-dane-00] (9 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) [draft-ietf-dnsop-svcb-https-12] (61 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) [draft-ietf-dnsop-svcb-httpssvc-03] (39 pages) - DNS Terminology [draft-ietf-dnsop-terminology-bis-14] (50 pages) - Terminology for DNS Transports and Location [draft-ietf-dnsop-terminology-ter-02] (3 pages) - DNS TIMEOUT Resource Record [draft-ietf-dnsop-update-timeout-01] (18 pages) - The "ZONEVERSION" EDNS option for the version token of a RR's zone [draft-ietf-dnsop-zoneversion-02] (10 pages) - Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY [draft-jabley-dnsop-refuse-any-01] (16 pages) - Decreasing Access Time to Root Servers by Running One On The Same Server [draft-kh-dnsop-7706bis-01] (12 pages) - Initializing a DNS Resolver with Priming Queries [draft-klh-dnsop-rfc8109bis-06] (10 pages) - DNS Transport over TCP - Operational Requirements [draft-kristoff-dnsop-dns-tcp-requirements-02] (11 pages) - YANG Types for DNS Classes and Resource Record Types [draft-lhotka-dnsop-iana-class-type-yang-02] (24 pages) - Moving DNSSEC Lookaside Validation (DLV) to Historic Status [draft-mekking-dnsop-obsolete-dlv-00] (5 pages) - Recommendations for DNSSEC Resolvers Operators [draft-mglt-dnsop-dnssec-validator-requirements-09] (23 pages) - DNS Catalog Zones [draft-muks-dnsop-dns-catalog-zones-04] (16 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) [draft-nygren-dnsop-svcb-httpssvc-00] (33 pages) - Managing DS records from parent via CDS/CDNSKEY [draft-ogud-dnsop-maintain-ds-00] (8 pages) - DNS TIMEOUT Resource Record [draft-pusateri-dnsop-update-timeout-05] (18 pages) - The DELEGATION_ONLY DNSKEY flag [draft-pwouters-powerbind-04] (11 pages) - Using Service Bindings with DANE [draft-rebs-dnsop-svcb-dane-01] (9 pages) - Survey of Domain Verification Techniques using DNS [draft-sahib-domain-verification-techniques-03] (12 pages) - DNS Resolver Information Self-publication [draft-sah-resolver-information-02] (9 pages) - The "RRSERIAL" EDNS option for the SOA serial of a RR's zone [draft-salgado-dnsop-rrserial-01] (6 pages) - DNS wire-format over HTTP [draft-song-dns-wireformat-http-04] (10 pages) - Interoperable Domain Name System (DNS) Server Cookies [draft-sury-toorop-dnsop-server-cookies-00] (14 pages) - Serving Stale Data to Improve DNS Resiliency [draft-tale-dnsop-serve-stale-02] (10 pages) - Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator [draft-thomassen-dnsop-dnssec-bootstrapping-03] (14 pages) - DNS Catalog Zones [draft-toorop-dnsop-dns-catalog-zones-01] (11 pages) - NSEC(3) TTLs and NSEC Aggressive Use [draft-vandijk-dnsop-nsec-ttl-00] (6 pages) - DNS Response Policy Zones (RPZ) [draft-vixie-dns-rpz-04] (30 pages) - Message Digest for DNS Zones [draft-wessels-dns-zone-digest-06] (27 pages) - The EDNS Key Tag Option [draft-wessels-edns-key-tag-00] (9 pages) - Let 'localhost' be localhost. [draft-west-let-localhost-be-localhost-06] (9 pages) - Structured Data for Filtered DNS [draft-wing-dnsop-structured-dns-error-page-05] (16 pages) - DNSSEC automation [draft-wisser-dnssec-automation-03] (12 pages) - The ALT Special Use Top Level Domain [draft-wkumari-dnsop-alt-tld-06] (10 pages) - Extended DNS Errors [draft-wkumari-dnsop-extended-error-02] (9 pages) - Decreasing Access Time to Root Servers by Running One on Loopback [draft-wkumari-dnsop-root-loopback-02] (9 pages) - Algorithm Implementation Requirements and Usage Guidance for DNSSEC [draft-wouters-sury-dnsop-algorithm-update-02] (9 pages) Requests for Comments: BCP123: Observed DNS Resolution Misbehavior (18 pages) BCP140: Preventing Use of Recursive Nameservers in Reflector Attacks (7 pages) BCP163: Locally Served DNS Zones (10 pages) BCP207: DNSSEC Roadblock Avoidance (19 pages) BCP209: Initializing a DNS Resolver with Priming Queries (7 pages) BCP219: DNS Terminology (50 pages) BCP222: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves (15 pages) BCP231: A Common Operational Problem in DNS Servers: Failure to Communicate (24 pages) BCP235: DNS Transport over TCP - Operational Requirements (29 pages) BCP236: Guidance for NSEC3 Parameter Settings (10 pages) BCP237: DNS Security Extensions (DNSSEC) (10 pages) BCP40: Root Name Server Operational Requirements (10 pages) BCP91: DNS IPv6 Transport Operational Guidelines (5 pages) RFC2870: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC7720 RFC3258: Distributing Authoritative Name Servers via Shared Unicast Addresses (11 pages) RFC3901: DNS IPv6 Transport Operational Guidelines (5 pages) RFC4074: Common Misbehavior Against DNS Queries for IPv6 Addresses (6 pages) RFC4339: IPv6 Host Configuration of DNS Server Information Approaches (26 pages) RFC4472: Operational Considerations and Issues with IPv6 DNS (29 pages) RFC4641: DNSSEC Operational Practices (35 pages) * Obsoletes RFC6781 RFC4697: Observed DNS Resolution Misbehavior (18 pages) RFC4892: Requirements for a Mechanism Identifying a Name Server Instance (8 pages) RFC5358: Preventing Use of Recursive Nameservers in Reflector Attacks (7 pages) RFC6168: Requirements for Management of Name Servers for the DNS (17 pages) RFC6303: Locally Served DNS Zones (10 pages) RFC6304: AS112 Nameserver Operations (18 pages) * Obsoletes RFC7534 RFC6305: I'm Being Attacked by PRISONER.IANA.ORG! (8 pages) RFC6781: DNSSEC Operational Practices, Version 2 (71 pages) RFC6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (27 pages) RFC7344: Automating DNSSEC Delegation Trust Maintenance (18 pages) * Updates RFC8078 RFC7477: Child-to-Parent Synchronization in DNS (15 pages) RFC7534: AS112 Nameserver Operations (24 pages) RFC7535: AS112 Redirection Using DNAME (16 pages) RFC7583: DNSSEC Key Rollover Timing Considerations (31 pages) RFC7646: Definition and Use of DNSSEC Negative Trust Anchors (16 pages) RFC7686: The ".onion" Special-Use Domain Name (7 pages) RFC7706: Decreasing Access Time to Root Servers by Running One on Loopback (12 pages) * Obsoletes RFC8806 RFC7719: DNS Terminology (27 pages) * Obsoletes RFC8499 RFC7766: DNS Transport over TCP - Implementation Requirements (19 pages) * Updates RFC8490 * Updates RFC9103 RFC7793: Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry (6 pages) RFC7816: DNS Query Name Minimisation to Improve Privacy (11 pages) * Obsoletes RFC9156 RFC7828: The edns-tcp-keepalive EDNS0 Option (11 pages) RFC7871: Client Subnet in DNS Queries (30 pages) RFC7873: Domain Name System (DNS) Cookies (25 pages) * Updates RFC9018 RFC7901: CHAIN Query Requests in DNS (16 pages) RFC8020: NXDOMAIN: There Really Is Nothing Underneath (10 pages) RFC8027: DNSSEC Roadblock Avoidance (19 pages) RFC8078: Managing DS Records from the Parent via CDS/CDNSKEY (10 pages) RFC8109: Initializing a DNS Resolver with Priming Queries (7 pages) RFC8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (13 pages) * Updates RFC8553 RFC8198: Aggressive Use of DNSSEC-Validated Cache (13 pages) * Updates RFC9077 RFC8244: Special-Use Domain Names Problem Statement (25 pages) RFC8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (10 pages) RFC8490: DNS Stateful Operations (64 pages) RFC8499: DNS Terminology (50 pages) RFC8501: Reverse DNS in IPv6 for Internet Service Providers (15 pages) RFC8509: A Root Key Trust Anchor Sentinel for DNSSEC (19 pages) RFC8552: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves (15 pages) RFC8553: DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names (15 pages) RFC8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture (79 pages) RFC8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC (11 pages) * Updates RFC9157 RFC8749: Moving DNSSEC Lookaside Validation (DLV) to Historic Status (6 pages) RFC8767: Serving Stale Data to Improve DNS Resiliency (12 pages) RFC8806: Running a Root Server Local to a Resolver (12 pages) RFC8901: Multi-Signer DNSSEC Models (13 pages) RFC8906: A Common Operational Problem in DNS Servers: Failure to Communicate (24 pages) RFC8914: Extended DNS Errors (13 pages) RFC8945: Secret Key Transaction Authentication for DNS (TSIG) (22 pages) RFC8976: Message Digest for DNS Zones (31 pages) RFC9018: Interoperable Domain Name System (DNS) Server Cookies (16 pages) RFC9077: NSEC and NSEC3: TTLs and Aggressive Use (8 pages) RFC9108: YANG Types for DNS Classes and Resource Record Types (14 pages) RFC9156: DNS Query Name Minimisation to Improve Privacy (11 pages) RFC9157: Revised IANA Considerations for DNSSEC (5 pages) RFC9210: DNS Transport over TCP - Operational Requirements (29 pages) RFC9276: Guidance for NSEC3 Parameter Settings (10 pages) RFC9364: DNS Security Extensions (DNSSEC) (10 pages) STD93: Secret Key Transaction Authentication for DNS (TSIG) (22 pages) Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Chris Morrow Job Snijders Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: https://mailarchive.ietf.org/arch/browse/grow/ Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Goals and Milestones: Done - Publish Risk, Interference and Fit (RIFT) document as WG I-D Done - Publish Embedding Globally ...Considered Harmful as WG I-D Done - Publish MED Considerations Draft as WG I-D Done - Publish Collection Communities as WG I-D Done - Submit Collection Communities to IESG for BCP Done - Submit Embedding Globally ...Considered Harmful to IESG for Info Done - Submit MED Considerations to IESG for Info Internet-Drafts: - Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) [draft-evens-grow-bmp-adj-rib-out-01] (10 pages) - Support for Local RIB in BGP Monitoring Protocol (BMP) [draft-evens-grow-bmp-local-rib-00] (12 pages) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-04] (24 pages) - A well-known BGP community to denote prefixes used for Anycast [draft-ietf-grow-anycast-community-00] (7 pages) - AS Path Prepending [draft-ietf-grow-as-path-prepending-07] (12 pages) - Requirements for the Graceful Shutdown of BGP Sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-07] (20 pages) - Graceful BGP Session Shutdown [draft-ietf-grow-bgp-gshut-13] (12 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-05] (13 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - Default External BGP (EBGP) Route Propagation Behavior without Policies [draft-ietf-grow-bgp-reject-08] (7 pages) - Mitigating the Negative Impact of Maintenance through BGP Session Culling [draft-ietf-grow-bgp-session-culling-05] (10 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-03] (10 pages) - BLACKHOLE Community [draft-ietf-grow-blackholing-03] (9 pages) - BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-17] (27 pages) - Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-adj-rib-out-07] (9 pages) - Support for Local RIB in the BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-local-rib-13] (14 pages) - BMP Peer Up Message Namespace [draft-ietf-grow-bmp-peer-up-00] (5 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-ietf-grow-bmp-registries-change-01] (3 pages) - TLV support for BMP Route Monitoring and Peer Down Messages [draft-ietf-grow-bmp-tlv-12] (10 pages) - Support for Enterprise-specific TLVs in the BGP Monitoring Protocol [draft-ietf-grow-bmp-tlv-ebit-02] (7 pages) - BMP YANG Module [draft-ietf-grow-bmp-yang-01] (31 pages) - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-08] (12 pages) - Distribution of Diverse BGP Paths [draft-ietf-grow-diverse-bgp-path-dist-08] (22 pages) - Embedding Globally-Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-05] (10 pages) - Impact of BGP Filtering on Inter-Domain Routing Policies [draft-ietf-grow-filtering-threats-08] (16 pages) - Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions [draft-ietf-grow-geomrt-07] (8 pages) - Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration [draft-ietf-grow-irr-routing-policy-considerations-06] (18 pages) - Internet Exchange BGP Route Server Operations [draft-ietf-grow-ix-bgp-route-server-operations-05] (15 pages) - Use of BGP Large Communities [draft-ietf-grow-large-communities-usage-07] (15 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format [draft-ietf-grow-mrt-17] (33 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions [draft-ietf-grow-mrt-add-paths-03] (6 pages) - Time to Remove Filters for Previously Unallocated IPv4 /8s [draft-ietf-grow-no-more-unallocated-slash8s-04] (5 pages) - Near Real Time Mirroring (NRTM) version 4 [draft-ietf-grow-nrtm-v4-01] (21 pages) - Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 [draft-ietf-grow-ops-reqs-for-bgp-error-handling-07] (14 pages) - Issues with Private IP Addressing in the Internet [draft-ietf-grow-private-ip-sp-cores-07] (14 pages) - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [draft-ietf-grow-rfc1519bis-04] (27 pages) - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) [draft-ietf-grow-rift-01] (39 pages) - Methods for Detection and Mitigation of BGP Route Leaks [draft-ietf-grow-route-leak-detection-mitigation-08] (10 pages) - Problem Definition and Classification of BGP Route Leaks [draft-ietf-grow-route-leak-problem-definition-06] (11 pages) - RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering [draft-ietf-grow-rpki-as-cones-02] (10 pages) - The "import-via" and "export-via" attributes in RPSL Policy Specifications [draft-ietf-grow-rpsl-via-01] (10 pages) - Routing System Stability [draft-ietf-grow-rss-00] (13 pages) - Route-Leaks & MITM Attacks Against BGPSEC [draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04] (8 pages) - Simple Virtual Aggregation (S-VA) [draft-ietf-grow-simple-va-12] (8 pages) - Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services [draft-ietf-grow-unique-origin-as-01] (10 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-06] (24 pages) - Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-05] (6 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-00] (7 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-00] (16 pages) - Policy Behavior for Well-Known BGP Communities [draft-ietf-grow-wkc-behavior-08] (7 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-scudder-grow-bmp-registries-change-00] (3 pages) - Usage of Large BGP Communities [draft-snijders-grow-large-communities-usage-00] (10 pages) - The "import-via" and "export-via" attributes in RPSL Policy Specifications [draft-snijders-rpsl-via-03] (9 pages) Requests for Comments: BCP105: Embedding Globally-Routable Internet Addresses Considered Harmful (10 pages) BCP114: BGP Communities for Data Collection (12 pages) BCP122: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (27 pages) BCP126: Operation of Anycast Services (24 pages) BCP169: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) BCP171: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) BCP214: Mitigating the Negative Impact of Maintenance through BGP Session Culling (10 pages) RFC4085: Embedding Globally-Routable Internet Addresses Considered Harmful (10 pages) RFC4264: BGP Wedgies (10 pages) RFC4384: BGP Communities for Data Collection (12 pages) RFC4451: BGP MULTI_EXIT_DISC (MED) Considerations (13 pages) RFC4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (27 pages) RFC4786: Operation of Anycast Services (24 pages) RFC6198: Requirements for the Graceful Shutdown of BGP Sessions (20 pages) RFC6382: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) RFC6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format (33 pages) RFC6397: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions (8 pages) RFC6441: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) RFC6752: Issues with Private IP Addressing in the Internet (14 pages) RFC6769: Simple Virtual Aggregation (S-VA) (8 pages) RFC6774: Distribution of Diverse BGP Paths (22 pages) RFC7682: Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration (18 pages) RFC7789: Impact of BGP Filtering on Inter-Domain Routing Policies (16 pages) RFC7854: BGP Monitoring Protocol (BMP) (27 pages) * Updates RFC8671 * Updates RFC9069 RFC7908: Problem Definition and Classification of BGP Route Leaks (11 pages) RFC7948: Internet Exchange BGP Route Server Operations (15 pages) RFC7999: BLACKHOLE Community (9 pages) RFC8050: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions (6 pages) RFC8195: Use of BGP Large Communities (15 pages) RFC8212: Default External BGP (EBGP) Route Propagation Behavior without Policies (7 pages) RFC8326: Graceful BGP Session Shutdown (12 pages) RFC8327: Mitigating the Negative Impact of Maintenance through BGP Session Culling (10 pages) RFC8642: Policy Behavior for Well-Known BGP Communities (7 pages) RFC8671: Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) (9 pages) RFC9069: Support for Local RIB in the BGP Monitoring Protocol (BMP) (14 pages) IOT Operations (iotops) ----------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Alexey Melnikov Henk Birkholz Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Editor: Warren Kumari Mailing Lists: General Discussion: iotops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/iotops Archive: https://mailarchive.ietf.org/arch/browse/iotops/ Description of Working Group: The IOTOPS Working Group is chartered for the discussion of operational issues related to Internet of Things (IoT) devices, in particular related to device onboarding and lifecycle management. IoT has a rather nebulous definition with different meanings for different people. For the purposes of this WG, its focus is on devices that - are networked, either to the Internet or within limited administrative domains - have a very limited end user interface or no end-user interface at all - are deployed in sufficiently large numbers that they cannot easily be managed or maintained manually The IETF works on a number of technologies related to IoT. This includes, but is not limited to work done in ACE, ANIMA, CBOR, CORE, DRIP, LAKE, LPWAN, LWIG, ROLL, SUIT, TEEP, 6LO, 6TISCH, and other working groups. IOTOPS is intended to be a discussion venue where people can discuss how various IoT-related technologies fit together. IOTOPS provides a venue for IoT experts and other interested parties to engage in discussions of operational IoT requirements, as well as proposals for new uses of IP technology related to IoT devices and network operations. Revision, updates, and extensions to work from existing WGs will be done in those WGs. Where new work may be needed, IOTOPS will help identify candidate venues within IETF for their development. IOTOPS WG charter is restricted to: 1) Taking input and discussing issues related to the operational management of IoT devices. This includes (but is not limited to): - factory provisioning of devices - onboarding of devices - access control of devices to network resources - administrative control of devices - software/firmware upgrades - isolation/quarantine of devices - remediation of broken devices - end of life management of devices 2) Taking input and discussing issues related to IoT operational security. 3) Publishing operational practices. 4) Documenting requirements. Approximately one year after chartering, the WG chairs will prepare a report for the IESG summarizing what the group has accomplished; this is both as a checkpoint for this working group and as a demonstration to the IESG that this style of working groups such as this have value and should be considered more often. Goals and Milestones: Internet-Drafts: - Comparison of CoAP Security Protocols [draft-ietf-iotops-security-protocol-comparison-02] (49 pages) - A summary of security-enabling technologies for IoT devices [draft-moran-iot-nets-03] (19 pages) No Requests for Comments IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2022-08-31 Current Status: Active Chairs: Ron Bonica XiPeng Xiao Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Tech Advisor: Fred Baker Mailing Lists: General Discussion: v6ops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/v6ops Archive: https://mailarchive.ietf.org/arch/browse/v6ops/ Description of Working Group: The global deployment of IPv6 is underway, creating an Internet consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and IPv6+translation networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks, ensuring addressing and connectivity for all IPv4 and IPv6 nodes. IPv6 deployment has resulted in the shutdown of IPv4 in some networks. Removing IPv4 constraints has resulted in innovations in IPv6 network operations. The IPv6 Operations Working Group (v6ops) develops guidelines for the deployment and operation of new and existing IPv6 networks. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with IPv6 networks, and determine solutions or workarounds to those issues. 2. Solicit input from network operators and users to identify operational interaction issues with the IPv4 networks, and determine solutions or workarounds to those issues. 3. Solicit discussion and documentation of the issues and opportunities in IPv6-only operation, and of the resulting innovations. 4. Operational solutions for identified issues should be developed in v6ops and documented in informational or BCP drafts. 5. Document operational requirements for IPv6 networks. These documents should document IPv6 operational experience, including interactions with IPv4, in dual stack networks, IPv6 networks with IPv4 delivered as an overlay or translation service, or IPv6-only networks. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Goals and Milestones: Jul 2019 - Recommendations for DNS in an IPv6 Network Done - File recommendation on how to build a commercial WiFi network Done - Prefix for use by IPv4/IPv6 translators in a network Done - Update RFC 7084 (IPv6 CE Requirements) Done - Update RFC 6555 with experience Done - Recommendations regarding the use of DNS64 Internet-Drafts: - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments [draft-anderson-v6ops-siit-dc-01] (30 pages) - SIIT-DC: Dual Translation Mode [draft-anderson-v6ops-siit-dc-2xlat-00] (8 pages) - IPv6 Address Assignment to End Sites [draft-ietf-v6ops-3177bis-end-sites-01] (9 pages) - Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks [draft-ietf-v6ops-3gpp-analysis-11] (24 pages) - Transition Scenarios for 3GPP Networks [draft-ietf-v6ops-3gpp-cases-03] (12 pages) - IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) [draft-ietf-v6ops-3gpp-eps-08] (36 pages) - 464XLAT: Combination of Stateful and Stateless Translation [draft-ietf-v6ops-464xlat-10] (14 pages) - 464XLAT/MAT-T Optimization [draft-ietf-v6ops-464xlat-optimization-04] (24 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-6204bis-12] (21 pages) - Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link [draft-ietf-v6ops-64share-10] (10 pages) - Advisory Guidelines for 6to4 Deployment [draft-ietf-v6ops-6to4-advisory-02] (20 pages) - Security Considerations for 6to4 [draft-ietf-v6ops-6to4-security-04] (41 pages) - Deprecating the Anycast Prefix for 6to4 Relay Routers [draft-ietf-v6ops-6to4-to-historic-11] (10 pages) - IPv6 Deployment Scenarios in 802.16 Networks [draft-ietf-v6ops-802-16-deployment-scenarios-07] (16 pages) - IPv6 Unicast Address Assignment Considerations [draft-ietf-v6ops-addcon-10] (35 pages) - Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules [draft-ietf-v6ops-addr-select-ps-09] (17 pages) - Requirements for Address Selection Mechanisms [draft-ietf-v6ops-addr-select-req-07] (7 pages) - Application Aspects of IPv6 Transition [draft-ietf-v6ops-application-transition-03] (33 pages) - Goals for Registered Assisted Tunneling [draft-ietf-v6ops-assisted-tunneling-requirements-01] (14 pages) - Balanced Security for IPv6 Residential CPE [draft-ietf-v6ops-balanced-ipv6-security-01] (9 pages) - ISP IPv6 Deployment Scenarios in Broadband Access Networks [draft-ietf-v6ops-bb-deployment-scenarios-05] (81 pages) - IPv6 Campus Transition Scenario Description and Analysis [draft-ietf-v6ops-campus-transition-01] (28 pages) - IPv6 Prefix Length Recommendation for Forwarding [draft-ietf-v6ops-cidr-prefix-03] (6 pages) - IPv4 Service Continuity Prefix [draft-ietf-v6ops-clatip-04] (4 pages) - Using Conditional Router Advertisements for Enterprise Multihoming [draft-ietf-v6ops-conditional-ras-08] (21 pages) - Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [draft-ietf-v6ops-cpe-simple-security-16] (36 pages) - Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events [draft-ietf-v6ops-cpe-slaac-renum-08] (11 pages) - IPv6 Operational Guidelines for Datacenters [draft-ietf-v6ops-dc-ipv6-01] (22 pages) - Routing-Related Design Choices for IPv6 Networks [draft-ietf-v6ops-design-choices-12] (26 pages) - Using DHCP-PD to Allocate Unique IPv6 Prefix per Device in Broadcast Networks [draft-ietf-v6ops-dhcp-pd-per-device-00] (14 pages) - DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration [draft-ietf-v6ops-dhcpv6-slaac-problem-07] (23 pages) - IPv6 Enterprise Network Analysis - IP Layer 3 Focus [draft-ietf-v6ops-ent-analysis-07] (32 pages) - Enterprise IPv6 Deployment Guidelines [draft-ietf-v6ops-enterprise-incremental-ipv6-06] (34 pages) - IPv6 Enterprise Networks Scenarios [draft-ietf-v6ops-entnet-scenarios-00] (17 pages) - IPv6 Enterprise Network Scenarios [draft-ietf-v6ops-ent-scenarios-05] (17 pages) - Framework of Multi-domain IPv6-only Underlay Networks and IPv4-as-a-Service [draft-ietf-v6ops-framework-md-ipv6only-underlay-01] (23 pages) - Happy Eyeballs: Success with Dual-Stack Hosts [draft-ietf-v6ops-happy-eyeballs-07] (15 pages) - Operational Issues with Processing of the Hop-by-Hop Options Header [draft-ietf-v6ops-hbh-04] (15 pages) - Host Address Availability Recommendations [draft-ietf-v6ops-host-addr-availability-07] (15 pages) - Best Current Practice for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-bcp-01] (34 pages) - Recommendations for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-recs-03] (38 pages) - IPv6 Guidance for Internet Content Providers and Application Service Providers [draft-ietf-v6ops-icp-guidance-05] (24 pages) - An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition [draft-ietf-v6ops-incremental-cgn-03] (13 pages) - Using IPsec to Secure IPv6-in-IPv4 Tunnels [draft-ietf-v6ops-ipsec-tunnels-05] (23 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Standards [draft-ietf-v6ops-ipv4survey-00] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-apps-04] (50 pages) - Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards [draft-ietf-v6ops-ipv4survey-gen-00] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-int-03] (49 pages) - Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-intro-06] (10 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-ops-05] (43 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-routing-03] (15 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-sec-04] (25 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-subip-04] (6 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-trans-05] (31 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-09] (17 pages) - Advanced Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-bis-01] (15 pages) - IPv6 Deployment Status [draft-ietf-v6ops-ipv6-deployment-10] (37 pages) - A Discard Prefix for IPv6 [draft-ietf-v6ops-ipv6-discard-prefix-05] (6 pages) - Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [draft-ietf-v6ops-ipv6-ehs-in-real-world-02] (15 pages) - Operational Implications of IPv6 Packets with Extension Headers [draft-ietf-v6ops-ipv6-ehs-packet-drops-08] (17 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06] (22 pages) - Analysis of Failure Cases in IPv6 Roaming Scenarios [draft-ietf-v6ops-ipv6-roaming-analysis-07] (19 pages) - Requirements for IPv6 Routers [draft-ietf-v6ops-ipv6rtr-reqs-04] (32 pages) - Emerging Service Provider Scenarios for IPv6 Deployment [draft-ietf-v6ops-isp-scenarios-00] (23 pages) - Scenarios and Analysis for Introducing IPv6 into ISP Networks [draft-ietf-v6ops-isp-scenarios-analysis-03] (28 pages) - Stateless Source Address Mapping for ICMPv6 Packets [draft-ietf-v6ops-ivi-icmp-address-07] (6 pages) - Basic Transition Mechanisms for IPv6 Hosts and Routers [draft-ietf-v6ops-mech-v2-07] (27 pages) - Monitoring Dual Stack/IPv6-only Networks and Services [draft-ietf-v6ops-monitor-ds-ipv6-00] (10 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-multihoming-without-nat66-00] (19 pages) - Local Network Protection for IPv6 [draft-ietf-v6ops-nap-06] (36 pages) - Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks [draft-ietf-v6ops-nat64-deployment-08] (38 pages) - NAT64 Deployment Options and Experience [draft-ietf-v6ops-nat64-experience-10] (22 pages) - IPv4/IPv6 Coexistence and Transition: Requirements for solutions [draft-ietf-v6ops-nat64-pb-statement-req-00] (17 pages) - NAT64/DNS64 detection via SRV Records [draft-ietf-v6ops-nat64-srv-00] (8 pages) - Reasons to Move NAT-PT to Experimental [draft-ietf-v6ops-natpt-to-exprmntl-03] (25 pages) - Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status [draft-ietf-v6ops-natpt-to-historic-00] (25 pages) - Neighbor Cache Entries on First-Hop Routers: Operational Considerations [draft-ietf-v6ops-nd-cache-init-05] (12 pages) - Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Protocol Issues [draft-ietf-v6ops-nd-considerations-01] (31 pages) - IPv6 Neighbor Discovery On-Link Assumption Considered Harmful [draft-ietf-v6ops-onlinkassumption-04] (8 pages) - Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) [draft-ietf-v6ops-pmtud-ecmp-problem-06] (9 pages) - IPv6 Router Advertisement Guard [draft-ietf-v6ops-ra-guard-08] (10 pages) - Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [draft-ietf-v6ops-ra-guard-implementation-07] (13 pages) - Reducing Energy Consumption of Router Advertisements [draft-ietf-v6ops-reducing-ra-energy-consumption-03] (6 pages) - Procedures for Renumbering an IPv6 Network without a Flag Day [draft-ietf-v6ops-renumbering-procedure-05] (22 pages) - IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts [draft-ietf-v6ops-rfc3316bis-06] (20 pages) - Special-Use IPv6 Addresses [draft-ietf-v6ops-rfc3330-for-ipv6-04] (7 pages) - Happy Eyeballs Version 2: Better Connectivity Using Concurrency [draft-ietf-v6ops-rfc6555bis-07] (15 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-rfc7084-bis-04] (31 pages) - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-02] (16 pages) - IPv6 Routing Policies Guidelines [draft-ietf-v6ops-routing-guidelines-01] (8 pages) - IPv6 Implications for Network Scanning [draft-ietf-v6ops-scanning-implications-04] (13 pages) - IPv6 Transition/Co-existence Security Considerations [draft-ietf-v6ops-security-overview-06] (41 pages) - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments [draft-ietf-v6ops-siit-dc-03] (24 pages) - Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode [draft-ietf-v6ops-siit-dc-2xlat-02] (17 pages) - Explicit Address Mappings for Stateless IP/ICMP Translation [draft-ietf-v6ops-siit-eam-03] (19 pages) - Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events [draft-ietf-v6ops-slaac-renum-05] (11 pages) - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-02] (20 pages) - Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) [draft-ietf-v6ops-transition-comparison-04] (27 pages) - Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service [draft-ietf-v6ops-transition-ipv4aas-15] (21 pages) - Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations [draft-ietf-v6ops-tunnel-loops-07] (19 pages) - Security Concerns with IP Tunneling [draft-ietf-v6ops-tunnel-security-concerns-04] (20 pages) - Unintended Operational Issues With ULA [draft-ietf-v6ops-ula-02] (8 pages) - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-considerations-02] (13 pages) - Considerations For Using Unique Local Addresses [draft-ietf-v6ops-ula-usage-recommendations-05] (16 pages) - Unique IPv6 Prefix per Host [draft-ietf-v6ops-unique-ipv6-prefix-per-host-13] (10 pages) - Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks [draft-ietf-v6ops-unmaneval-03] (19 pages) - Unmanaged Networks IPv6 Transition Scenarios [draft-ietf-v6ops-unman-scenarios-03] (20 pages) - Framework for IP Version Transition Scenarios [draft-ietf-v6ops-v4v6tran-framework-02] (7 pages) - Local-Use IPv4/IPv6 Translation Prefix [draft-ietf-v6ops-v4v6-xlat-prefix-02] (7 pages) - Considerations for Transitioning Content to IPv6 [draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11] (27 pages) - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-09] (10 pages) - Mobile Networks Considerations for IPv6 Deployment [draft-ietf-v6ops-v6-in-mobile-networks-05] (17 pages) - Operational Neighbor Discovery Problems [draft-ietf-v6ops-v6nd-problems-05] (12 pages) - Issues with Dual Stack IPv6 on by Default [draft-ietf-v6ops-v6onbydefault-03] (14 pages) - Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks [draft-ietf-v6ops-vlan-usage-01] (11 pages) - Wireline Incremental IPv6 [draft-ietf-v6ops-wireline-incremental-ipv6-06] (29 pages) - Neighbor Cache Entries on First-Hop Routers: Operational Considerations [draft-linkova-v6ops-nd-cache-init-01] (13 pages) - Pros and Cons of IPv6 Transition Technologies for IPv4aaS [draft-lmhp-v6ops-transition-comparison-06] (28 pages) - 464XLAT Optimization [draft-palet-v6ops-464xlat-opt-cdn-caches-04] (17 pages) - IPv6 Deployment Status [draft-vf-v6ops-ipv6-deployment-02] (30 pages) Requests for Comments: BCP157: IPv6 Address Assignment to End Sites (9 pages) BCP196: Deprecating the Anycast Prefix for 6to4 Relay Routers (10 pages) BCP198: IPv6 Prefix Length Recommendation for Forwarding (6 pages) BCP202: Reducing Energy Consumption of Router Advertisements (6 pages) BCP204: Host Address Availability Recommendations (15 pages) BCP234: Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events (11 pages) RFC3574: Transition Scenarios for 3GPP Networks (12 pages) RFC3750: Unmanaged Networks IPv6 Transition Scenarios (20 pages) RFC3789: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents (10 pages) RFC3790: Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents (49 pages) RFC3791: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents (15 pages) RFC3792: Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents (25 pages) RFC3793: Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents (6 pages) RFC3794: Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents (31 pages) RFC3795: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents (50 pages) RFC3796: Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents (43 pages) RFC3904: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks (19 pages) RFC3964: Security Considerations for 6to4 (41 pages) RFC4029: Scenarios and Analysis for Introducing IPv6 into ISP Networks (28 pages) RFC4038: Application Aspects of IPv6 Transition (33 pages) RFC4057: IPv6 Enterprise Network Scenarios (17 pages) RFC4192: Procedures for Renumbering an IPv6 Network without a Flag Day (22 pages) RFC4213: Basic Transition Mechanisms for IPv6 Hosts and Routers (27 pages) RFC4215: Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks (24 pages) RFC4554: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (11 pages) RFC4779: ISP IPv6 Deployment Scenarios in Broadband Access Networks (81 pages) RFC4852: IPv6 Enterprise Network Analysis - IP Layer 3 Focus (32 pages) RFC4864: Local Network Protection for IPv6 (36 pages) RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls (38 pages) RFC4891: Using IPsec to Secure IPv6-in-IPv4 Tunnels (23 pages) RFC4942: IPv6 Transition/Co-existence Security Considerations (41 pages) RFC4943: IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (8 pages) RFC4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status (25 pages) RFC5156: Special-Use IPv6 Addresses (7 pages) * Obsoletes RFC6890 RFC5157: IPv6 Implications for Network Scanning (13 pages) * Obsoletes RFC7707 RFC5181: IPv6 Deployment Scenarios in 802.16 Networks (16 pages) RFC5220: Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules (17 pages) RFC5221: Requirements for Address Selection Mechanisms (7 pages) RFC5375: IPv6 Unicast Address Assignment Considerations (35 pages) RFC5963: IPv6 Deployment in Internet Exchange Points (IXPs) (10 pages) RFC6036: Emerging Service Provider Scenarios for IPv6 Deployment (23 pages) * Obsoletes RFC9386 RFC6092: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (36 pages) RFC6104: Rogue IPv6 Router Advertisement Problem Statement (16 pages) RFC6105: IPv6 Router Advertisement Guard (10 pages) * Updates RFC7113 RFC6169: Security Concerns with IP Tunneling (20 pages) RFC6177: IPv6 Address Assignment to End Sites (9 pages) RFC6204: Basic Requirements for IPv6 Customer Edge Routers (17 pages) * Obsoletes RFC7084 RFC6264: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (13 pages) RFC6312: Mobile Networks Considerations for IPv6 Deployment (17 pages) * Obsoletes RFC6342 RFC6324: Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (19 pages) RFC6342: Mobile Networks Considerations for IPv6 Deployment (17 pages) RFC6343: Advisory Guidelines for 6to4 Deployment (20 pages) RFC6459: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) (36 pages) RFC6555: Happy Eyeballs: Success with Dual-Stack Hosts (15 pages) * Obsoletes RFC8305 RFC6583: Operational Neighbor Discovery Problems (12 pages) RFC6589: Considerations for Transitioning Content to IPv6 (27 pages) RFC6666: A Discard Prefix for IPv6 (6 pages) RFC6782: Wireline Incremental IPv6 (29 pages) RFC6791: Stateless Source Address Mapping for ICMPv6 Packets (6 pages) RFC6877: 464XLAT: Combination of Stateful and Stateless Translation (14 pages) RFC6883: IPv6 Guidance for Internet Content Providers and Application Service Providers (24 pages) RFC7066: IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts (20 pages) RFC7084: Basic Requirements for IPv6 Customer Edge Routers (21 pages) * Updates RFC9096 RFC7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) (13 pages) RFC7157: IPv6 Multihoming without Network Address Translation (22 pages) RFC7269: NAT64 Deployment Options and Experience (22 pages) RFC7278: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link (10 pages) RFC7335: IPv4 Service Continuity Prefix (4 pages) RFC7381: Enterprise IPv6 Deployment Guidelines (34 pages) RFC7445: Analysis of Failure Cases in IPv6 Roaming Scenarios (19 pages) RFC7526: Deprecating the Anycast Prefix for 6to4 Relay Routers (10 pages) RFC7608: IPv6 Prefix Length Recommendation for Forwarding (6 pages) RFC7690: Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) (9 pages) RFC7755: SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments (24 pages) RFC7756: Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode (17 pages) RFC7757: Explicit Address Mappings for Stateless IP/ICMP Translation (19 pages) RFC7772: Reducing Energy Consumption of Router Advertisements (6 pages) RFC7872: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (15 pages) RFC7934: Host Address Availability Recommendations (15 pages) RFC8215: Local-Use IPv4/IPv6 Translation Prefix (7 pages) RFC8273: Unique IPv6 Prefix per Host (10 pages) RFC8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency (15 pages) RFC8475: Using Conditional Router Advertisements for Enterprise Multihoming (21 pages) RFC8585: Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service (21 pages) RFC8683: Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks (38 pages) RFC8978: Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events (11 pages) RFC9096: Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events (11 pages) RFC9098: Operational Implications of IPv6 Packets with Extension Headers (17 pages) RFC9313: Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) (27 pages) RFC9386: IPv6 Deployment Status (37 pages) MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2023-03-24 Current Status: Active Chairs: Greg Shepherd Lenny Giuliano Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Tech Advisor: Scott Bradner Mailing Lists: General Discussion: mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: https://mailarchive.ietf.org/arch/browse/mboned/ Description of Working Group: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet, inter-domain and single domain. This activity will include, but not be limited to: - Document deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Analyze the need for IPv4 - IPv6 multicast transition solutions - Develop tools, extend protocols and provide operational and implementation advice that assists in multicast administration, diagnostics, troubleshooting and deployment between/within native and non-native environments. - Development of routing and group membership protocols is out of scope. This working group may develop requirements and assist in review and feedback of documents in other working groups responsible for such protocols. Goals and Milestones: Jan 2014 - Submit Mtracev2 to IESG for Proposed Standards Mar 2014 - Work with TSV area to submit multicast transport guidelines for congestion control Mar 2014 - Submit Overview of Multicast in the Data Center to IESG for Informational Internet-Drafts: - IPv6 Multicast Address With Embedded IPv4 Multicast Address [draft-ietf-mboned-64-multicast-address-format-06] (12 pages) - Overview of the Internet Multicast Addressing Architecture [draft-ietf-mboned-addrarch-07] (14 pages) - Lightweight Multicast Address Discovery Problem Space [draft-ietf-mboned-addrdisc-problems-02] (11 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-admin-ip-space-05] (8 pages) - Asymmetric Manifest Based Integrity [draft-ietf-mboned-ambi-03] (29 pages) - Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) [draft-ietf-mboned-anycast-rp-08] (7 pages) - Automatic Multicast Tunneling [draft-ietf-mboned-auto-multicast-18] (82 pages) - Circuit Breaker Assisted Congestion Control [draft-ietf-mboned-cbacc-04] (20 pages) - Multicast in the Data Center Overview [draft-ietf-mboned-dc-deploy-09] (18 pages) - Deprecating Any-Source Multicast (ASM) for Interdomain Multicast [draft-ietf-mboned-deprecate-interdomain-asm-07] (14 pages) - Discovery Of Restconf Metadata for Source-specific multicast [draft-ietf-mboned-dorms-04] (26 pages) - DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery [draft-ietf-mboned-driad-amt-discovery-13] (33 pages) - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [draft-ietf-mboned-embeddedrp-07] (18 pages) - Multicast Geo-Distribution Control [draft-ietf-mboned-geo-distribution-control-00] (8 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-addressing-02] (5 pages) - Extended Assignments in 233/8 [draft-ietf-mboned-glop-extensions-02] (4 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-update-01] (5 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-iana-ipv4-mcast-guidelines-04] (8 pages) - Multicast Considerations over IEEE 802 Wireless Media [draft-ietf-mboned-ieee802-mcast-problems-15] (22 pages) - Internet Multicast Gap Analysis from the MBONED Working Group for the IESG [draft-ietf-mboned-iesg-gap-analysis-00] (14 pages) - Some Issues for an Inter-domain Multicast Routing Protocol [draft-ietf-mboned-imrp-some-issues-03] (12 pages) - Use of Multicast across Inter-domain Peering Points [draft-ietf-mboned-interdomain-peering-bcp-14] (44 pages) - Introduction to IP Multicast Routing [draft-ietf-mboned-intro-multicast-03] (60 pages) - IP Multicast MIB [draft-ietf-mboned-ip-mcast-mib-07] (59 pages) - Requirements for IP multicast performance monitoring [draft-ietf-mboned-ip-multicast-pm-requirement-01] (15 pages) - IPv4 Multicast Best Current Practice [draft-ietf-mboned-ipv4-mcast-bcp-01] (12 pages) - IPv4 Multicast Unusable Group And Source Addresses [draft-ietf-mboned-ipv4-mcast-unusable-01] (7 pages) - Unicast-Prefix-Based IPv4 Multicast Addresses [draft-ietf-mboned-ipv4-uni-based-mcast-06] (5 pages) - IPv6 Multicast Deployment Issues [draft-ietf-mboned-ipv6-multicast-issues-02] (12 pages) - Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols [draft-ietf-mboned-lightweight-igmpv3-mldv2-06] (17 pages) - Guidelines for Rate Limits on the MBONE [draft-ietf-mboned-limit-rate-guide-00] (3 pages) - Using MSDP to create Logical RPs [draft-ietf-mboned-logical-rp-00] (7 pages) - Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) [draft-ietf-mboned-maccnt-req-10] (18 pages) - Multicast Addresses for Documentation [draft-ietf-mboned-mcaddrdoc-04] (7 pages) - IP Multicast Applications: Challenges and Solutions [draft-ietf-mboned-mcast-apps-02] (28 pages) - Moving MCAST.NET into the ARPA infrastructure top level domain [draft-ietf-mboned-mcast-arpa-03] (9 pages) - Connecting Multicast Domains [draft-ietf-mboned-mcast-connect-00] (14 pages) - IP Multicast and Firewalls [draft-ietf-mboned-mcast-firewall-02] (12 pages) - Multicast Debugging Handbook [draft-ietf-mboned-mdh-05] (34 pages) - Multicast-Friendly Internet Exchange (MIX) [draft-ietf-mboned-mix-01] (10 pages) - Multicast Network Address Translation [draft-ietf-mboned-mnat-01] (23 pages) - Multicast Reachability Monitor (MRM) [draft-ietf-mboned-mrm-01] (22 pages) - Justification for and use of the Multicast Routing Monitor (MRM) Protocol [draft-ietf-mboned-mrm-use-00] (9 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements [draft-ietf-mboned-mroutesec-04] (23 pages) - Multicast Source Discovery Protocol (MSDP) Deployment Scenarios [draft-ietf-mboned-msdp-deploy-06] (14 pages) - Multicast Source Discovery Protocol (MSDP) MIB [draft-ietf-mboned-msdp-mib-01] (32 pages) - Mtrace Version 2: Traceroute Facility for IP Multicast [draft-ietf-mboned-mtrace-v2-26] (41 pages) - AAA and Admission Control Framework for Multicasting [draft-ietf-mboned-multiaaa-framework-12] (22 pages) - Multicast On-path Telemetry using IOAM [draft-ietf-mboned-multicast-telemetry-06] (14 pages) - Multicast YANG Data Model [draft-ietf-mboned-multicast-yang-model-08] (42 pages) - Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions [draft-ietf-mboned-multrans-addr-acquisition-07] (10 pages) - Multicast-Scope Zone Announcement Protocol (MZAP) [draft-ietf-mboned-mzap-06] (27 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-oops-disregard-00] (6 pages) - PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone [draft-ietf-mboned-pmbr-spec-00] (8 pages) - Multicast pruning a necessity [draft-ietf-mboned-pruning-02] (3 pages) - Issues Related to Receiver Access Control in the Current Multicast Protocols [draft-ietf-mboned-rac-issues-03] (24 pages) - Multicast Redundant Ingress Router Failover [draft-ietf-mboned-redundant-ingress-failover-02] (14 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171bis-08] (11 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171-update-00] (9 pages) - Overview of the Internet Multicast Routing Architecture [draft-ietf-mboned-routingarch-12] (25 pages) - Scoped Address Discovery Protocol (SADP) [draft-ietf-mboned-sadp-02] (14 pages) - Requirements for IP Multicast Session Announcement [draft-ietf-mboned-session-announcement-req-03] (14 pages) - The Use of SNTP as a Multicast Heartbeat [draft-ietf-mboned-sntp-heart-00] (8 pages) - Source-Specific Protocol Independent Multicast in 232/8 [draft-ietf-mboned-ssm232-09] (7 pages) - Multicast Ping Protocol [draft-ietf-mboned-ssmping-09] (24 pages) - Static Allocations in 233/8 [draft-ietf-mboned-static-allocation-00] (5 pages) - IPv4-IPv6 Multicast: Problem Statement and Use Cases [draft-ietf-mboned-v4v6-mcast-ps-04] (20 pages) - Asymmetric Manifest Based Integrity [draft-jholland-mboned-ambi-05] (22 pages) - Circuit Breaker Assisted Congestion Control [draft-jholland-mboned-cbacc-01] (15 pages) - Discovery Of Restconf Metadata for Source-specific multicast [draft-jholland-mboned-dorms-02] (17 pages) - Multicasting Applications Across Inter-Domain Peering Points [draft-tarapore-mboned-multicast-cdni-07] (27 pages) Requests for Comments: BCP120: Source-Specific Protocol Independent Multicast in 232/8 (7 pages) BCP121: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (14 pages) BCP213: Use of Multicast across Inter-domain Peering Points (44 pages) BCP229: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast (14 pages) BCP23: Administratively Scoped IP Multicast (8 pages) BCP51: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) BCP53: GLOP Addressing in 233/8 (5 pages) RFC2365: Administratively Scoped IP Multicast (8 pages) RFC2588: IP Multicast and Firewalls (12 pages) RFC2770: GLOP Addressing in 233/8 (5 pages) * Obsoletes RFC3180 RFC2776: Multicast-Scope Zone Announcement Protocol (MZAP) (27 pages) RFC3138: Extended Assignments in 233/8 (4 pages) * Obsoletes RFC5771 RFC3170: IP Multicast Applications: Challenges and Solutions (28 pages) RFC3171: IANA Guidelines for IPv4 Multicast Address Assignments (8 pages) * Obsoletes RFC5771 RFC3180: GLOP Addressing in 233/8 (5 pages) RFC3446: Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) (7 pages) RFC3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (18 pages) * Updates RFC7371 RFC4608: Source-Specific Protocol Independent Multicast in 232/8 (7 pages) RFC4609: Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements (23 pages) RFC4611: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (14 pages) RFC4624: Multicast Source Discovery Protocol (MSDP) MIB (32 pages) RFC5110: Overview of the Internet Multicast Routing Architecture (25 pages) RFC5132: IP Multicast MIB (59 pages) RFC5771: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) RFC5790: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols (17 pages) RFC6034: Unicast-Prefix-Based IPv4 Multicast Addresses (5 pages) RFC6308: Overview of the Internet Multicast Addressing Architecture (14 pages) RFC6450: Multicast Ping Protocol (24 pages) RFC6676: Multicast Addresses for Documentation (7 pages) RFC7450: Automatic Multicast Tunneling (82 pages) * Updates RFC8777 RFC8313: Use of Multicast across Inter-domain Peering Points (44 pages) RFC8487: Mtrace Version 2: Traceroute Facility for IP Multicast (41 pages) RFC8777: DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery (33 pages) RFC8815: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast (14 pages) RFC9119: Multicast Considerations over IEEE 802 Wireless Media (22 pages) Media OPerationS (mops) ----------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Kyle Rose Leslie Daigle Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Éric Vyncke Tech Advisors: Glenn Deen Warren Kumari Mailing Lists: General Discussion: mops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mops Archive: https://mailarchive.ietf.org/arch/browse/mops/ Description of Working Group: Internet-wide and within-domain IP-delivered media is widespread, leading to significant technology development across industries not traditionally thought of as Internet technology developers or operators, as well as considerable quantities of traffic on local and transit networks. The focus of MOPS is on identifying areas where existing protocols and/or networks are challenged by updated requirements. MOPS will solicit input on media-related operational issues and practices; existing and proposed technologies related to the deployment, engineering, and operation of media streaming and manipulation protocols and procedures in the global Internet (inter-domain) and within-domain networking. In the context of this working group, media is considered to include the transport of video, audio, objects and any combination thereof, possibly non-sequentially. The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats. MOPS provides a venue for both video industry and Internet engineering experts to engage in discussion of video technology’s requirements of networking standards, as well as proposals for new uses of IP technology in video. Where new protocols are needed, MOPS will help identify candidate venues for their development. The goals of MOPS include documenting existing protocol and operational issues with media on the Internet, and identifying requirements for potential IETF work. The general process of elaboration through documentation will be for issues to be identified (on the mailing list) and presentations made at WG meetings. When topics merit more coherent documentation, MOPS will adopt working group documents to capture the information in Internet-Drafts. If the working group consensus is that the material of the Internet-Draft is generally useful for archival purposes, the WG will seek publication of the work items as RFCs. At any point — from early discussion of topics, through later documentation stages — MOPS may identify a more appropriate WG for the matter and/or document, and dispatch it. With that in mind, MOPS will: 1/ Solicit regular updates from other media technology developing consortia/standards bodies working with IETF-developed protocols. 2/ Solicit input from network operators and users to identify operational issues with media delivery in and across networks, and determine solutions or workarounds to those issues. 3/ Solicit discussion and documentation of the issues and opportunities in media acquisition and delivery, and of the resulting protocols and technologies developed outside the IETF. 4/ Document operational requirements for media acquisition (for example, from cameras and recording devices) and delivery. 5/ Develop operational information to aid in operation of media technologies in the global Internet. These activities should document media operational experience, including global Internet, inter-domain and within-domain operations. In all cases of working with other organizations mentioned above, MOPS will work with existing liaison managers where the IETF has them, and informal connections with other organizations otherwise. If new formal liaison relationships are required, MOPS will work with the IAB to help establish them. Media operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) remain the responsibility of the groups or areas responsible for those protocols or technologies. However, the MOPS Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to MOPS operational and deployment problems. There must be a continuing expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. The IESG is establishing this working group on an experimental basis and intends to review it, for rechartering to continue or else closure, in 2 years. Goals and Milestones: Jul 2022 - Draft documenting Streaming Video Alliance (SVA) reliance on IETF protocols Nov 2022 - Last-call document on operational considerations for low latency streaming video applications Nov 2022 - Last-call document on Streaming Video Alliance (SVA) reliance on IETF protocols (including explicit outreach to SVA) Done - Draft of edge network operational considerations for streaming media Done - Revised draft of edge network operational considerations for streaming media Done - Develop work items specific to media acquisition and delivery Done - Initial draft operational considerations for low latency streaming video applications Done - IESG to decide whether continue, re-charter or close MOPS WG Done - Revised draft operational considerations for low latency streaming video applications Internet-Drafts: - Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure [draft-ietf-mops-ar-use-case-11] (17 pages) - Operational Considerations for Streaming Media [draft-ietf-mops-streaming-opcons-12] (37 pages) - TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences [draft-ietf-mops-treedn-00] (10 pages) Requests for Comments: RFC9317: Operational Considerations for Streaming Media (37 pages) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2023-03-26 Current Status: Active Chairs: Kent Watsen Mahesh Jethanandani Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Secretary: Per Andersson Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: https://mailarchive.ietf.org/arch/browse/netconf/ Description of Working Group: The NETCONF Working Group, previously named after the NETCONF protocol, now renamed as the NETwork CONFiguration Working Group, is responsible for the development and maintenance of protocols such as NETCONF and RESTCONF for YANG data model-driven management (for the purposes of, for example, configuration, monitoring, telemetry, and zero-touch), their transports and encodings, defining data models necessary to support the protocols, and defining mechanisms supporting the operational deployment of systems using the protocols. The NETCONF protocol is data modeling language independent, but YANG (RFC 7950) is the recommended NETCONF data modeling language, which introduces advanced language features for configuration management. The NETCONF WG is currently responsible for: a) The network management protocol NETCONF (RFC 6241). This effort entails periodically updating the NETCONF related specifications to address new requirements as they arise. b) The network management protocol RESTCONF (RFC 8040). This effort entails periodically updating the RESTCONF related specifications to address new requirements as they arise. c) The transports and encodings used by the data model-driven protocols. d) The data models and mechanisms related to network management protocols. Specifically, data models enabling the configuration and/or monitoring of the protocols themselves. Other examples include data models for configuring access controls or discovering server metadata. e) The data models for subscriptions to data, and protocol bindings for pushing subscribed data to clients, for the purpose of monitoring and telemetry. f) The mechanisms enabling devices zero-touch provisioning and the related call home functions. The NETCONF working group consults with the NETMOD working group to ensure that new requirements are understood and can be met by the YANG data modeling language (RFC 7950) developed within that working group. Goals and Milestones: Sep 2018 - WGLC for YANG Notification Headers and Bundles Sep 2018 - WGLC for advanced Notification/Subscription Specifications Sep 2018 - WGLC for YANG Push Sep 2018 - WGLC for RESTCONF and HTTP Transport for Event Notifications Sep 2018 - WGLC for NETCONF Support for Event Notifications Dec 2018 - Submit draft-ietf-netconf-udp-pub-channel to IESG for publication (as Standards Track) Dec 2018 - WGLC for System-level Keystore Mechanism Dec 2018 - WGLC for Server and Client Configuration Models for NETCONF and RESTCONF Dec 2018 - WGLC for Client and Server Configuration Models for SSH and TLS Done - WGLC for NMDA RESTCONF Done - WGLC for YANG Library bis (as Standards Track) Done - WGLC for NMDA NETCONF Done - WGLC for Zero-touch Configuration Mechanism Internet-Drafts: - RESTCONF Update to Support the NMDA [draft-dsdt-netconf-restconf-nmda-00] (6 pages) - NETCONF Model for NMDA [draft-dsdt-nmda-netconf-01] (13 pages) - Network Configuration Protocol (NETCONF) [draft-ietf-netconf-4741bis-10] (113 pages) - Network Configuration Protocol (NETCONF) Access Control Model [draft-ietf-netconf-access-control-07] (49 pages) - Adaptive Subscription to YANG Notification [draft-ietf-netconf-adaptive-subscription-02] (32 pages) - Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [draft-ietf-netconf-beep-10] (10 pages) - NETCONF Call Home and RESTCONF Call Home [draft-ietf-netconf-call-home-17] (13 pages) - YANG Data Types and Groupings for Cryptography [draft-ietf-netconf-crypto-types-27] (63 pages) - Subscription to Distributed Notifications [draft-ietf-netconf-distributed-notif-06] (20 pages) - YANG Groupings for HTTP 1.1/2.0 Clients and HTTP Servers [draft-ietf-netconf-http-client-server-13] (33 pages) - An HTTPS-based Transport for YANG Notifications [draft-ietf-netconf-https-notif-13] (27 pages) - A YANG Data Model for a Keystore [draft-ietf-netconf-keystore-28] (53 pages) - List Pagination for YANG-driven Protocols [draft-ietf-netconf-list-pagination-01] (58 pages) - NETCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-nc-01] (12 pages) - RESTCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-rc-01] (13 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (28 pages) - NETCONF Client and Server Models [draft-ietf-netconf-netconf-client-server-29] (63 pages) - Dynamic Subscription to YANG Events and Datastores over NETCONF [draft-ietf-netconf-netconf-event-notifications-22] (19 pages) - NETCONF Extensions to Support the Network Management Datastore Architecture [draft-ietf-netconf-nmda-netconf-08] (23 pages) - RESTCONF Extensions to Support the Network Management Datastore Architecture [draft-ietf-netconf-nmda-restconf-05] (9 pages) - NETCONF Event Notifications [draft-ietf-netconf-notification-14] (35 pages) - YANG Modules Describing Capabilities for Systems and Datastore Update Notifications [draft-ietf-netconf-notification-capabilities-21] (22 pages) - Notification Message Headers and Bundles [draft-ietf-netconf-notification-messages-08] (23 pages) - Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication [draft-ietf-netconf-over-tls13-02] (6 pages) - Partial Lock Remote Procedure Call (RPC) for NETCONF [draft-ietf-netconf-partial-lock-11] (23 pages) - NETCONF Configuration Protocol [draft-ietf-netconf-prot-12] (95 pages) - RESTCONF Protocol [draft-ietf-netconf-restconf-18] (137 pages) - RESTCONF Client and Server Models [draft-ietf-netconf-restconf-client-server-29] (58 pages) - RESTCONF Collection Resource [draft-ietf-netconf-restconf-collection-00] (17 pages) - Dynamic Subscription to YANG Events and Datastores over RESTCONF [draft-ietf-netconf-restconf-notif-15] (23 pages) - NETCONF Call Home using SSH [draft-ietf-netconf-reverse-ssh-06] (11 pages) - Using the NETCONF Protocol over Secure Shell (SSH) [draft-ietf-netconf-rfc4742bis-08] (11 pages) - RFC4743 and RFC4744 to Historic status [draft-ietf-netconf-rfc4743-rfc4744-to-historic-00] (4 pages) - Subscribing to Event Notifications [draft-ietf-netconf-rfc5277bis-01] (46 pages) - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication [draft-ietf-netconf-rfc5539bis-10] (11 pages) - Network Configuration Access Control Model [draft-ietf-netconf-rfc6536bis-09] (58 pages) - YANG Library [draft-ietf-netconf-rfc7895bis-07] (32 pages) - NETCONF Server and RESTCONF Server Configuration Models [draft-ietf-netconf-server-model-09] (74 pages) - Using NETCONF over the Simple Object Access Protocol (SOAP) [draft-ietf-netconf-soap-08] (20 pages) - Using the NETCONF Configuration Protocol over Secure SHell (SSH) [draft-ietf-netconf-ssh-06] (10 pages) - YANG Groupings for SSH Clients and SSH Servers [draft-ietf-netconf-ssh-client-server-33] (143 pages) - Subscription to YANG Notifications [draft-ietf-netconf-subscribed-notifications-26] (77 pages) - System Keychain Model [draft-ietf-netconf-system-keychain-00] (33 pages) - Network Configuration Protocol (NETCONF) Base Notifications [draft-ietf-netconf-system-notifications-07] (15 pages) - Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request [draft-ietf-netconf-sztp-csr-14] (36 pages) - YANG Groupings for TCP Clients and TCP Servers [draft-ietf-netconf-tcp-client-server-16] (34 pages) - NETCONF over Transport Layer Security (TLS) [draft-ietf-netconf-tls-07] (7 pages) - YANG Groupings for TLS Clients and TLS Servers [draft-ietf-netconf-tls-client-server-33] (155 pages) - Transaction ID Mechanism for NETCONF [draft-ietf-netconf-transaction-id-00] (56 pages) - A YANG Data Model for a Truststore [draft-ietf-netconf-trust-anchors-21] (39 pages) - UDP-based Transport for Configured Subscriptions [draft-ietf-netconf-udp-notif-09] (30 pages) - UDP based Publication Channel for Streaming Telemetry [draft-ietf-netconf-udp-pub-channel-05] (21 pages) - With-defaults Capability for NETCONF [draft-ietf-netconf-with-defaults-14] (26 pages) - YANG Module Library [draft-ietf-netconf-yang-library-06] (13 pages) - YANG Patch Media Type [draft-ietf-netconf-yang-patch-14] (39 pages) - Subscription to YANG Notifications for Datastore Updates [draft-ietf-netconf-yang-push-25] (58 pages) - Secure Zero Touch Provisioning (SZTP) [draft-ietf-netconf-zerotouch-29] (87 pages) - YANG Library [draft-nmdsdt-netconf-rfc7895bis-01] (23 pages) Requests for Comments: RFC4741: NETCONF Configuration Protocol (95 pages) * Obsoletes RFC6241 RFC4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) (10 pages) * Obsoletes RFC6242 RFC4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (20 pages) * Updates RFC8996 RFC4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (10 pages) * Updates RFC8996 RFC5277: NETCONF Event Notifications (35 pages) RFC5539: NETCONF over Transport Layer Security (TLS) (7 pages) * Obsoletes RFC7589 RFC5717: Partial Lock Remote Procedure Call (RPC) for NETCONF (23 pages) RFC6022: YANG Module for NETCONF Monitoring (28 pages) RFC6241: Network Configuration Protocol (NETCONF) (113 pages) * Updates RFC7803 * Updates RFC8526 RFC6242: Using the NETCONF Protocol over Secure Shell (SSH) (11 pages) RFC6243: With-defaults Capability for NETCONF (26 pages) RFC6470: Network Configuration Protocol (NETCONF) Base Notifications (15 pages) RFC6536: Network Configuration Protocol (NETCONF) Access Control Model (49 pages) * Obsoletes RFC8341 RFC7589: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication (11 pages) RFC7895: YANG Module Library (13 pages) * Obsoletes RFC8525 RFC8040: RESTCONF Protocol (137 pages) * Updates RFC8527 RFC8071: NETCONF Call Home and RESTCONF Call Home (13 pages) RFC8072: YANG Patch Media Type (39 pages) RFC8341: Network Configuration Access Control Model (58 pages) RFC8525: YANG Library (32 pages) RFC8526: NETCONF Extensions to Support the Network Management Datastore Architecture (23 pages) RFC8527: RESTCONF Extensions to Support the Network Management Datastore Architecture (9 pages) RFC8572: Secure Zero Touch Provisioning (SZTP) (87 pages) RFC8639: Subscription to YANG Notifications (77 pages) RFC8640: Dynamic Subscription to YANG Events and Datastores over NETCONF (19 pages) RFC8641: Subscription to YANG Notifications for Datastore Updates (58 pages) RFC8650: Dynamic Subscription to YANG Events and Datastores over RESTCONF (23 pages) RFC9196: YANG Modules Describing Capabilities for Systems and Datastore Update Notifications (22 pages) STD91: Network Configuration Access Control Model (58 pages) Network Modeling (netmod) ------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Kent Watsen Lou Berger Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Secretary: Jason Sterne Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netmod Archive: https://mailarchive.ietf.org/arch/browse/netmod/ Description of Working Group: The Network Modeling (NETMOD) working group is responsible for the YANG data modeling language, which can be used to specify network management data models that are transported over such protocols as NETCONF and RESTCONF, and guidelines for developing YANG models. The NETMOD working group addresses general topics related to the use of the YANG language and YANG models, for example, the mapping of YANG modeled data into various encodings. Finally, the NETMOD working group also defines core YANG models used as basic YANG building blocks, and YANG models that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG may include work on YANG modules device profiles that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG is responsible for: a) Maintaining the data modeling language YANG. This effort entails periodically updating the specification to address new requirements as they arise. b) Maintaining the guidelines for developing YANG models. This effort is primarily driven by updates made to the YANG specification. c) Maintaining a conceptual framework in which YANG models are used. This effort entails describing the generic context that in YANG exists and how certain YANG statements interact in that context. An example of this is YANG's relationship with datastores. d) Maintaining encodings for YANG modeled data. This effort entails updating encodings already defined by the NETMOD working group (XML and JSON) to accommodate changes to the YANG specification, and defining new YANG encodings that are needed, and yet do not fall under the charter of any other active IETF working group. e) Maintaining YANG models used as basic YANG building blocks. This effort entails updating existing YANG models (ietf-yang-types and ietf-inet-types) as needed, as well as defining additional core YANG data models when necessary. f) Defining and maintaining YANG models that do not fall under the charter of any other active IETF working group. The NETMOD working group consults with the NETCONF working group to ensure that new requirements are understood and can be met by the protocols (e.g., NETCONF and RESTCONF) developed within that working group. The NETMOD working group does not serve as a review team for YANG modules developed by other working groups. Instead, the YANG doctors, [1] as organized by the OPS area director responsible for network management, will act as advisors for other working groups and provide YANG reviews for the OPS area directors. [1] http://www.ietf.org/iesg/directorate/yang-doctors.html Goals and Milestones: May 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG for publication (as Informational) May 2017 - Submit draft-ietf-netmod-syslog-model to IESG for publication (as Standards Track) Jul 2017 - Submit draft-ietf-netmod-rfc6087bis to IESG for publication (as Informational) Nov 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for publication (as Informational) Jan 2018 - Submit draft-ietf-netmod-acl-model to IESG for publication (as Standards Track) Jan 2018 - Submit draft-ietf-netmod-entity to IESG for publication (as Standards Track) Internet-Drafts: - YANG Data Extensions [draft-bierman-netmod-yang-data-ext-01] (10 pages) - A YANG Data Model for Interface Management [draft-bjorklund-netmod-rfc7223bis-00] (47 pages) - A YANG Data Model for IP Management [draft-bjorklund-netmod-rfc7277bis-00] (32 pages) - Extensions to the Access Control Lists (ACLs) YANG Model [draft-dbb-netmod-acl-03] (32 pages) - Extensions to the Access Control Lists (ACLs) YANG Model [draft-ietf-netmod-acl-extensions-01] (50 pages) - YANG Data Model for Network Access Control Lists (ACLs) [draft-ietf-netmod-acl-model-21] (60 pages) - An Architecture for Network Management Using NETCONF and YANG [draft-ietf-netmod-arch-10] (30 pages) - Handling Long Lines in Content of Internet-Drafts and RFCs [draft-ietf-netmod-artwork-folding-12] (28 pages) - Representing Netconf Data Models using Document Schema Definition Languages (DSDL) [draft-ietf-netmod-dsdl-00] (72 pages) - Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content [draft-ietf-netmod-dsdl-map-10] (100 pages) - A YANG Data model for ECA Policy Management [draft-ietf-netmod-eca-policy-01] (54 pages) - A YANG Data Model for Hardware Management [draft-ietf-netmod-entity-08] (60 pages) - A YANG Data Model for Factory Default Settings [draft-ietf-netmod-factory-default-15] (10 pages) - A YANG Grouping for Geographic Locations [draft-ietf-netmod-geo-location-11] (22 pages) - IANA Address Family Numbers and Subsequent Address Family Identifiers YANG Module [draft-ietf-netmod-iana-afn-safi-00] (20 pages) - IANA Interface Type YANG Module [draft-ietf-netmod-iana-if-type-10] (37 pages) - IANA Timezone Database YANG Module [draft-ietf-netmod-iana-timezones-03] (40 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-interfaces-cfg-16] (39 pages) - Common Interface Extension YANG Data Models [draft-ietf-netmod-intf-ext-yang-11] (33 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-ip-cfg-14] (30 pages) - YANG Module Tags [draft-ietf-netmod-module-tags-10] (19 pages) - Comparison of Network Management Datastore Architecture (NMDA) Datastores [draft-ietf-netmod-nmda-diff-12] (16 pages) - Node Tags in YANG Modules [draft-ietf-netmod-node-tags-09] (32 pages) - Terminology and Requirements for Enhanced Handling of Operational State [draft-ietf-netmod-opstate-reqs-04] (6 pages) - Network Management Datastore Architecture (NMDA) [draft-ietf-netmod-revised-datastores-10] (44 pages) - The YANG 1.1 Data Modeling Language [draft-ietf-netmod-rfc6020bis-14] (217 pages) - Common YANG Data Types [draft-ietf-netmod-rfc6021-bis-03] (30 pages) - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models [draft-ietf-netmod-rfc6087bis-20] (63 pages) - Common YANG Data Types [draft-ietf-netmod-rfc6991-bis-15] (43 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-rfc7223bis-03] (49 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-rfc7277bis-03] (34 pages) - A YANG Data Model for Routing Management (NMDA Version) [draft-ietf-netmod-rfc8022bis-11] (80 pages) - A YANG Data Model for Routing Management [draft-ietf-netmod-routing-cfg-25] (64 pages) - YANG Schema Mount [draft-ietf-netmod-schema-mount-12] (28 pages) - Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules [draft-ietf-netmod-smi-yang-05] (36 pages) - A YANG Data Model for SNMP Configuration [draft-ietf-netmod-snmp-cfg-08] (88 pages) - Sub-interface VLAN YANG Data Models [draft-ietf-netmod-sub-intf-vlan-model-08] (34 pages) - A YANG Data Model for Syslog Configuration [draft-ietf-netmod-syslog-model-30] (42 pages) - System-defined Configuration [draft-ietf-netmod-system-config-01] (43 pages) - A YANG Data Model for System Management [draft-ietf-netmod-system-mgmt-16] (35 pages) - YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) [draft-ietf-netmod-yang-13] (173 pages) - YANG Data Structure Extensions [draft-ietf-netmod-yang-data-ext-05] (16 pages) - A File Format for YANG Instance Data [draft-ietf-netmod-yang-instance-file-format-21] (24 pages) - JSON Encoding of Data Modeled with YANG [draft-ietf-netmod-yang-json-10] (20 pages) - Defining and Using Metadata with YANG [draft-ietf-netmod-yang-metadata-07] (21 pages) - YANG Module Classification [draft-ietf-netmod-yang-model-classification-08] (11 pages) - Updated YANG Module Revision Handling [draft-ietf-netmod-yang-module-versioning-09] (43 pages) - YANG Packages [draft-ietf-netmod-yang-packages-03] (53 pages) - YANG Schema Comparison [draft-ietf-netmod-yang-schema-comparison-02] (24 pages) - YANG Semantic Versioning [draft-ietf-netmod-yang-semver-11] (27 pages) - YANG Versioning Solution Overview [draft-ietf-netmod-yang-solutions-01] (8 pages) - YANG Tree Diagrams [draft-ietf-netmod-yang-tree-diagrams-06] (13 pages) - Common YANG Data Types [draft-ietf-netmod-yang-types-09] (26 pages) - Guidelines for Authors and Reviewers of YANG Data Model Documents [draft-ietf-netmod-yang-usage-11] (26 pages) - YANG Schema Selection [draft-ietf-netmod-yang-ver-selection-00] (32 pages) - YANG Module Versioning Requirements [draft-ietf-netmod-yang-versioning-reqs-07] (12 pages) - Handling Long Lines in Artwork in Internet-Drafts and RFCs [draft-kwatsen-netmod-artwork-folding-08] (17 pages) - YANG Based Instance Data Files Format [draft-lengyel-netmod-yang-instance-data-05] (14 pages) - System-defined Configuration [draft-ma-netmod-with-system-05] (43 pages) - A Revised Conceptual Model for YANG Datastores [draft-nmdsdt-netmod-revised-datastores-00] (20 pages) - Catalog and registry for YANG models [draft-openconfig-netmod-model-catalog-02] (40 pages) - Self Describing Data Object Tags [draft-tao-netmod-yang-node-tags-06] (26 pages) - Sub-interface VLAN YANG Data Models [draft-wilton-netmod-intf-vlan-yang-04] (27 pages) - A YANG Data model for ECA Policy Management [draft-wwx-netmod-event-yang-10] (54 pages) Requests for Comments: BCP215: YANG Tree Diagrams (13 pages) BCP216: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (63 pages) RFC6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) (173 pages) RFC6021: Common YANG Data Types (26 pages) * Obsoletes RFC6991 RFC6087: Guidelines for Authors and Reviewers of YANG Data Model Documents (26 pages) * Obsoletes RFC8407 RFC6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content (100 pages) * Updates RFC7952 RFC6244: An Architecture for Network Management Using NETCONF and YANG (30 pages) RFC6643: Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules (36 pages) RFC6991: Common YANG Data Types (30 pages) RFC7223: A YANG Data Model for Interface Management (39 pages) * Obsoletes RFC8343 RFC7224: IANA Interface Type YANG Module (37 pages) RFC7277: A YANG Data Model for IP Management (30 pages) * Obsoletes RFC8344 RFC7317: A YANG Data Model for System Management (35 pages) RFC7407: A YANG Data Model for SNMP Configuration (88 pages) RFC7950: The YANG 1.1 Data Modeling Language (217 pages) * Updates RFC8342 * Updates RFC8526 RFC7951: JSON Encoding of Data Modeled with YANG (20 pages) RFC7952: Defining and Using Metadata with YANG (21 pages) RFC8022: A YANG Data Model for Routing Management (64 pages) * Obsoletes RFC8349 RFC8199: YANG Module Classification (11 pages) RFC8340: YANG Tree Diagrams (13 pages) * Updates RFC8791 RFC8342: Network Management Datastore Architecture (NMDA) (44 pages) RFC8343: A YANG Data Model for Interface Management (49 pages) RFC8344: A YANG Data Model for IP Management (34 pages) RFC8348: A YANG Data Model for Hardware Management (60 pages) RFC8349: A YANG Data Model for Routing Management (NMDA Version) (80 pages) RFC8407: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (63 pages) * Updates RFC8819 RFC8519: YANG Data Model for Network Access Control Lists (ACLs) (60 pages) RFC8528: YANG Schema Mount (28 pages) RFC8791: YANG Data Structure Extensions (16 pages) RFC8792: Handling Long Lines in Content of Internet-Drafts and RFCs (28 pages) RFC8808: A YANG Data Model for Factory Default Settings (10 pages) RFC8819: YANG Module Tags (19 pages) RFC9144: Comparison of Network Management Datastore Architecture (NMDA) Datastores (16 pages) RFC9179: A YANG Grouping for Geographic Locations (22 pages) RFC9195: A File Format for YANG Instance Data (24 pages) Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Jen Linkova Ron Bonica Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec Archive: https://mailarchive.ietf.org/arch/browse/opsec/ Description of Working Group: Goals: The OPSEC WG will document operational issues and best current practices with regard to network security. In particular, the working group will clarify the rationale of supporting current operational practice, addressing gaps in currently understood best practices and clarifying liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG includes the protection and secure operation of the forwarding, control and management planes. Documentation of operational issues, revision of existing operational security practices documents and proposals for new approaches to operational challenges related to network security are in scope. Method: The work will result in the publication of informational or BCP RFCs. Taxonomy or problem statement documents may provide a basis for such documents. Informational or Best Current Practices Documents For each topic addressed, the working group will produce a document that captures common practices related to secure network operation. This will be primarily based on operational experience. A document might convey: * a threat or threats to be addressed * current practices for addressing the threat * protocols, tools and technologies extant at the time of writing that are used to address the threat * the possibility that a solution does not exist within existing tools or technologies Taxonomy and Problem Statement Documents These are documents that describe the scope of particular operational security challenges or problem spaces without necessarily coming to conclusions or proposing solutions. Such a document might be the precursor to an informational or best current practices document. While the principal input of the working group is operational experience and needs, the output should be directed towards providing guidance to the operators community, other working groups that develop protocols or the protocol development community. Non-Goals: The OPSEC WG is will not write or modify protocols. New protocol work must be addressed through a working group chartered for that work, or via one of the individual submission processes. The OPSEC WG may take on documents related to the practices of using such work. Goals and Milestones: Dec 2012 - WG Adoption of 'Network Reconnaissance in IPv6 Networks' document Dec 2012 - WG Adoption of 'BGP operations and security' document Dec 2012 - WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Dec 2012 - WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Jan 2013 - WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document Jan 2013 - WG Last Call for 'Operational Security Considerations for IPv6 Networks' document Jan 2013 - WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document Jan 2013 - WG Last Call for 'Recommendations for filtering ICMP messages' document Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG Mar 2013 - Submit 'Operational Security Considerations for IPv6 Networks' document to IESG Mar 2013 - Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG Mar 2013 - WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document May 2013 - Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG Jul 2013 - WG Last Call for 'BGP operations and security' document Jul 2013 - WG Last Call for 'Network Reconnaissance in IPv6 Networks' document Jul 2013 - WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Jul 2013 - WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Sep 2013 - Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG Sep 2013 - Submit 'BGP operations and security' document to IESG Sep 2013 - Submit 'Network Reconnaissance in IPv6 Networks' document to IESG Done - First draft of Framework Document as Internet Draft Done - Complete Charter Done - First draft of Standards Survey Document as Internet Draft Done - First draft of Event Logging Capabilities Done - First draft of Packet Filtering Capabilities Done - First draft of Network Operator Current Security Practices Done - First draft of Configuration and Management Interface Capabilities Done - First draft of In-Band management capabilities Done - First draft of Out-of-Band management capabilities Done - Submit Network Operator Current Security Practices to IESG Internet-Drafts: - Implications of IPv6 Addressing on Security Operations [draft-gont-opsec-ipv6-addressing-00] (8 pages) - BGP Operations and Security [draft-ietf-opsec-bgp-security-07] (26 pages) - Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) [draft-ietf-opsec-blackhole-urpf-04] (15 pages) - Operational Security Current Practices in Internet Service Provider Environments [draft-ietf-opsec-current-practices-07] (37 pages) - DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers [draft-ietf-opsec-dhcpv6-shield-08] (12 pages) - Security Best Practices Efforts and Documents [draft-ietf-opsec-efforts-20] (41 pages) - Filtering and Rate Limiting Capabilities for IP Network Infrastructure [draft-ietf-opsec-filter-caps-09] (30 pages) - Framework for Operational Security Capabilities for IP Network Infrastructure [draft-ietf-opsec-framework-05] (29 pages) - Recommendations for filtering ICMP messages [draft-ietf-opsec-icmp-filtering-04] (58 pages) - Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-04] (11 pages) - Indicators of Compromise (IoCs) and Their Role in Attack Defence [draft-ietf-opsec-indicators-of-compromise-04] (30 pages) - Service Provider Infrastructure Security [draft-ietf-opsec-infrastructure-security-01] (17 pages) - Recommendations on Filtering of IPv4 Packets Containing IPv4 Options [draft-ietf-opsec-ip-options-filtering-07] (36 pages) - Security Assessment of the Internet Protocol Version 4 [draft-ietf-opsec-ip-security-07] (75 pages) - Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers [draft-ietf-opsec-ipv6-eh-filtering-10] (33 pages) - Network Reconnaissance in IPv6 Networks [draft-ietf-opsec-ipv6-host-scanning-08] (38 pages) - Security Implications of IPv6 on IPv4 Networks [draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07] (19 pages) - Security Assessment of Neighbor Discovery (ND) for IPv6 [draft-ietf-opsec-ipv6-nd-security-00] (62 pages) - Using Only Link-Local Addressing inside an IPv6 Network [draft-ietf-opsec-lla-only-11] (10 pages) - Logging Capabilities for IP Network Infrastructure [draft-ietf-opsec-logging-caps-04] (35 pages) - Miscellaneous Capabilities for IP Network Infrastructure [draft-ietf-opsec-misc-cap-00] (21 pages) - Network Management Access Security Capabilities [draft-ietf-opsec-nmasc-00] (13 pages) - Impact of TLS 1.3 to Operational Network Security Practices [draft-ietf-opsec-ns-impact-04] (18 pages) - Attribution of Internet Probes [draft-ietf-opsec-probe-attribution-05] (10 pages) - Protecting the Router Control Plane [draft-ietf-opsec-protect-control-plane-06] (25 pages) - Routing Control Plane Security Capabilities [draft-ietf-opsec-routing-capabilities-03] (20 pages) - Issues with Existing Cryptographic Protection Methods for Routing Protocols [draft-ietf-opsec-routing-protocols-crypto-issues-07] (21 pages) - Enhanced Feasible-Path Unicast Reverse Path Forwarding [draft-ietf-opsec-urpf-improvements-04] (17 pages) - Operational Security Considerations for IPv6 Networks [draft-ietf-opsec-v6-27] (48 pages) - Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks [draft-ietf-opsec-vpn-leakages-06] (12 pages) - Enhanced Feasible-Path Unicast Reverse Path Filtering [draft-sriram-opsec-urpf-improvements-03] (15 pages) - Attribution of Internet Probes [draft-vyncke-opsec-probe-attribution-01] (8 pages) Requests for Comments: BCP186: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages) BCP194: BGP Operations and Security (26 pages) BCP199: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages) RFC4778: Operational Security Current Practices in Internet Service Provider Environments (37 pages) RFC5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) (15 pages) RFC6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols (21 pages) RFC6094: Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols (11 pages) RFC6192: Protecting the Router Control Plane (25 pages) RFC6274: Security Assessment of the Internet Protocol Version 4 (75 pages) RFC7123: Security Implications of IPv6 on IPv4 Networks (19 pages) RFC7126: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages) RFC7359: Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks (12 pages) RFC7404: Using Only Link-Local Addressing inside an IPv6 Network (10 pages) RFC7454: BGP Operations and Security (26 pages) RFC7610: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages) RFC7707: Network Reconnaissance in IPv6 Networks (38 pages) RFC8704: Enhanced Feasible-Path Unicast Reverse Path Forwarding (17 pages) RFC9099: Operational Security Considerations for IPv6 Networks (48 pages) RFC9288: Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers (33 pages) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Henk Birkholz Joe Clarke Tianran Zhou Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: https://mailarchive.ietf.org/arch/browse/opsawg/ Description of 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. Goals and Milestones: Oct 2012 - Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft Mar 2013 - Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational Done - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft Done - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft Done - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft Done - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft Done - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard Done - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft 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 'Structured Data Elements (SDEs) for syslog' Done - Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard Done - Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft Done - Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard Internet-Drafts: - Layer 3 VPN Network Model [draft-aguado-opsawg-l3sm-l3nm-02] (96 pages) - On Firewalls in Internet Security [draft-baker-opsawg-firewalls-00] (12 pages) - RADIUS Extensions for DHCP Configured Services [draft-ietf-opsawg-add-encrypted-dns-12] (19 pages) - Survey of Possibilities for the Automated Configuration of Large IP Networks [draft-ietf-opsawg-automated-network-configuration-05] (23 pages) - Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-alt-tunnel-12] (29 pages) - CAPWAP Extension for 802.11n and Power/channel Autoconfiguration [draft-ietf-opsawg-capwap-extension-06] (17 pages) - IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-hybridmac-08] (13 pages) - Management of Networks with Constrained Devices: Problem Statement and Requirements [draft-ietf-opsawg-coman-probstate-reqs-05] (44 pages) - Management of Networks with Constrained Devices: Use Cases [draft-ietf-opsawg-coman-use-cases-05] (26 pages) - A Template for Internet Drafts Containing Data Models [draft-ietf-opsawg-data-model-doc-template-00] (24 pages) - Finding and Using Geofeed Data [draft-ietf-opsawg-finding-geofeeds-17] (21 pages) - On Firewalls in Internet Security [draft-ietf-opsawg-firewalls-01] (10 pages) - HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-06] (14 pages) - HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05] (14 pages) - Export of BGP Community Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-bgp-community-12] (18 pages) - Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-mpls-sr-label-type-11] (5 pages) - Export of On-Path Delay in IPFIX [draft-ietf-opsawg-ipfix-on-path-telemetry-02] (23 pages) - Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-srv6-srh-14] (28 pages) - A YANG Network Data Model for Layer 2 VPNs [draft-ietf-opsawg-l2nm-19] (139 pages) - A YANG Network Data Model for Layer 3 VPNs [draft-ietf-opsawg-l3sm-l3nm-18] (129 pages) - Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks [draft-ietf-opsawg-large-flow-load-balancing-15] (29 pages) - Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs [draft-ietf-opsawg-lsn-deployment-06] (20 pages) - An Overview of the IETF Network Management Standards [draft-ietf-opsawg-management-stds-07] (85 pages) - Textual Conventions for the Representation of Floating-Point Numbers [draft-ietf-opsawg-mib-floats-02] (7 pages) - MIB Transfer from the IETF to the IEEE 802.3 WG [draft-ietf-opsawg-mibs-to-ieee80231-01] (7 pages) - A Framework for Automating Service and Network Management with YANG [draft-ietf-opsawg-model-automation-framework-10] (40 pages) - Guidelines for the Use of the "OAM" Acronym in the IETF [draft-ietf-opsawg-mpls-tp-oam-def-10] (9 pages) - Manufacturer Usage Description Specification [draft-ietf-opsawg-mud-25] (60 pages) - Authorized update to MUD URLs [draft-ietf-opsawg-mud-acceptable-urls-06] (14 pages) - Operational Considerations for use of DNS in IoT devices [draft-ietf-opsawg-mud-iot-dns-considerations-08] (17 pages) - Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices [draft-ietf-opsawg-mud-tls-12] (34 pages) - A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) [draft-ietf-opsawg-nat-yang-17] (94 pages) - Network Telemetry Framework [draft-ietf-opsawg-ntf-13] (33 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Tools [draft-ietf-opsawg-oam-overview-16] (53 pages) - Ownership and licensing statements in YANG [draft-ietf-opsawg-ol-03] (8 pages) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-09] (35 pages) - PCAP Capture File Format [draft-ietf-opsawg-pcap-02] (10 pages) - Link-Layer Types for PCAP and PCAPNG Capture File Formats [draft-ietf-opsawg-pcaplinktype-00] (32 pages) - PCAP Next Generation (pcapng) Capture File Format [draft-ietf-opsawg-pcapng-00] (57 pages) - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB [draft-ietf-opsawg-rfc5066bis-07] (6 pages) - An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element [draft-ietf-opsawg-rfc7125-update-03] (7 pages) - A YANG Network Model for Service Attachment Points (SAPs) [draft-ietf-opsawg-sap-15] (43 pages) - Discovering and Retrieving Software Transparency and Vulnerability Information [draft-ietf-opsawg-sbom-access-18] (21 pages) - Secure Device Install [draft-ietf-opsawg-sdi-13] (16 pages) - Service Assurance for Intent-based Networking Architecture [draft-ietf-opsawg-service-assurance-architecture-13] (29 pages) - YANG Modules for Service Assurance [draft-ietf-opsawg-service-assurance-yang-11] (45 pages) - Service Models Explained [draft-ietf-opsawg-service-model-explained-05] (23 pages) - Expressing SNMP SMI Datatypes in XML Schema Definition Language [draft-ietf-opsawg-smi-datatypes-in-xsd-06] (14 pages) - Simple Network Management Protocol (SNMP) Context EngineID Discovery [draft-ietf-opsawg-snmp-engineid-discovery-03] (9 pages) - Survey of IETF Network Management Standards [draft-ietf-opsawg-survey-management-00] (21 pages) - Alarms in Syslog [draft-ietf-opsawg-syslog-alarm-02] (7 pages) - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications [draft-ietf-opsawg-syslog-msg-mib-06] (22 pages) - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages [draft-ietf-opsawg-syslog-snmp-05] (15 pages) - The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol [draft-ietf-opsawg-tacacs-18] (41 pages) - TACACS+ TLS 1.3 [draft-ietf-opsawg-tacacs-tls13-02] (12 pages) - A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) [draft-ietf-opsawg-tacacs-yang-12] (16 pages) - Updates to the TLS Transport Model for SNMP [draft-ietf-opsawg-tlstm-update-15] (35 pages) - Management Information Base for Virtual Machines Controlled by a Hypervisor [draft-ietf-opsawg-vmm-mib-04] (52 pages) - A Common YANG Data Model for Layer 2 and Layer 3 VPNs [draft-ietf-opsawg-vpn-common-12] (60 pages) - A YANG Data Model for Network and VPN Service Performance Monitoring [draft-ietf-opsawg-yang-vpn-service-pm-15] (39 pages) - CGN Deployment with MPLS/VPNs [draft-kuarsingh-lsn-deployment-06] (18 pages) - Export BGP community information in IP Flow Information Export (IPFIX) [draft-li-opsawg-ipfix-bgp-community-02] (10 pages) - Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) [draft-tgraf-ipfix-mpls-sr-label-type-07] (6 pages) - Export of On-Path Delay in IPFIX [draft-tgraf-opsawg-ipfix-on-path-telemetry-01] (23 pages) - Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3) [draft-vaughn-tlstm-update-01] (43 pages) Requests for Comments: BCP161: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) RFC5343: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) RFC5674: Alarms in Syslog (7 pages) RFC5675: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (15 pages) RFC5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (22 pages) RFC5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (35 pages) RFC5935: Expressing SNMP SMI Datatypes in XML Schema Definition Language (14 pages) RFC6291: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) RFC6340: Textual Conventions for the Representation of Floating-Point Numbers (7 pages) RFC6632: An Overview of the IETF Network Management Standards (85 pages) RFC7124: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB (6 pages) RFC7276: An Overview of Operations, Administration, and Maintenance (OAM) Tools (53 pages) RFC7289: Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs (20 pages) RFC7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks (29 pages) RFC7448: MIB Transfer from the IETF to the IEEE 802.3 WG (7 pages) RFC7494: IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) (13 pages) RFC7547: Management of Networks with Constrained Devices: Problem Statement and Requirements (44 pages) RFC7548: Management of Networks with Constrained Devices: Use Cases (26 pages) RFC7630: HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 (14 pages) * Obsoletes RFC7860 RFC7666: Management Information Base for Virtual Machines Controlled by a Hypervisor (52 pages) RFC7860: HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 (14 pages) RFC8309: Service Models Explained (23 pages) RFC8350: Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) (29 pages) RFC8512: A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) (94 pages) RFC8520: Manufacturer Usage Description Specification (60 pages) RFC8549: Export of BGP Community Information in IP Flow Information Export (IPFIX) (18 pages) RFC8886: Secure Device Install (16 pages) RFC8907: The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol (41 pages) RFC8969: A Framework for Automating Service and Network Management with YANG (40 pages) RFC9092: Finding and Using Geofeed Data (21 pages) RFC9105: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) (16 pages) RFC9160: Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) (5 pages) RFC9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs (60 pages) RFC9182: A YANG Network Data Model for Layer 3 VPNs (129 pages) RFC9232: Network Telemetry Framework (33 pages) RFC9291: A YANG Network Data Model for Layer 2 VPNs (139 pages) RFC9375: A YANG Data Model for Network and VPN Service Performance Monitoring (39 pages) STD78: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) SIDR Operations (sidrops) ------------------------- Charter Last Modified: 2023-05-06 Current Status: Active Chairs: Chris Morrow Keyur Patel Russ Housley Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: sidrops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sidrops Archive: https://mailarchive.ietf.org/arch/browse/sidrops/ Description of Working Group: The global deployment of SIDR, consisting of RPKI, Origin Validation of BGP announcements, and BGPSEC, is underway, creating an Internet Routing System consisting of SIDR-aware and non-SIDR-aware networks. This deployment must be properly handled to avoid the division of the Internet into separate networks. Sidrops is responsible for encouraging deployment of theSIDR technologies while ensuring as secure of a global routing system, as possible, during the transition. The SIDR Operations Working Group (sidrops) develops guidelines for the operation of SIDR-aware networks, and provides operational guidance on how to deploy and operate SIDR technologies in existing and new networks. In the space of sidrops, the term operators will encompass a range of operational experience: CA Operators, Regional/National and Local Internet Registries, Relying Party software developers as well as the research/measurement community all have relevant operational experience or insight that this working group will consider in its work. The sidrops working group is focused on deployment and operational issues and experiences with SIDR technologies that are part of the global routing system, as well as the repositories and CA systems that form part of the SIDR architecture. The goals of the sidrops working group are to: 1. Solicit input from a range of operators to identify operational issues with a SIDR-aware Internet, and determine solutions or workarounds to those issues. 2. Solicit input from all operators to identify issues with interaction with the non-SIDR-aware Internet, and to determine solutions or workarounds to those issues. 3. Develop operational solutions for identified issues in sidrops and document them in informational or BCP documents. These documents should document SIDR operational experience, including interactions with non-SIDR-aware networks, the interfaces between SIDR- aware and non-SIDR-aware networks, and the continued operational/ security impacts from non-SIDR-aware networks. SIDR operational and deployment issues with Interdomain Routing Protocols as well as BGPSEC maintenance and extension are the primary responsibility of the IDR working group. The sidrops Working Group may provide input to that group, as needed, and cooperate with that group in reviewing solutions to SIDR operational and deployment problems. Future work items within this scope will be adopted by the Working Group if there is a substantial expression of interest from the community and if the work (for example protocol maintenance) clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Goals and Milestones: Jul 2017 - draft-ietf-sidr-bgpsec-rollover Jul 2017 - draft-ietf-sidr-rtr-keying Jul 2017 - draft-ietf-sidr-route-server-rpki-light Jul 2017 - draft-ietf-sidr-rpki-tree-validation Sep 2017 - BGPSEC Ops document finalized. Internet-Drafts: - BGPsec Router Certificate Rollover [draft-ietf-sidr-bgpsec-rollover-06] (10 pages) - Use Cases for Localized Versions of the RPKI [draft-ietf-sidr-lta-use-cases-07] (5 pages) - Manifests for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-6486bis-11] (16 pages) - The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 [draft-ietf-sidrops-8210bis-10] (38 pages) - A Profile for Autonomous System Provider Authorization [draft-ietf-sidrops-aspa-profile-13] (16 pages) - BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects [draft-ietf-sidrops-aspa-verification-14] (22 pages) - Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) [draft-ietf-sidrops-bar-sav-01] (15 pages) - BGPsec Algorithms, Key Formats, and Signature Formats [draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05] (21 pages) - BGPsec Router Certificate Rollover [draft-ietf-sidrops-bgpsec-rollover-04] (11 pages) - Resource Public Key Infrastructure (RPKI) Repository Requirements [draft-ietf-sidrops-deprecate-rsync-00] (10 pages) - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator [draft-ietf-sidrops-https-tal-08] (11 pages) - Use Cases for Localized Versions of the RPKI [draft-ietf-sidrops-lta-use-cases-06] (6 pages) - Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-ov-clarify-05] (5 pages) - Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export [draft-ietf-sidrops-ov-egress-04] (5 pages) - Resource Public Key Infrastructure (RPKI) Repository Requirements [draft-ietf-sidrops-prefer-rrdp-02] (10 pages) - A Profile for Route Origin Authorizations (ROAs) [draft-ietf-sidrops-rfc6482bis-03] (14 pages) - Avoidance of ROA Containing Multiple IP Prefixes [draft-ietf-sidrops-roa-considerations-08] (6 pages) - Signaling Prefix Origin Validation Results from a Route Server to Peers [draft-ietf-sidrops-route-server-rpki-light-02] (7 pages) - Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh [draft-ietf-sidrops-rov-no-rr-08] (7 pages) - Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties [draft-ietf-sidrops-rp-06] (11 pages) - The 'I' in RPKI Does Not Stand for Identity [draft-ietf-sidrops-rpki-has-no-identity-07] (7 pages) - The Use of maxLength in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidrops-rpkimaxlen-15] (13 pages) - Timing Parameters in the RPKI based Route Origin Validation Supply Chain [draft-ietf-sidrops-rpki-rov-timing-06] (10 pages) - A Profile for RPKI Signed Checklists (RSCs) [draft-ietf-sidrops-rpki-rsc-11] (13 pages) - A profile for Resource Tagged Attestations (RTAs) [draft-ietf-sidrops-rpki-rta-00] (13 pages) - RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation [draft-ietf-sidrops-rpki-tree-validation-03] (17 pages) - Router Keying for BGPsec [draft-ietf-sidrops-rtr-keying-06] (21 pages) - RPKI Signed Object for Trust Anchor Key [draft-ietf-sidrops-signed-tal-13] (23 pages) - Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers [draft-ietf-sidrops-validating-bgp-speaker-03] (8 pages) - Signaling Prefix Origin Validation Results from a Route-Server to Peers [draft-ietf-sidr-route-server-rpki-light-01] (6 pages) - RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator [draft-ietf-sidr-rpki-tree-validation-03] (15 pages) - BGPsec Validation State Signaling [draft-sidrops-bgpsec-validation-signaling-05] (8 pages) - Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) [draft-sriram-sidrops-bar-sav-02] (15 pages) Requests for Comments: BCP224: BGPsec Router Certificate Rollover (11 pages) RFC8481: Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) (5 pages) * Updates RFC9324 RFC8488: RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation (17 pages) RFC8608: BGPsec Algorithms, Key Formats, and Signature Formats (21 pages) RFC8630: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator (11 pages) RFC8634: BGPsec Router Certificate Rollover (11 pages) RFC8635: Router Keying for BGPsec (21 pages) RFC8893: Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export (5 pages) RFC8897: Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties (11 pages) RFC9255: The 'I' in RPKI Does Not Stand for Identity (7 pages) RFC9286: Manifests for the Resource Public Key Infrastructure (RPKI) (16 pages) RFC9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI) (13 pages) RFC9323: A Profile for RPKI Signed Checklists (RSCs) (13 pages) RFC9324: Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh (7 pages) Babel routing protocol (babel) ------------------------------ Charter Last Modified: 2022-05-04 Current Status: Active Chairs: Donald E. Eastlake 3rd Russ White Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Mailing Lists: General Discussion: babel@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/babel Archive: https://mailarchive.ietf.org/arch/browse/babel/ Description of Working Group: Babel is a loop-avoiding, distance vector routing protocol with good provisions for dynamically computed link metrics. The core of the Babel protocol and security extensions are described in Experimental Independent Stream RFCs 6126, 7557, and 7298. These RFCs are the basis of three independent, open source implementations. There is some production deployment of these implementations, notably in hybrid networks (networks that include classical, wired parts with meshy radio bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). The Working Group will focus on moving the Babel protocol to IETF Proposed Standard with IETF review. This includes clarifying RFC 6126 and integrating RFC 7557 and feedback provided by independent implementations, and resolving comments. It is not a requirement that the Babel protocol produced is backwards compatible with RFC 6126. It is a requirement that Babel support at least one profile that is auto-configuring. Other documents that are relevant to the above work can also be produced. Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security. Link metric measurement or link metric calculation procedures significantly more complex that those currently in Babel are out of scope. The Babel WG should coordinate with other Working Groups, such as the HOMENET WG for likely applicability, the RTGWG and V6OPS WG about Source-Specific Routing to support IPv6 multihoming, the PIM WG for discussion around multicast, and the MANET WG for considerations around wireless. The Babel WG should liaise as necessary with the Broadband Forum to facilitate use of the Babel Information Model for TR-069. Work Items: - Produce a revision of RFC 6126 suitable for publication as a Proposed Standard -- incorporate in the revision developments since RFC 6126 -- resolve technical issues found -- include in the base specification the extensibility work in RFC 7557 -- support auto-configuration -- consider any important changes based on experience with Babel to date. - Address security needs for BABEL. This may include using the techniques in RFC 7298, or other alternatives. Security may be included in the base spec or the base spec may normatively reference a separate Proposed Standard specification. This is required as part of moving Babel to Proposed Standard. - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. To be consistent with the ongoing effort to use YANG data models in the Routing Area, a Babel YANG data model should be specified to support management of Babel routers. - As the Proposed Standard version of Babel is completed, an Applicability Statement should be finalized to guide those potentially interested in deploying Babel. This Applicability Statement may include deployment advice and will be published as an RFC. - The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes. This documentation may be on the Working Group's wiki, in an internet-draft that isn't expected to be published as an RFC, or a combination. - As a non-primary focus, the Working Group may work on multicast aspects of Babel. This may include discussion of any potential issues for supporting Babel running with PIM-SM in an auto-configuration profile. It may include exploring Babel carrying separate metrics for multicast. It may include discussion and consultation with the PIM WG about Babel providing the ability to build multicast routing tables. With AD and WG agreement, once an approach is understood, then a milestone may be added for an associated document targeted as Proposed Standard. - As a non-primary focus, the Working Group may work on documents defining source specific routing extensions for Babel as a way of handling IPv6 multihoming. Goals and Milestones: Done - WG adoption of RFC6126bis Done - WG adoption of Babel Applicability draft Done - WG adoption of Babel Management (Info Model & YANG Model) draft Done - IESG Submission of Babel Applicability draft (Informational) Done - IESG Submission of Babel Information Model draft (Proposed Standard) Done - IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard) Done - IESG Submission of source specific Babel draft (Proposed Standard) Done - IESG Submission of Babel Management draft (Proposed Standard) Done - IESG submission of IPv4 via IPv6 Internet-Drafts: - Source-Specific Routing in Babel [draft-boutier-babel-source-specific-03] (11 pages) - Applicability of the Babel Routing Protocol [draft-ietf-babel-applicability-10] (10 pages) - Babel Routing Protocol over Datagram Transport Layer Security [draft-ietf-babel-dtls-10] (9 pages) - MAC Authentication for the Babel Routing Protocol [draft-ietf-babel-hmac-12] (17 pages) - Babel Information Model [draft-ietf-babel-information-model-14] (20 pages) - Relaxed Packet Counter Verification for Babel MAC Authentication [draft-ietf-babel-mac-relaxed-04] (7 pages) - The Babel Routing Protocol [draft-ietf-babel-rfc6126bis-20] (54 pages) - Delay-based Metric Extension for the Babel Routing Protocol [draft-ietf-babel-rtt-extension-00] (9 pages) - Source-Specific Routing in the Babel Routing Protocol [draft-ietf-babel-source-specific-08] (13 pages) - IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol [draft-ietf-babel-v4viav6-08] (9 pages) - YANG Data Model for Babel [draft-ietf-babel-yang-model-13] (44 pages) - Babel HMAC Cryptographic Authentication [draft-ovsienko-babel-rfc7298bis-00] (55 pages) Requests for Comments: RFC8965: Applicability of the Babel Routing Protocol (10 pages) RFC8966: The Babel Routing Protocol (54 pages) RFC8967: MAC Authentication for the Babel Routing Protocol (17 pages) RFC8968: Babel Routing Protocol over Datagram Transport Layer Security (9 pages) RFC9046: Babel Information Model (20 pages) RFC9079: Source-Specific Routing in the Babel Routing Protocol (13 pages) RFC9229: IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol (9 pages) BGP Enabled ServiceS (bess) --------------------------- Charter Last Modified: 2023-01-13 Current Status: Active Chairs: Matthew Bocci Stephane Litkowski Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Secretary: Mankamana Mishra Mailing Lists: General Discussion: bess@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bess Archive: https://mailarchive.ietf.org/arch/browse/bess/ Description of Working Group: BGP is established as a protocol for provisioning and operating Layer-3 (routed) Virtual Private Networks (L3VPNs). It is also used in certain Layer-2 Virtual Private Networks (L2VPNs). The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP. In particular, the working group will work on the following services: - BGP/MPLS IP VPN solutions (based on RFC4364 and RFC4659) for supporting provider-provisioned L3VPNs including methods for enabling multicast over BGP/MPLS VPNs. - BGP-enabled L2VPNs (as described in RFC 4664) that operate over IP or MPLS packet switched network tunnels. All types of L2VPN are in scope provided they utilize BGP for discovery, signaling, or for some other purposes related to the VPN. But L2VPN solutions that operate over pseudowires or use LDP and that do not utilize BGP will be addressed by the PALS working group. Any contention in placement of the work between these working groups will be resolved by the chairs. - BGP-enabled VPN solutions for use in the data center networking. This work includes consideration of VPN scaling issues and mechanisms applicable to such environments. - Extensions to BGP-enabled VPN solutions for the construction of virtual topologies in support of services such as Service Function Chaining. The working group may also suggest new services to be supported by BGP and these may be added to the working group charter subject to rechartering. The working group may work on: - Mechanisms to support BGP-enabled services in the presence of multi- homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience. - Auto-discovery of sites that participate in the BGP-enabled service. - Data models for modeling, managing, and operating BGP-based services using SMI or YANG. - OAM or resiliency mechanisms operating over BGP-enabled services. But native data plane OAM mechanisms may be worked on only in conjunction with the working groups responsible for the relevant data planes. - Extensions to BGP and extensions to YANG models for BGP. All such work must be reviewed by the IDR WG, but the decision to request publication of such work remains with the BESS WG. The working group will also coordinate with other working groups where appropriate. For example, with the MPLS working group for issues related to the MPLS architecture, and the NVO3 working group for coordination of protocols to support data center VPNs. The BESS working group will not define new data plane or forwarding plane encapsulations. Goals and Milestones: Dec 2015 - Submit E-VPN OAM to IESG as PS Dec 2020 - Submit a Yang or SMI datamodel for E-VPN to IESG as PS Dec 2020 - Submit a YANG datamodel for mVPN to IESG as PS Dec 2020 - Submit a YANG datamodel for L2VPN to IESG as PS Dec 2020 - Submit a Yang or SMI datamodel for RFC4364 to IESG as PS Done - Submit specification of the BGP ACCEPT_OWN Community Attribute to IESG as PS Done - Submit specification for multicast VPN bidir P-tunnels to IESG as PS Done - Submit specifications for E-VPN to IESG as PS Done - Submit specification for extranet support in multicast VPNs to IESG as PS Done - Submit specification for the use of E-VPN for datacenter overlays to IESG as PS Done - Submit specification of a multicast VPN MIB to IESG as PS Done - Submit specifications for PBB/E-VPN interoperability to IESG as PS Done - Submit specifications for SPB-M/E-VPN interoperability to IESG as PS Done - Submit specifications for VPLS multi-homing to IESG as PS Done - Submit specification for BGP NSH controlplane to IESG as PS Internet-Drafts: - VXLAN DCI Using EVPN [draft-boutros-bess-vxlan-evpn-02] (15 pages) - VPWS support in EVPN [draft-boutros-l2vpn-evpn-vpws-06] (11 pages) - Yang Data Model for EVPN [draft-brissette-bess-evpn-yang-01] (12 pages) - Yang Data Model for BGP/MPLS L3 VPNs [draft-dhjain-bess-bgp-l3vpn-yang-02] (29 pages) - Explicit Tracking with Wild Card Routes in Multicast VPN [draft-dolganow-bess-mvpn-expl-track-02] (15 pages) - Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection [draft-drake-bess-datacenter-gateway-05] (11 pages) - BGP Usage for SDWAN Overlay Networks [draft-dunbar-bess-bgp-sdwan-usage-08] (28 pages) - Service Chaining using Virtual Networks with BGP VPNs [draft-fm-bess-service-chaining-02] (42 pages) - Inter-AS Option C between NVO3 and BGP/MPLS IP VPN network [draft-hao-bess-inter-nvo3-vpn-optionc-03] (14 pages) - BGP Based Multicast [draft-ietf-bess-bgp-multicast-04] (28 pages) - Controller Based BGP Multicast Signaling [draft-ietf-bess-bgp-multicast-controller-09] (25 pages) - BGP Usage for SD-WAN Overlay Networks [draft-ietf-bess-bgp-sdwan-usage-09] (29 pages) - Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) [draft-ietf-bess-bgp-vpls-control-flags-08] (9 pages) - Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing [draft-ietf-bess-datacenter-gateway-13] (12 pages) - Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks [draft-ietf-bess-dci-evpn-overlay-10] (24 pages) - Deployment Guidelines for Edge Peering IPv4-NLRI with IPv6-NH [draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh-02] (23 pages) - Cumulative DMZ Link Bandwidth and load-balancing [draft-ietf-bess-ebgp-dmz-02] (12 pages) - Requirements for Extending BGP/MPLS VPNs to End-Systems [draft-ietf-bess-end-system-requirements-00] (16 pages) - AC-Aware Bundling Service Interface in EVPN [draft-ietf-bess-evpn-ac-aware-bundling-01] (13 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-ietf-bess-evpn-ac-df-03] (10 pages) - EVPN Network Layer Fault Management [draft-ietf-bess-evpn-bfd-04] (17 pages) - Updates on EVPN BUM Procedures [draft-ietf-bess-evpn-bum-procedure-updates-14] (21 pages) - A new Designated Forwarder Election for the EVPN [draft-ietf-bess-evpn-df-election-03] (15 pages) - Framework for Ethernet VPN Designated Forwarder Election Extensibility [draft-ietf-bess-evpn-df-election-framework-09] (32 pages) - Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) [draft-ietf-bess-evpn-etree-14] (23 pages) - Fast Recovery for EVPN Designated Forwarder Election [draft-ietf-bess-evpn-fast-df-recovery-07] (12 pages) - EVPN control plane for Geneve [draft-ietf-bess-evpn-geneve-06] (10 pages) - Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) [draft-ietf-bess-evpn-igmp-mld-proxy-21] (30 pages) - Integrated Routing and Bridging in Ethernet VPN (EVPN) [draft-ietf-bess-evpn-inter-subnet-forwarding-15] (30 pages) - EVPN Interworking with IPVPN [draft-ietf-bess-evpn-ipvpn-interworking-07] (30 pages) - Extended Mobility Procedures for EVPN-IRB [draft-ietf-bess-evpn-irb-extended-mobility-09] (25 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-ietf-bess-evpn-irb-mcast-09] (78 pages) - EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols [draft-ietf-bess-evpn-l2gw-proto-03] (13 pages) - LSP-Ping Mechanisms for EVPN and PBB-EVPN [draft-ietf-bess-evpn-lsp-ping-10] (21 pages) - EVPN multi-homing port-active load-balancing [draft-ietf-bess-evpn-mh-pa-07] (13 pages) - EVPN Multi-Homing Extensions for Split Horizon Filtering [draft-ietf-bess-evpn-mh-split-horizon-05] (18 pages) - EVPN Interoperability Modes [draft-ietf-bess-evpn-modes-interop-02] (20 pages) - Seamless Multicast Interoperability between EVPN and MVPN PEs [draft-ietf-bess-evpn-mvpn-seamless-interop-05] (38 pages) - Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) [draft-ietf-bess-evpn-na-flags-09] (10 pages) - Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) [draft-ietf-bess-evpn-oam-req-frmwk-10] (16 pages) - Optimized Ingress Replication Solution for Ethernet VPN (EVPN) [draft-ietf-bess-evpn-optimized-ir-12] (34 pages) - A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) [draft-ietf-bess-evpn-overlay-12] (33 pages) - Per multicast flow Designated Forwarder Election for EVPN [draft-ietf-bess-evpn-per-mcast-flow-df-election-07] (12 pages) - Preference-based EVPN DF Election [draft-ietf-bess-evpn-pref-df-10] (19 pages) - IP Prefix Advertisement in Ethernet VPN (EVPN) [draft-ietf-bess-evpn-prefix-advertisement-11] (31 pages) - Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks [draft-ietf-bess-evpn-proxy-arp-nd-16] (22 pages) - Multicast Source Redundancy in EVPN Networks [draft-ietf-bess-evpn-redundant-mcast-source-05] (32 pages) - Weighted Multi-Path Procedures for EVPN Multi-Homing [draft-ietf-bess-evpn-unequal-lb-17] (21 pages) - Usage and Applicability of BGP MPLS-Based Ethernet VPN [draft-ietf-bess-evpn-usage-09] (31 pages) - EVPN Virtual Ethernet Segment [draft-ietf-bess-evpn-virtual-eth-segment-10] (25 pages) - Virtual Hub-and-Spoke in BGP EVPNs [draft-ietf-bess-evpn-virtual-hub-00] (16 pages) - Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents [draft-ietf-bess-evpn-vpls-seamless-integ-07] (16 pages) - Virtual Private Wire Service Support in Ethernet VPN [draft-ietf-bess-evpn-vpws-14] (17 pages) - EVPN VPWS Flexible Cross-Connect Service [draft-ietf-bess-evpn-vpws-fxc-08] (17 pages) - Yang Data Model for EVPN [draft-ietf-bess-evpn-yang-07] (28 pages) - Extended Procedures for EVPN Optimized Ingress Replication [draft-ietf-bess-extended-evpn-optimized-ir-03] (13 pages) - Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels [draft-ietf-bess-fat-pw-bgp-04] (9 pages) - IPv6-Only PE Design for IPv4-NLRI with IPv6-NH [draft-ietf-bess-ipv6-only-pe-design-04] (28 pages) - Ingress Replication Tunnels in Multicast VPN [draft-ietf-bess-ir-05] (23 pages) - L2L3 VPN Multicast MIB [draft-ietf-bess-l2l3-vpn-mcast-mib-16] (20 pages) - YANG Data Model for MPLS-based L2VPN [draft-ietf-bess-l2vpn-yang-10] (49 pages) - Yang Data Model for BGP/MPLS L3 VPNs [draft-ietf-bess-l3vpn-yang-05] (22 pages) - Multicast VPN State Damping [draft-ietf-bess-multicast-damping-06] (18 pages) - Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels [draft-ietf-bess-mvpn-bidir-04] (34 pages) - Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication [draft-ietf-bess-mvpn-bidir-ingress-replication-04] (8 pages) - MVPN/EVPN Tunnel Aggregation with Common Labels [draft-ietf-bess-mvpn-evpn-aggregation-label-09] (16 pages) - Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication [draft-ietf-bess-mvpn-evpn-sr-p2mp-07] (20 pages) - Explicit Tracking with Wildcard Routes in Multicast VPN [draft-ietf-bess-mvpn-expl-track-13] (21 pages) - Extranet Multicast in BGP/IP MPLS VPNs [draft-ietf-bess-mvpn-extranet-07] (65 pages) - Multicast VPN Fast Upstream Failover [draft-ietf-bess-mvpn-fast-failover-15] (22 pages) - Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures [draft-ietf-bess-mvpn-global-table-mcast-03] (22 pages) - BGP/MPLS Layer 3 VPN Multicast Management Information Base [draft-ietf-bess-mvpn-mib-12] (57 pages) - Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes [draft-ietf-bess-mvpn-msdp-sa-interoperation-08] (6 pages) - BGP as an MVPN PE-CE Protocol [draft-ietf-bess-mvpn-pe-ce-01] (12 pages) - Yang Data Model for Multicast in MPLS/BGP IP VPNs [draft-ietf-bess-mvpn-yang-05] (41 pages) - BGP Control Plane for the Network Service Header in Service Function Chaining [draft-ietf-bess-nsh-bgp-control-plane-18] (59 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-bess-orf-covering-prefixes-06] (21 pages) - PBB-EVPN ISID-based CMAC-Flush [draft-ietf-bess-pbb-evpn-isid-cmacflush-06] (12 pages) - Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags [draft-ietf-bess-pta-flags-03] (7 pages) - Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop [draft-ietf-bess-rfc5549revision-06] (12 pages) - BGP MPLS-Based Ethernet VPN [draft-ietf-bess-rfc7432bis-07] (74 pages) - Service Function Chaining using Virtual Networks with BGP VPNs [draft-ietf-bess-service-chaining-06] (41 pages) - Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) [draft-ietf-bess-spbm-evpn-02] (11 pages) - BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) [draft-ietf-bess-srv6-services-15] (29 pages) - BGP/MPLS VPN Virtual PE [draft-ietf-bess-virtual-pe-00] (25 pages) - Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution [draft-ietf-bess-virtual-subnet-07] (15 pages) - FIB Reduction in Virtual Subnet [draft-ietf-bess-virtual-subnet-fib-reduction-04] (7 pages) - BGP based Multi-homing in Virtual Private LAN Service [draft-ietf-bess-vpls-multihoming-05] (21 pages) - Weighted HRW and its applications [draft-ietf-bess-weighted-hrw-00] (11 pages) - Shortest Path Bridging, MAC mode Support over EVPN [draft-ietf-l2vpn-spbm-evpn-02] (10 pages) - TRILL-EVPN [draft-ietf-l2vpn-trill-evpn-02] (14 pages) - BGP ACCEPT_OWN Community Attribute [draft-ietf-l3vpn-acceptown-community-10] (8 pages) - BGP-Signaled End-System IP/VPNs [draft-ietf-l3vpn-end-system-06] (31 pages) - Requirements for Extending BGP/MPLS VPNs to End-Systems [draft-ietf-l3vpn-end-system-requirements-00] (16 pages) - MVPN: Using Bidirectional P-Tunnels [draft-ietf-l3vpn-mvpn-bidir-08] (32 pages) - Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication [draft-ietf-l3vpn-mvpn-bidir-ingress-replication-01] (13 pages) - Extranet Multicast in BGP/IP MPLS VPNs [draft-ietf-l3vpn-mvpn-extranet-05] (61 pages) - Global Table Multicast with BGP-MVPN Procedures [draft-ietf-l3vpn-mvpn-global-table-mcast-00] (23 pages) - Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes [draft-ietf-l3vpn-mvpn-mldp-nlri-10] (10 pages) - BGP as an MVPN PE-CE Protocol [draft-ietf-l3vpn-mvpn-pe-ce-02] (13 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-l3vpn-orf-covering-prefixes-02] (19 pages) - Virtual Subnet: A L3VPN-based Subnet Extension Solution [draft-ietf-l3vpn-virtual-subnet-03] (14 pages) - Virtual Hub-and-Spoke in BGP EVPNs [draft-keyupate-bess-evpn-virtual-hub-02] (16 pages) - Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels [draft-keyupate-l2vpn-fat-pw-bgp-04] (8 pages) - EVPN Interoperability Modes [draft-krattiger-evpn-modes-interop-03] (21 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-lin-bess-evpn-irb-mcast-04] (70 pages) - BGP Control Plane for NSH SFC [draft-mackie-bess-nsh-bgp-control-plane-04] (52 pages) - Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing [draft-malhotra-bess-evpn-unequal-lb-04] (18 pages) - Inter-AS Option D for BGP/MPLS IP VPN [draft-mapathak-interas-ab-02] (15 pages) - A new Designated Forwarder Election for the EVPN [draft-mohanty-bess-evpn-df-election-02] (15 pages) - Multicast VPN state damping [draft-morin-bess-multicast-damping-01] (15 pages) - Multicast VPN fast upstream failover [draft-morin-bess-mvpn-fast-failover-02] (17 pages) - Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint Trees [draft-parekh-bess-mvpn-evpn-sr-p2mp-02] (15 pages) - Interconnect Solution for EVPN Overlay networks [draft-rabadan-bess-dci-evpn-overlay-00] (22 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-rabadan-bess-evpn-ac-df-05] (10 pages) - Optimized Ingress Replication solution for EVPN [draft-rabadan-bess-evpn-optimized-ir-02] (24 pages) - Preference-based EVPN DF Election [draft-rabadan-bess-evpn-pref-df-02] (12 pages) - EVPN Vendor-Specific Route Type [draft-rabadan-bess-vendor-evpn-route-07] (5 pages) - IP Prefix Advertisement in EVPN [draft-rabadan-l2vpn-evpn-prefix-advertisement-03] (23 pages) - IANA Registry for P-Multicast Service Interface Tunnel Attribute Flags [draft-rosen-bess-pta-flags-00] (3 pages) - Ingress Replication Tunnels in Multicast VPN [draft-rosen-l3vpn-ir-02] (19 pages) - E-TREE Support in EVPN & PBB-EVPN [draft-sajassi-bess-evpn-etree-00] (11 pages) - IGMP and MLD Proxy for EVPN [draft-sajassi-bess-evpn-igmp-mld-proxy-01] (25 pages) - Per multicast flow Designated Forwarder Election for EVPN [draft-sajassi-bess-evpn-per-mcast-flow-df-election-01] (12 pages) - EVPN Virtual Ethernet Segment [draft-sajassi-bess-evpn-virtual-eth-segment-03] (22 pages) - (PBB-)EVPN Seamless Integration with (PBB-)VPLS [draft-sajassi-bess-evpn-vpls-seamless-integ-00] (10 pages) - YANG Data Model for MPLS-based L2VPN [draft-shah-bess-l2vpn-yang-01] (51 pages) - Updated processing of control flags for BGP VPLS [draft-singh-bess-bgp-vpls-control-flags-01] (8 pages) - PIM Proxy in EVPN Networks [draft-skr-bess-evpn-pim-proxy-01] (24 pages) - Multicast Source Redundancy in EVPN Networks [draft-skr-bess-evpn-redundant-mcast-source-02] (29 pages) - Loop Protection in EVPN networks [draft-snr-bess-evpn-loop-protect-04] (13 pages) - Propagation of IPv6 Neighbor Advertisement Flags in EVPN [draft-snr-bess-evpn-na-flags-07] (6 pages) - Operational Aspects of Proxy-ARP/ND in EVPN Networks [draft-snr-bess-evpn-proxy-arp-nd-02] (22 pages) - PBB-EVPN ISID-based CMAC-Flush [draft-snr-bess-pbb-evpn-isid-cmacflush-06] (10 pages) - Extended Procedures for EVPN Optimized Ingress Replication [draft-wsv-bess-extended-evpn-optimized-ir-02] (13 pages) - FIB Reduction in Virtual Subnet [draft-xu-l3vpn-virtual-subnet-fib-reduction-02] (6 pages) - Updates on EVPN BUM Procedures [draft-zzhang-bess-evpn-bum-procedure-updates-03] (16 pages) - MVPN and MSDP SA Interoperation [draft-zzhang-bess-mvpn-msdp-sa-interoperation-01] (6 pages) Requests for Comments: RFC7441: Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes (10 pages) RFC7543: Covering Prefixes Outbound Route Filter for BGP-4 (21 pages) RFC7582: Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels (34 pages) * Updates RFC8534 RFC7611: BGP ACCEPT_OWN Community Attribute (8 pages) RFC7716: Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures (22 pages) RFC7734: Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) (11 pages) RFC7740: Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication (8 pages) RFC7814: Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution (15 pages) RFC7899: Multicast VPN State Damping (18 pages) RFC7900: Extranet Multicast in BGP/IP MPLS VPNs (65 pages) * Updates RFC8534 RFC7902: Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags (7 pages) RFC7988: Ingress Replication Tunnels in Multicast VPN (23 pages) RFC8214: Virtual Private Wire Service Support in Ethernet VPN (17 pages) RFC8317: Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) (23 pages) RFC8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) (33 pages) RFC8388: Usage and Applicability of BGP MPLS-Based Ethernet VPN (31 pages) RFC8395: Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels (9 pages) RFC8502: L2L3 VPN Multicast MIB (20 pages) RFC8503: BGP/MPLS Layer 3 VPN Multicast Management Information Base (57 pages) RFC8534: Explicit Tracking with Wildcard Routes in Multicast VPN (21 pages) RFC8560: Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents (16 pages) RFC8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility (32 pages) RFC8614: Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) (9 pages) RFC8950: Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop (12 pages) RFC9014: Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks (24 pages) RFC9015: BGP Control Plane for the Network Service Header in Service Function Chaining (59 pages) RFC9026: Multicast VPN Fast Upstream Failover (22 pages) RFC9047: Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) (10 pages) RFC9062: Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) (16 pages) RFC9081: Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes (6 pages) RFC9125: Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing (12 pages) RFC9135: Integrated Routing and Bridging in Ethernet VPN (EVPN) (30 pages) RFC9136: IP Prefix Advertisement in Ethernet VPN (EVPN) (31 pages) RFC9161: Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks (22 pages) RFC9251: Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) (30 pages) RFC9252: BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) (29 pages) Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2022-07-23 Current Status: Active Chairs: Jeffrey Haas Reshad Rahman Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Tech Advisors: Dave Katz David Ward Mailing Lists: General Discussion: rtg-bfd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtg-bfd Archive: https://mailarchive.ietf.org/arch/browse/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Goals and Milestones: Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard Done - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC Done - Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless IP draft to the IESG to be considered as a Proposed Standard Done - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Done - Submit a BFD Yang module to the IESG to be considered as a Proposed Standard Done - Submit BFD for VxLAN to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Stability [draft-ashesh-bfd-stability-05] (6 pages) - Unsolicited BFD for Sessionless Applications [draft-chen-bfd-unsolicited-03] (6 pages) - Unaffiliated BFD Echo Function [draft-cw-bfd-unaffiliated-echo-01] (6 pages) - BFD Encapsulated in Large Packets [draft-haas-bfd-large-packets-01] (5 pages) - Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-base-11] (49 pages) - Generic Application of Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-generic-05] (17 pages) - BFD Generic Cryptographic Authentication [draft-ietf-bfd-generic-crypto-auth-06] (13 pages) - Authenticating BFD using HMAC-SHA-2 procedures [draft-ietf-bfd-hmac-sha-05] (8 pages) - Common Interval Support in Bidirectional Forwarding Detection [draft-ietf-bfd-intervals-05] (8 pages) - BFD Encapsulated in Large Packets [draft-ietf-bfd-large-packets-02] (7 pages) - Bidirectional Forwarding Detection (BFD) Management Information Base [draft-ietf-bfd-mib-22] (39 pages) - Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-mpls-07] (12 pages) - BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks [draft-ietf-bfd-mpls-mib-07] (23 pages) - Bidirectional Forwarding Detection (BFD) for Multihop Paths [draft-ietf-bfd-multihop-09] (6 pages) - Bidirectional Forwarding Detection (BFD) for Multipoint Networks [draft-ietf-bfd-multipoint-19] (23 pages) - Bidirectional Forwarding Detection (BFD) Multipoint Active Tails [draft-ietf-bfd-multipoint-active-tail-10] (20 pages) - Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [draft-ietf-bfd-on-lags-04] (11 pages) - Optimizing BFD Authentication [draft-ietf-bfd-optimizing-authentication-13] (9 pages) - Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-rfc5884-clarifications-04] (7 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-rfc9127-bis-04] (58 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) [draft-ietf-bfd-seamless-base-11] (24 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS [draft-ietf-bfd-seamless-ip-06] (8 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases [draft-ietf-bfd-seamless-use-case-08] (15 pages) - Secure BFD Sequence Numbers [draft-ietf-bfd-secure-sequence-numbers-10] (13 pages) - BFD Stability [draft-ietf-bfd-stability-10] (13 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-08] (11 pages) - Unaffiliated BFD Echo [draft-ietf-bfd-unaffiliated-echo-07] (12 pages) - Unsolicited BFD for Sessionless Applications [draft-ietf-bfd-unsolicited-16] (18 pages) - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-11] (7 pages) - Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) [draft-ietf-bfd-vxlan-16] (9 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-yang-17] (64 pages) - BFD for Multipoint Networks [draft-katz-ward-bfd-multipoint-02] (29 pages) - Optimizing BFD Authentication [draft-mahesh-bfd-authentication-01] (7 pages) - BFD in Demand Mode over a Point-to-Point MPLS LSP [draft-mirsky-bfd-mpls-demand-14] (5 pages) - Secure BFD Sequence Numbers [draft-sonal-bfd-secure-sequence-numbers-00] (5 pages) - BFD Multipoint Active Tails. [draft-spallagatti-bfd-multipoint-active-tail-00] (16 pages) - BFD for VXLAN [draft-spallagatti-bfd-vxlan-06] (10 pages) - Bidirectional Forwarding Detection (BFD) on Multi-chassis Ling Aggregation Group (MC-LAG) Interfaces in IP Networks [draft-tanmir-rtgwg-bfd-mc-lag-ip-01] (4 pages) - Bidirectional Forwarding Detection (BFD) on Multi-chassis Ling Aggregation Group (MC-LAG) Interfaces in IP/MPLS Networks [draft-tanmir-rtgwg-bfd-mc-lag-mpls-01] (5 pages) - Yang Data Model for Bidirectional Forwarding Detection (BFD) [draft-zheng-bfd-yang-04] (37 pages) Requests for Comments: RFC5880: Bidirectional Forwarding Detection (BFD) (49 pages) * Updates RFC7419 * Updates RFC7880 * Updates RFC8562 RFC5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) (7 pages) RFC5882: Generic Application of Bidirectional Forwarding Detection (BFD) (17 pages) RFC5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths (6 pages) RFC5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) (12 pages) * Updates RFC7726 RFC7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces (11 pages) RFC7330: Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management (11 pages) RFC7331: Bidirectional Forwarding Detection (BFD) Management Information Base (39 pages) RFC7419: Common Interval Support in Bidirectional Forwarding Detection (8 pages) RFC7726: Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) (7 pages) RFC7880: Seamless Bidirectional Forwarding Detection (S-BFD) (24 pages) RFC7881: Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS (8 pages) RFC7882: Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases (15 pages) RFC8562: Bidirectional Forwarding Detection (BFD) for Multipoint Networks (23 pages) RFC8563: Bidirectional Forwarding Detection (BFD) Multipoint Active Tails (20 pages) RFC8971: Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) (9 pages) RFC9127: YANG Data Model for Bidirectional Forwarding Detection (BFD) (64 pages) * Updates RFC9314 RFC9314: YANG Data Model for Bidirectional Forwarding Detection (BFD) (58 pages) Bit Indexed Explicit Replication (bier) --------------------------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Greg Shepherd Tony Przygienda Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Secretary: Zheng Zhang Mailing Lists: General Discussion: bier@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bier Archive: https://mailarchive.ietf.org/arch/browse/bier/ Description of Working Group: The BIER (Bit Index Explicit Replication) Working Group has defined an architecture [RFC 8279] for multicast forwarding that uses an encapsulation [RFC 8296] that can be used on MPLS or Ethernet transport. The BIER-WG is now chartered to produce Standards Track RFCs, including the status update for RFCs 8279 and 8296. The BIER working group's original charter required the publication of an Informational RFC describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms as well as an analysis of the impact and benefit of the BIER data-plane to the overall Internet architecture. The WG did not produce this RFC, but the goals of that milestone have nevertheless been reached; i.e., the industry has demonstrated interest in deploying BIER and the trade-offs are now well understood. Therefore, BIER is proceeding with work on the Standards Track. The focus of the BIER-WG is on deployment: transition, partial deployments, applicability and management. First and primarily, the BIER-WG will complete its work on: 1) Transition Mechanisms and Partial Deployments: The WG will describe how BIER can be introduced in existing multicast networks to shift multicast delivery, either end-to-end or in part of a network, from mechanisms such as PIM, ng-MVPN, etc. BIER operation in networks where not all routers are BIER capable or have other BIER support constraints should be addressed. How to handle routers supporting BIER with different BitStringLengths and encapsulations should be addressed. Each new mechanism should include an applicability statement that clearly describes its utility and distinctions from already standardized mechanisms. 2) Applicability Statements: The WG will continue to work on documents describing how BIER can be applied, as has been done for MVPN in draft-ietf-bier-mvpn. A document describing applicability to EVPN should be published. 3) Use Case: The WG will produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. 4) Manageability and OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 5) Management models: The WG will work on YANG models to manage BIER. 6) Link-State Routing and BGP extensions: The BIER-WG has already defined the basic information needed to set up the BIER forwarding tables via advertisements in OSPFv2 and ISIS; the extensions to OSPFv3 will be specified. Additional extensions may be needed - for example, to support constraining the topology on which a particular BIER sub-domain operates. Any necessary extensions to the IGP will be specified by the WG as Standards Track, in cooperation with the LSR WG. The BIER-WG shall also specify the extensions to support BIER for BGP when used as an IGP (see RFC 7938) and to provide BIER-specific information in BGP-LS, in cooperation with IDR. The BIER-WG is additionally chartered to start Standards Track work on: 7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be standardized if coordinated with the 6MAN WG and with understood applicability. 8) Forwarding Plane Mechanisms for BIER Traffic Engineering: definition of how the new BIER forwarding plane structures (e.g. BIFT) can be used to support engineered multicast trees. No control-plane work will be done in BIER-WG. The BIER-WG will serve as a forum to discuss how BIER can be applied. The BIER-WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include: * mpls on the associated MPLS-based OAM mechanisms, * lsr on OSPF and ISIS extensions to flood BIER-related information, * babel on Babel extensions to support BIER, * bess and idr on BGP extensions to flood BIER-related information and the applicability of existing BGP-based mechanisms for providing multicast group membership information, * pim and mboned on the applicability of and extensions to PIM, IGMP, and MLD to support BIER operations and transition, * pce on extensions to program BIER forwarding on the BFIRs,and * teas on architecture and control-plane mechanisms to use BIER-TE forwarding mechanisms. Goals and Milestones: Mar 2018 - Published as proposed standard: draft-ietf-bier-mvpn Mar 2018 - Published as proposed standard: draft-ietf-bier-ospf-bier-extensions Mar 2018 - Published as proposed standard: draft-ietf-bier-isis-extensions Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-oam-requirements Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-path-mtu-discovery Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-pmmm-oam Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-ping Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-use-cases Mar 2018 - WGLC: draft-ietf-bier-idr-extensions Mar 2018 - WGLC: draft-ietf-bier-bgp-ls-bier-ext Mar 2018 - WG call for adoption: draft-hfa-bier-pim-signaling Mar 2018 - IETF 101 discuss BIER-TE documents adoption Mar 2018 - IETF 101 discuss and target mechanisms for BIER transition Jul 2018 - Publish as proposed standard: draft-ietf-bier-oam-requirements Jul 2018 - Publish as proposed standard: draft-ietf-bier-path-mtu-discovery Jul 2018 - Publish as proposed standard: draft-ietf-bier-pmmm-oam Jul 2018 - Publish as proposed standard:draft-ietf-bier-ping Jul 2018 - Publish as proposed standard: draft-ietf-bier-use-cases Jul 2018 - WGLC: draft-ietf-bier-evpn Nov 2018 - Target feasibility and solution selection for IPv6 encap Nov 2018 - Progress YANG BIER drafts to WGLC Nov 2018 - Publish document(s) solidifying BAR/IPA complexity Mar 2019 - WGLC BIER-TE drafts Internet-Drafts: - YANG Data Model for BIER Protocol [draft-chh-bier-bier-yang-04] (19 pages) - BIER BFD [draft-hu-bier-bfd-07] (11 pages) - Multicast Using Bit Index Explicit Replication (BIER) [draft-ietf-bier-architecture-08] (43 pages) - Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) [draft-ietf-bier-bar-ipa-13] (6 pages) - BIER BFD [draft-ietf-bier-bfd-03] (12 pages) - BGP Link-State extensions for BIER [draft-ietf-bier-bgp-ls-bier-ext-14] (13 pages) - Supporting BIER in IPv6 Networks (BIERin6) [draft-ietf-bier-bierin6-07] (10 pages) - YANG Data Model for BIER Protocol [draft-ietf-bier-bier-yang-07] (17 pages) - Use of BIER Entropy for Data Center Clos Networks [draft-ietf-bier-entropy-staged-dc-clos-04] (9 pages) - EVPN BUM Using BIER [draft-ietf-bier-evpn-08] (15 pages) - BIER Fast ReRoute [draft-ietf-bier-frr-01] (31 pages) - BGP Extensions for BIER [draft-ietf-bier-idr-extensions-09] (12 pages) - BIER IPv6 Requirements [draft-ietf-bier-ipv6-requirements-09] (7 pages) - Bit Index Explicit Replication (BIER) Support via IS-IS [draft-ietf-bier-isis-extensions-11] (12 pages) - LSR Extensions for BIER over Ethernet [draft-ietf-bier-lsr-ethernet-extensions-04] (13 pages) - LSR Extensions for BIER non-MPLS Encapsulation [draft-ietf-bier-lsr-non-mpls-extensions-01] (13 pages) - BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols [draft-ietf-bier-mld-07] (17 pages) - M-LDP Signaling Through BIER Core [draft-ietf-bier-mldp-signaling-over-bier-02] (9 pages) - Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks [draft-ietf-bier-mpls-encapsulation-12] (24 pages) - BIER MTU Discovery [draft-ietf-bier-mtud-00] (7 pages) - Multicast/BIER As A Service [draft-ietf-bier-multicast-as-a-service-02] (15 pages) - Applicability of BIER Multicast Overlay for Adaptive Streaming Services [draft-ietf-bier-multicast-http-response-06] (17 pages) - Multicast VPN Using Bit Index Explicit Replication (BIER) [draft-ietf-bier-mvpn-11] (17 pages) - An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation [draft-ietf-bier-non-mpls-bift-encoding-04] (6 pages) - Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-oam-requirements-12] (5 pages) - OSPFv2 Extensions for Bit Index Explicit Replication (BIER) [draft-ietf-bier-ospf-bier-extensions-18] (12 pages) - OSPFv3 Extensions for BIER [draft-ietf-bier-ospfv3-extensions-07] (10 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-path-mtu-discovery-14] (8 pages) - BIER Penultimate Hop Popping [draft-ietf-bier-php-10] (8 pages) - PIM Signaling Through BIER Core [draft-ietf-bier-pim-signaling-12] (13 pages) - BIER Ping and Trace [draft-ietf-bier-ping-10] (30 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-13] (9 pages) - BIER Prefix Redistribute [draft-ietf-bier-prefix-redistribute-04] (14 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-ietf-bier-problem-statement-00] (13 pages) - BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover [draft-ietf-bier-source-protection-04] (11 pages) - Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-arch-13] (43 pages) - IS-IS Extensions for BIER-TE [draft-ietf-bier-te-isis-05] (8 pages) - OSPFv2 Extensions for BIER-TE [draft-ietf-bier-te-ospf-05] (9 pages) - OSPFv3 Extensions for BIER-TE [draft-ietf-bier-te-ospfv3-05] (7 pages) - Tethering A BIER Router To A BIER incapable Router [draft-ietf-bier-tether-03] (9 pages) - A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-yang-05] (19 pages) - BIER Use Cases [draft-ietf-bier-use-cases-12] (17 pages) - BIER Use Cases [draft-kumar-bier-use-cases-02] (12 pages) - BIER Ping and Trace [draft-kumarzheng-bier-ping-03] (26 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-mirsky-bier-path-mtu-discovery-01] (8 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-mirsky-bier-pmmm-oam-01] (7 pages) - BIER support via ISIS [draft-przygienda-bier-isis-ranges-02] (13 pages) - OSPF Extensions For BIER [draft-psenak-ospf-bier-extensions-02] (8 pages) - Multicast VPN Using BIER [draft-rosen-l3vpn-mvpn-bier-02] (10 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-shepherd-bier-problem-statement-02] (13 pages) - Multicast using Bit Index Explicit Replication [draft-wijnands-bier-architecture-05] (30 pages) - Encapsulation for Bit Index Explicit Replication in MPLS Networks [draft-wijnands-mpls-bier-encapsulation-02] (13 pages) - Supporting BIER in IPv6 Networks (BIERin6) [draft-zhang-bier-bierin6-09] (11 pages) Requests for Comments: RFC8279: Multicast Using Bit Index Explicit Replication (BIER) (43 pages) RFC8296: Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks (24 pages) RFC8401: Bit Index Explicit Replication (BIER) Support via IS-IS (12 pages) * Updates RFC9272 RFC8444: OSPFv2 Extensions for Bit Index Explicit Replication (BIER) (12 pages) * Updates RFC9272 RFC8556: Multicast VPN Using Bit Index Explicit Replication (BIER) (17 pages) RFC9262: Tree Engineering for Bit Index Explicit Replication (BIER-TE) (43 pages) RFC9272: Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) (6 pages) Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Daniele Ceccarelli Fatai Zhang Luis M. Contreras Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Secretary: Haomian Zheng Mailing Lists: General Discussion: ccamp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccamp Archive: https://mailarchive.ietf.org/arch/browse/ccamp/ Description of Working Group: The CCAMP working group is responsible for standardizing a common control plane and a separate common measurement plane for non-packet technologies found in the Internet and in the networks of telecom service providers (ISPs and SPs). Examples of the devices in such networks include photonic cross-connects, OEO switches, ROADMs, TDM switches, microwave links, and Ethernet switches. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. The working group develops extensions to core Traffic Engineering protocols that are under the care of other working groups. The CCAMP working group will coordinate with the TEAS working group to ensure that extensions that can be generalized for use with more than one technology are made appropriately, and with the working groups that have responsibility for the specific protocols. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling in technology-specific networks. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Maintenance and extension of the Link Management Protocol (LMP). - Functional specification of extensions for GMPLS-related routing (OSPF, ISIS) and signaling (RSVP-TE) protocols required for path establishment and maintenance in non-packet, technology-specific networks. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols and the TEAS working group has the responsibility to determine whether such protocol extensions should be generalized for Traffic Engineering in any network. This may include protocol work to support data planes that have already been approved by another Standards Development Organization. Note that the specification or modification of data planes is out of scope of this working group - Definition of management objects (e.g., as part of MIB modules or YANG models) and control of OAM techniques relevant to the protocols and extensions specified within the WG. The OAM work will be synchronized with the LIME WG - Describe non-packet-specific aspects of traffic engineering including for multi-areas/multi-AS/multi-layer scenarios and define protocol extensions in cooperation with the TEAS and PCE working groups. - Define how the properties of network resources gathered by a measurement protocol (or by other means such as configuration) can be distributed in existing routing protocols, such as OSPF, IS-IS, and BGP-LS. CCAMP will work with the WGs that supervise these The CCAMP WG currently works on the following tasks: - Protocol extensions in support of WSON. - Protocol extensions in support of flexible grid lambda networks. - Maintenance of existing protocol extensions for non-packet technology-specific networks (Ethernet, TDM, OTN) already specified by CCAMP. - Maintenance of LMP. Goals and Milestones: May 2022 - Submit YANG modelling for flexi grid draft to IESG for review Jun 2022 - Submit T-NBI model applicability to IESG for review Jul 2022 - First version of YANG model of Ethernet Tunnel Working Group drafts Jul 2022 - Submit YANG model of OTN topology & Flexi-grid topology to IESG for review Jul 2022 - Submit YANG model of Layer 1 Types to IESG for review Aug 2022 - First version of client tunnel YANG model working group draft Aug 2022 - Submit L1CSM YANG model to IESG for review Sep 2022 - Submit DWDM Interface YANG model to IESG for review Oct 2022 - First version of client signal performance monitoring YANG model working group draft Nov 2022 - Submit OTN tunnel model to IESG for review Nov 2022 - Submit Microwave topology model to IESG for review Dec 2022 - Submit Info Model for WSON with impairments validation to IESG for review Dec 2022 - Submit YANG model of WSON Impairment Topology YANG model to IESG for review; Feb 2023 - Submit OTN slicing YANG model to IESG for review Mar 2023 - Submit DWDM interface LMP and YANG to IESG for review Aug 2023 - Submit client signal YANG model to IESG for review Done - Post strawman WG goals and charter Done - Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done - Build appropriate design teams Done - Submit WG document defining common measurement plane protocol Done - Submit WG document defining path setup portions of common control plane protocol Done - Submit LMP MIB to IESG Done - Submit protection & restoration documents to IESG Done - Submit GMPLS MIBs to IESG Done - Submit ASON signaling requirements doc to IESG Done - Submit ASON routing requirements doc to IESG Done - Produce CCAMP WG document for multi-area/AS signaling and routing Done - Produce CCAMP WG document for generic tunnel tracing protocol Done - Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done - First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done - Submit ASON Routing evaluation I-D for IESG review Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D MPLS to GMPLS migration strategies Done - First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Done - First version WG I-D for Evaluation of existing protocols for MLN/MRN Done - First version of WG I-D for ASON Routing solutions Done - Submit Per-domain path computation signaling I-D for IESG review Done - Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done - First version WG I-D for Protocol solutions for MLN/MRN Done - Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done - Submit GMPLS signaling in support of Call Management I-D for IESG review Done - First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - First version of WG I-D for OSPF-TE/GMPLS MIB module Done - Submit GMPLS/ASON lexicography I-D for IESG review Done - Submit LSP Stitching I-D for IESG review Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done - First version WG I-D GMPLS OAM Requirements Done - Submit GMPLS routing and signaling interoperability advice I-D for IESG review Done - Submit MPLS to GMPLS migration strategies I-D for IESG review Done - Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Done - Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Done - Submit Evaluation of existing protocols for MLN/MRN for IESG review Done - Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Done - First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Done - Submit Protocol solutions for MLN/MRN I-D for IESG review Done - First version of WSON routing related Working Group drafts Done - Submit Ethernet related drafts for IESG review Done - Submit hierarchy bis for IESG review Done - First version of Working Group draft providing Control Plane Framework for MPLS-TP Done - Submit VCAT/LCAS with GMPLS for IESG review Done - Submit TE MIB module IESG review Done - First version of G.709 enhancements framework Working Group drafts Done - First version of LMP Negotiation Working Group draft Done - Submit WSON framework draft for IESG review Done - Submit Lambda labels draft for IESG review Done - First version of OAM configuration solutions Working Group draft Done - Submit WSON impairment framework draft for IESG review Done - First version of G.709 enhancements solutions Working Group drafts Done - First version of Working Group draft defining RSVP-TE extensions for MPLS-TP Done - Submit Control Plane Framework for MPLS-TP for IESG review Done - Submit RSVP-TE extensions for MPLS-TP for IESG review Done - Submit OAM configuration framework for IESG review Done - Submit LMP Negotiation for IESG review Done - Submit G.709 enhancements solutions for IESG review Done - Submit G.709 enhancements framework for IESG review Done - First version flexigrid requirements/framework Working Group draft Done - Submit first set of OAM configuration solutions for IESG review Done - Submit last OAM configuration solutions for IESG review Done - Submit WSON routing related drafts for IESG review Done - Submit WSON signaling related draft for IESG review Done - Submit OTN signal types update and sub registry drafts to IESG for review Done - Submit flexi grid framework to IESG for review Done - First draft of technology specific version of signaling and routing bandwidth availability working group draft. Done - First version of YANG modelling for flexi grid Working Group draft Done - Submit flexi grid label, signaling and routing extensions to IESG for review Done - Submit technology specific version of signaling and routing bandwidth availability draft to IESG for review Done - Recharter or close Working Group Done - First version of YANG model of Ethernet Topology Working Group drafts Done - First version of OTN network slicing working group draft Done - Submit applicability of gmpls to OTN beyond 100G to IETF for review Internet-Drafts: - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Additional Signal Types in G.709 OTN [draft-ali-ccamp-additional-signal-type-g709v3-05] (4 pages) - IANA Allocation Procedures for OTN Signal Type Subregistry to the GMPLS Signaling Parameters Registry [draft-ali-ccamp-otn-signal-type-subregistry-02] (4 pages) - Network Assigned Upstream-Label [draft-beeram-ccamp-network-assigned-upstream-label-03] (9 pages) - Revised Definition of The GMPLS Switching Capability and Type Fields [draft-berger-ccamp-swcaps-update-02] (9 pages) - Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks [draft-ceccarelli-ccamp-gmpls-ospf-g709-07] (29 pages) - Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) [draft-dhody-ccamp-rsvp-te-domain-subobjects-02] (17 pages) - A YANG Data Model for Layer 0 Types - Revision 2 [draft-esdih-ccamp-layer0-types-ext-01] (28 pages) - Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks [draft-farrel-interconnected-te-info-exchange-07] (56 pages) - A Yang Data Model for L1 Connectivity Service Model (L1CSM) [draft-fioccola-ccamp-l1csm-yang-01] (22 pages) - YANG Data Models for requesting Path Computation in Optical Networks [draft-gbb-ccamp-optical-path-computation-yang-02] (35 pages) - A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) [draft-gbb-ccamp-otn-path-computation-yang-02] (19 pages) - RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) [draft-ietf-ccamp-additional-signal-type-g709v3-04] (5 pages) - A YANG Data Model for Alarm Management [draft-ietf-ccamp-alarm-module-09] (82 pages) - RSVP ASSOCIATION Object Extensions [draft-ietf-ccamp-assoc-ext-06] (17 pages) - Usage of the RSVP ASSOCIATION Object [draft-ietf-ccamp-assoc-info-03] (11 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-02] (14 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03] (11 pages) - Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects [draft-ietf-ccamp-attribute-bnf-02] (8 pages) - Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership [draft-ietf-ccamp-automesh-04] (15 pages) - A YANG Data Model for Bandwidth Availability Topology [draft-ietf-ccamp-bwa-topo-yang-00] (12 pages) - A YANG Data Model for Transport Network Client Signals [draft-ietf-ccamp-client-signal-yang-08] (57 pages) - Data Channel Status Confirmation Extensions for the Link Management Protocol [draft-ietf-ccamp-confirm-data-channel-status-09] (15 pages) - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE [draft-ietf-ccamp-crankback-06] (38 pages) - Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks [draft-ietf-ccamp-dpm-08] (29 pages) - Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application [draft-ietf-ccamp-dwdm-if-lmp-07] (15 pages) - A framework for Management and Control of DWDM optical interface parameters [draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13] (31 pages) - A YANG model to manage the optical interface parameters for an external transponder in a WDM network [draft-ietf-ccamp-dwdm-if-param-yang-09] (32 pages) - A YANG Data Model for Ethernet TE Topology [draft-ietf-ccamp-eth-client-te-topo-yang-04] (66 pages) - Service Provider Requirements for Ethernet control with GMPLS [draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02] (20 pages) - Ethernet Traffic Parameters [draft-ietf-ccamp-ethernet-traffic-parameters-10] (14 pages) - YANG Data Model for FlexE Management [draft-ietf-ccamp-flexe-yang-cm-01] (20 pages) - GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks [draft-ietf-ccamp-flexible-grid-ospf-ext-09] (17 pages) - RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks [draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05] (12 pages) - Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks [draft-ietf-ccamp-flexi-grid-fwk-07] (42 pages) - Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers [draft-ietf-ccamp-flexigrid-lambda-label-05] (14 pages) - A YANG Data Model for Flexi-Grid Media Channels [draft-ietf-ccamp-flexigrid-media-channel-yang-04] (62 pages) - A YANG Data Model for Flexi-Grid Tunnels [draft-ietf-ccamp-flexigrid-tunnel-yang-02] (41 pages) - A YANG Data Model for Flexi-Grid Optical Networks [draft-ietf-ccamp-flexigrid-yang-14] (64 pages) - General Network Element Constraint Encoding for GMPLS-Controlled Networks [draft-ietf-ccamp-general-constraint-encode-20] (28 pages) - Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-addressing-08] (23 pages) - GMPLS - Communication of Alarm Information [draft-ietf-ccamp-gmpls-alarm-spec-06] (19 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Architecture [draft-ietf-ccamp-gmpls-architecture-07] (69 pages) - A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture [draft-ietf-ccamp-gmpls-ason-lexicography-06] (19 pages) - Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-reqts-07] (16 pages) - Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements [draft-ietf-ccamp-gmpls-ason-routing-eval-03] (22 pages) - OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing [draft-ietf-ccamp-gmpls-ason-routing-ospf-09] (29 pages) - Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-routing-reqts-05] (22 pages) - Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions [draft-ietf-ccamp-gmpls-dcsc-channel-ext-04] (10 pages) - GMPLS Signaling Procedure for Egress Control [draft-ietf-ccamp-gmpls-egress-control-03] (5 pages) - Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework [draft-ietf-ccamp-gmpls-ethernet-arch-09] (20 pages) - Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) [draft-ietf-ccamp-gmpls-ethernet-pbb-te-06] (20 pages) - Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-04] (15 pages) - Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers [draft-ietf-ccamp-gmpls-g-694-lambda-labels-11] (15 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control [draft-ietf-ccamp-gmpls-g709-09] (23 pages) - Framework for GMPLS and PCE Control of G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-g709-framework-15] (26 pages) - OSPF-TE Extensions for General Network Element Constraints [draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10] (12 pages) - Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base [draft-ietf-ccamp-gmpls-lsr-mib-15] (42 pages) - Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) [draft-ietf-ccamp-gmpls-mef-uni-03] (10 pages) - Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-eval-06] (25 pages) - Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-extensions-12] (24 pages) - Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) [draft-ietf-ccamp-gmpls-mln-reqs-11] (28 pages) - OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-oam-requirements-00] (13 pages) - Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-ospf-g709v3-13] (36 pages) - Traffic Engineering Database Management Information Base in support of GMPLS [draft-ietf-ccamp-gmpls-ospf-mib-01] (22 pages) - Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network [draft-ietf-ccamp-gmpls-otn-b100g-applicability-15] (14 pages) - Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model [draft-ietf-ccamp-gmpls-overlay-05] (13 pages) - Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) [draft-ietf-ccamp-gmpls-recovery-analysis-05] (47 pages) - RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery [draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04] (47 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification [draft-ietf-ccamp-gmpls-recovery-functional-04] (23 pages) - Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-recovery-terminology-06] (22 pages) - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-routing-09] (27 pages) - Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-rsvp-te-ason-04] (40 pages) - Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls [draft-ietf-ccamp-gmpls-rsvp-te-call-04] (31 pages) - GMPLS Segment Recovery [draft-ietf-ccamp-gmpls-segment-recovery-03] (25 pages) - GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-signaling-g709v3-12] (27 pages) - Generalized MPLS Signaling - Implementation Survey [draft-ietf-ccamp-gmpls-signaling-survey-03] (101 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-gmpls-sonet-sdh-08] (26 pages) - Generalized Multiprotocol Label Switching Extensions to Control Non-Standard SONET and SDH Features [draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03] (14 pages) - Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management [draft-ietf-ccamp-gmpls-tc-mib-11] (9 pages) - Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-15] (40 pages) - Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [draft-ietf-ccamp-gmpls-te-mib-16] (60 pages) - Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-vcat-lcas-13] (21 pages) - Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures [draft-ietf-ccamp-gr-description-04] (18 pages) - Link Management Protocol Extensions for Grid Property Negotiation [draft-ietf-ccamp-grid-property-lmp-04] (12 pages) - A YANG Data Model for Interface Reference Topology [draft-ietf-ccamp-if-ref-topo-yang-00] (11 pages) - A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering [draft-ietf-ccamp-inter-domain-framework-06] (22 pages) - A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) [draft-ietf-ccamp-inter-domain-pd-path-comp-06] (21 pages) - Analysis of Inter-Domain Label Switched Path (LSP) Recovery [draft-ietf-ccamp-inter-domain-recovery-analysis-05] (26 pages) - Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-ccamp-inter-domain-rsvp-te-07] (25 pages) - ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-ccamp-isis-interas-te-extension-04] (19 pages) - A YANG Data Model for L1 Connectivity Service Model (L1CSM) [draft-ietf-ccamp-l1csm-yang-23] (19 pages) - A YANG Data Model for Layer 0 Types [draft-ietf-ccamp-layer0-types-09] (20 pages) - A YANG Data Model for Layer 0 Types - Revision 2 [draft-ietf-ccamp-layer0-types-ext-01] (27 pages) - A YANG Data Model for Layer 1 Types [draft-ietf-ccamp-layer1-types-15] (51 pages) - Link Management Protocol (LMP) [draft-ietf-ccamp-lmp-10] (86 pages) - Link Management Protocol Behavior Negotiation and Configuration Modifications [draft-ietf-ccamp-lmp-behavior-negotiation-11] (11 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-lmp-mib-10] (82 pages) - Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages [draft-ietf-ccamp-lmp-test-sonet-sdh-04] (15 pages) - Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems [draft-ietf-ccamp-lmp-wdm-03] (16 pages) - Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) [draft-ietf-ccamp-loose-path-reopt-02] (14 pages) - Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks [draft-ietf-ccamp-lsp-dppm-11] (44 pages) - Procedures for Dynamically Signaled Hierarchical Label Switched Paths [draft-ietf-ccamp-lsp-hierarchy-bis-08] (30 pages) - Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) [draft-ietf-ccamp-lsp-stitching-06] (19 pages) - A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters [draft-ietf-ccamp-microwave-framework-07] (20 pages) - Framework for MPLS-TE to GMPLS Migration [draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05] (19 pages) - Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks [draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04] (15 pages) - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks [draft-ietf-ccamp-mpls-graceful-shutdown-13] (11 pages) - MPLS Transport Profile (MPLS-TP) Control Plane Framework [draft-ietf-ccamp-mpls-tp-cp-framework-06] (57 pages) - A YANG Data Model for Microwave Topology [draft-ietf-ccamp-mw-topo-yang-05] (44 pages) - A YANG Data Model for Microwave Radio Link [draft-ietf-ccamp-mw-yang-13] (53 pages) - A YANG Data Model for Network Hardware Inventory [draft-ietf-ccamp-network-inventory-yang-01] (42 pages) - GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration [draft-ietf-ccamp-oam-configuration-fwk-13] (24 pages) - TITLE: Optical Link Interface Requirements [draft-ietf-ccamp-oli-reqts-00] (13 pages) - A YANG Data Model for Optical Impairment-aware Topology [draft-ietf-ccamp-optical-impairment-topology-yang-12] (125 pages) - YANG Data Models for requesting Path Computation in Optical Networks [draft-ietf-ccamp-optical-path-computation-yang-01] (35 pages) - OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth [draft-ietf-ccamp-ospf-availability-extension-13] (10 pages) - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-ospf-gmpls-extensions-12] (11 pages) - OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-ccamp-ospf-interas-te-extension-06] (17 pages) - Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) [draft-ietf-ccamp-otn-g709-info-model-13] (23 pages) - A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) [draft-ietf-ccamp-otn-path-computation-yang-01] (20 pages) - IANA Allocation Procedures for the GMPLS OTN Signal Type Registry [draft-ietf-ccamp-otn-signal-type-subregistry-05] (4 pages) - A YANG Data Model for Optical Transport Network Topology [draft-ietf-ccamp-otn-topo-yang-16] (80 pages) - OTN Tunnel YANG Model [draft-ietf-ccamp-otn-tunnel-model-18] (48 pages) - Resource Reservation Protocol (RSVP) Extensions for Path Key Support [draft-ietf-ccamp-path-key-ero-04] (14 pages) - Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network [draft-ietf-ccamp-pc-and-sc-reqs-06] (11 pages) - RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network [draft-ietf-ccamp-pc-spc-rsvpte-ext-07] (23 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-rfc3946bis-01] (25 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-rfc4327bis-01] (83 pages) - Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rfc4420bis-03] (22 pages) - Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols [draft-ietf-ccamp-rfc5787bis-06] (30 pages) - A YANG Data Model for Layer 0 Types [draft-ietf-ccamp-rfc9093-bis-04] (47 pages) - Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement [draft-ietf-ccamp-rsvp-node-id-based-hello-03] (7 pages) - RSVP Resource Sharing Remote Identification Association [draft-ietf-ccamp-rsvp-resource-sharing-02] (11 pages) - Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart [draft-ietf-ccamp-rsvp-restart-ext-09] (24 pages) - Ethernet Traffic Parameters with Availability Information [draft-ietf-ccamp-rsvp-te-bandwidth-availability-16] (13 pages) - GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration [draft-ietf-ccamp-rsvp-te-eth-oam-ext-13] (18 pages) - Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rsvp-te-exclude-route-06] (27 pages) - Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE [draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16] (32 pages) - GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06] (16 pages) - Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-info-24] (23 pages) - Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-wson-encode-28] (37 pages) - Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) [draft-ietf-ccamp-rwa-wson-framework-12] (51 pages) - Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks [draft-ietf-ccamp-sdhsonet-control-05] (35 pages) - Revised Definition of the GMPLS Switching Capability and Type Fields [draft-ietf-ccamp-swcaps-update-03] (9 pages) - IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities [draft-ietf-ccamp-te-node-cap-05] (13 pages) - Tracing Requirements for Generic Tunnels [draft-ietf-ccamp-tracereq-05] (9 pages) - A Transport Network View of the Link Management Protocol (LMP) [draft-ietf-ccamp-transport-lmp-02] (18 pages) - Transport Northbound Interface Applicability Statement [draft-ietf-ccamp-transport-nbi-app-statement-16] (92 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-ietf-ccamp-transport-nbi-use-cases-01] (28 pages) - Generic Tunnel Tracing Protocol (GTTP) Specification [draft-ietf-ccamp-tunproto-01] (36 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-01] (37 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments [draft-ietf-ccamp-wson-impairments-10] (31 pages) - Information Encoding for WSON with Impairments Validation [draft-ietf-ccamp-wson-iv-encode-02] (11 pages) - Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-ietf-ccamp-wson-iv-info-12] (19 pages) - GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signal-compatibility-ospf-17] (12 pages) - Signaling Extensions for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signaling-12] (16 pages) - A Yang Data Model for WSON Tunnel [draft-ietf-ccamp-wson-tunnel-model-08] (44 pages) - A YANG Data Model for Wavelength Switched Optical Networks (WSONs) [draft-ietf-ccamp-wson-yang-28] (56 pages) - Framework and Data Model for OTN Network Slicing [draft-ietf-ccamp-yang-otn-slicing-04] (44 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions [draft-ietf-mpls-generalized-cr-ldp-07] (23 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-mpls-generalized-rsvp-te-09] (42 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description [draft-ietf-mpls-generalized-signaling-09] (34 pages) - A framework for Management and Control of DWDM optical interface parameters [draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-01] (29 pages) - A Yang Data Model for WSON Optical Networks [draft-lee-ccamp-wson-yang-04] (17 pages) - Link Management Protocol Extensions for Grid Property Negotiation [draft-li-ccamp-grid-property-lmp-03] (12 pages) - OSPF Routing Extension for Links with Variable Discrete Bandwidth [draft-long-ccamp-ospf-availability-extension-04] (8 pages) - RSVP-TE Signaling Extension for Links with Variable Discrete Bandwidth [draft-long-ccamp-rsvp-te-bandwidth-availability-05] (11 pages) - Information Encoding for WSON with Impairments Validation [draft-martinelli-ccamp-wson-iv-encode-09] (12 pages) - Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-martinelli-ccamp-wson-iv-info-05] (19 pages) - A YANG Data Model for Microwave Radio Link [draft-mwdt-ccamp-mw-yang-01] (37 pages) - Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks [draft-ogrcetal-ccamp-flexi-grid-fwk-03] (30 pages) - OTN Tunnel YANG Model [draft-sharma-ccamp-otn-tunnel-model-02] (21 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-tnbidt-ccamp-transport-nbi-use-cases-03] (28 pages) - YANG Alarm Module [draft-vallin-ccamp-alarm-module-01] (58 pages) - YANG Data Model for FlexE Management [draft-wang-ccamp-flexe-yang-cm-04] (20 pages) - A YANG Data Model for Network Hardware Inventory [draft-yg3bp-ccamp-network-inventory-yang-02] (38 pages) - GMPLS OSPF-TE Extensions in support of Flexible Grid [draft-zhang-ccamp-flexible-grid-ospf-ext-04] (14 pages) - RSVP-TE Signaling Extensions in support of Flexible Grid [draft-zhang-ccamp-flexible-grid-rsvp-te-ext-04] (12 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control [draft-zhang-ccamp-gmpls-evolving-g709-09] (24 pages) - RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- based LSP Setup and Teardown [draft-zhang-ccamp-gmpls-resource-sharing-proc-03] (19 pages) - RSVP-TE Identification of MPLS-TP Co-Routed Bidirectional LSP [draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05] (8 pages) - RSVP-TE Extensions for Collecting SRLG Information [draft-zhang-ccamp-srlg-fa-configuration-05] (9 pages) - A YANG Data Model for Transport Network Client Signals [draft-zheng-ccamp-client-signal-yang-07] (50 pages) - A YANG Data Model for Ethernet TE Topology [draft-zheng-ccamp-client-topo-yang-10] (66 pages) Requests for Comments: RFC3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description (34 pages) * Updates RFC4201 * Updates RFC4328 * Updates RFC4872 * Updates RFC6002 * Updates RFC6003 * Updates RFC6205 * Updates RFC7074 * Updates RFC7699 * Updates RFC8359 RFC3472: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions (23 pages) * Updates RFC3468 * Updates RFC4201 RFC3473: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (42 pages) * Updates RFC4003 * Updates RFC4201 * Updates RFC4420 * Updates RFC4783 * Updates RFC4874 * Updates RFC4873 * Updates RFC4974 * Updates RFC5063 * Updates RFC5151 * Updates RFC5420 * Updates RFC6002 * Updates RFC6003 * Updates RFC6780 * Updates RFC8359 RFC3609: Tracing Requirements for Generic Tunnels (9 pages) RFC3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture (69 pages) * Updates RFC6002 RFC3946: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (26 pages) * Obsoletes RFC4606 RFC4003: GMPLS Signaling Procedure for Egress Control (5 pages) RFC4139: Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) (16 pages) RFC4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (27 pages) * Updates RFC6001 * Updates RFC6002 * Updates RFC7074 RFC4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (11 pages) * Updates RFC6001 * Updates RFC6002 * Updates RFC7074 RFC4204: Link Management Protocol (LMP) (86 pages) * Updates RFC6898 RFC4207: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages (15 pages) * Updates RFC6898 RFC4208: Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model (13 pages) RFC4209: Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems (16 pages) * Updates RFC6898 RFC4257: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks (35 pages) RFC4258: Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) (22 pages) RFC4327: Link Management Protocol (LMP) Management Information Base (MIB) (82 pages) * Obsoletes RFC4631 RFC4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control (23 pages) * Updates RFC7139 RFC4394: A Transport Network View of the Link Management Protocol (LMP) (18 pages) RFC4397: A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture (19 pages) RFC4426: Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification (23 pages) RFC4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) (22 pages) RFC4428: Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) (47 pages) RFC4558: Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement (7 pages) RFC4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (25 pages) * Updates RFC6344 RFC4631: Link Management Protocol (LMP) Management Information Base (MIB) (83 pages) RFC4652: Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements (22 pages) RFC4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering (22 pages) RFC4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) (14 pages) RFC4783: GMPLS - Communication of Alarm Information (19 pages) RFC4801: Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management (9 pages) RFC4802: Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base (60 pages) RFC4803: Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base (42 pages) RFC4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery (47 pages) * Updates RFC4873 * Updates RFC6780 * Updates RFC9270 RFC4873: GMPLS Segment Recovery (25 pages) * Updates RFC9270 RFC4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (27 pages) * Updates RFC6001 * Updates RFC8390 RFC4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE (38 pages) RFC4972: Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership (15 pages) RFC4974: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls (31 pages) * Updates RFC6001 RFC4990: Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks (23 pages) RFC5063: Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart (24 pages) RFC5073: IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities (13 pages) RFC5145: Framework for MPLS-TE to GMPLS Migration (19 pages) RFC5146: Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks (15 pages) RFC5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) (19 pages) RFC5151: Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions (25 pages) RFC5152: A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) (21 pages) RFC5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) (28 pages) RFC5298: Analysis of Inter-Domain Label Switched Path (LSP) Recovery (26 pages) RFC5316: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (19 pages) * Obsoletes RFC9346 RFC5339: Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) (25 pages) RFC5392: OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (17 pages) RFC5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) (22 pages) * Updates RFC6510 RFC5467: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (14 pages) * Obsoletes RFC6387 RFC5493: Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network (11 pages) RFC5495: Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures (18 pages) RFC5553: Resource Reservation Protocol (RSVP) Extensions for Path Key Support (14 pages) RFC5787: OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing (29 pages) * Obsoletes RFC6827 RFC5814: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks (44 pages) RFC5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks (11 pages) RFC5818: Data Channel Status Confirmation Extensions for the Link Management Protocol (15 pages) * Updates RFC6898 RFC5828: Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework (20 pages) RFC5852: RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network (23 pages) RFC6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) (24 pages) RFC6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (10 pages) RFC6003: Ethernet Traffic Parameters (14 pages) RFC6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching (15 pages) RFC6005: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) (10 pages) RFC6060: Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) (20 pages) RFC6107: Procedures for Dynamically Signaled Hierarchical Label Switched Paths (30 pages) RFC6163: Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) (51 pages) RFC6205: Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers (15 pages) * Updates RFC7699 * Updates RFC8359 RFC6344: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) (21 pages) RFC6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework (57 pages) RFC6387: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (11 pages) RFC6510: Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects (8 pages) RFC6566: A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments (31 pages) RFC6689: Usage of the RSVP ASSOCIATION Object (11 pages) RFC6777: Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks (29 pages) RFC6780: RSVP ASSOCIATION Object Extensions (17 pages) RFC6825: Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS (40 pages) RFC6827: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols (30 pages) RFC6898: Link Management Protocol Behavior Negotiation and Configuration Modifications (11 pages) RFC7062: Framework for GMPLS and PCE Control of G.709 Optical Transport Networks (26 pages) RFC7074: Revised Definition of the GMPLS Switching Capability and Type Fields (9 pages) RFC7096: Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) (23 pages) RFC7138: Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks (36 pages) RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks (27 pages) * Updates RFC7892 RFC7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration (24 pages) RFC7369: GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration (18 pages) RFC7446: Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks (23 pages) RFC7487: Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE (32 pages) RFC7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks (28 pages) RFC7580: OSPF-TE Extensions for General Network Element Constraints (12 pages) RFC7581: Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks (37 pages) RFC7688: GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks (12 pages) RFC7689: Signaling Extensions for Wavelength Switched Optical Networks (16 pages) RFC7698: Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks (42 pages) RFC7699: Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers (14 pages) RFC7792: RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks (12 pages) RFC7892: IANA Allocation Procedures for the GMPLS OTN Signal Type Registry (4 pages) RFC7963: RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) (5 pages) RFC8330: OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth (10 pages) RFC8363: GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks (17 pages) RFC8432: A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters (20 pages) RFC8561: A YANG Data Model for Microwave Radio Link (53 pages) RFC8625: Ethernet Traffic Parameters with Availability Information (13 pages) RFC8632: A YANG Data Model for Alarm Management (82 pages) RFC9093: A YANG Data Model for Layer 0 Types (20 pages) RFC9094: A YANG Data Model for Wavelength Switched Optical Networks (WSONs) (56 pages) RFC9376: Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network (14 pages) Computing-Aware Traffic Steering (cats) --------------------------------------- Charter Last Modified: 2023-05-18 Current Status: Active Chairs: Adrian Farrel Peng Liu Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Secretary: Cheng Li Mailing Lists: General Discussion: cats@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cats/ Archive: https://mailarchive.ietf.org/arch/browse/cats/ Description of Working Group: Computing-Aware Traffic Steering (cats) Many service architectures create multiple service instances. These instances are often geographically distributed to multiple sites, and a single site may support multiple instances of a service. The services are provided on computing platforms and are generically referred to as "compute services". The CATS (Computing-Aware Traffic Steering) working group (WG) is chartered to consider the problem of how the network edge can steer traffic between clients of a service and sites offering the service. Since, for some services (for example, the evolution of networked AR/VR, and deployment of autonomous and networked vehicles), the performance experienced by clients will depend on both network metrics such as bandwidth and latency, and compute metrics such as processing, storage capabilities, and capacity, there is a need for a solution that can optimize how a network edge node steers traffic based on these metrics, as appropriate to the service. Although the specific optimization function will likely differ between services, implementations, and deployments, there is a need for a general framework for the distribution of compute and network metrics and transport of traffic from network edge to service instance. It also is likely that some set of common metrics can be identified. The CATS WG will concern itself with these issues. The IETF is working on exposing network conditions to endpoints (notably ALTO) and load balancing/service selection at layers 4 and 7 (for example, related to the selection of SIP servers). Specific characteristics that may distinguish CATS from other work include the desire to integrate both network and compute conditions in the optimization function that informs the steering applied by the network edge nodes, and the desire to operate that function on nodes within the service provider's network, logically separated from service operation. Exposure of network and compute conditions to applications is not in the scope of CATS. Because of their experience and prior work in collecting and exposing network conditions for use in selecting paths and servers, the CATS WG will seek advice and expertise from the ART and TSV areas. The assumed model for the CATS WG is an overlay network, where a network edge node makes a decision based on the metrics of interest, and then steers the traffic to a node that serves a service instance, for example using a tunnel. The CATS WG will focus on single domain models. Architectures that require the underlay network to be service-aware are out of scope. The CATS WG will analyze the problem in further detail and produce an architecture for a solution. Ideally, that architecture will be one that can be instantiated using existing technologies. The CATS WG is chartered to work on the following items: o Groundwork may be documented via a set of informational Internet- Drafts, not necessarily for publication as RFCs: * Problem statement for the need to consider both network and computing resource status. * Use cases for steering traffic from applications that have critical SLAs that would benefit from the integrated consideration of network and computing resource status. * Requirements for commonly agreed computing metrics and their distribution across the overlay network, as well as the appropriate frequency and scope of distribution. o Overall CATS framework & architecture: * This work encompasses the various building blocks and their interactions, realizing a CATS control and data plane that addresses the identified problems and requirements in the groundwork, including methods for distributing necessary information to utilize the identified metrics in CATS use cases. This will also cover OAM, scalability, and security aspects. o Additional groundwork to include: * Analyze the suitability and usefulness of computing and networking metrics for traffic steering decisions in CATS with a CATS metrics ontology as a possible outcome. * Analyze methods for distributing the necessary information to utilize the identified metrics in CATS use cases. o Applicability of existing tools and mechanisms: * Analysis of implementing the CATS control and data plane using existing mechanisms, including identifying the limitations of existing tools in fulfilling requirements. * Study potential new approaches for the CATS control and data plane solution that can fill the identified gaps in existing tools and solutions. * Study FCAPS (fault, configuration, accounting, performance, security) requirements, mechanisms, and suitability of existing messaging protocols (NETCONF) and data models (YANG). Goals and Milestones: Jul 2023 - Adopt the CATS Problem Statement, Use Cases, Gap Analysis, and Requirements documents Jul 2024 - Adopt the CATS Framework and Architecture document Nov 2025 - Submit the CATS Framework and Architecture document to the IESG for publication as Informational Internet-Drafts: No Requests for Comments Deterministic Networking (detnet) --------------------------------- Charter Last Modified: 2023-04-14 Current Status: Active Chairs: János Farkas Lou Berger Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Tech Advisor: David Black Secretary: Ethan Grossman Mailing Lists: General Discussion: detnet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/detnet Archive: https://mailarchive.ietf.org/arch/browse/detnet/ Description of Working Group: The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. The Working Group addresses Layer 3 aspects in support of applications requiring deterministic networking. The Working Group collaborates with IEEE802.1 Time-Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being considered by the IEEE 802.1 TSN Task Group. The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also can include private WANs. The DetNet WG will not spend energy on solutions for large groups of domains such as the Internet. The Working Group is responsible for the overall DetNet architecture and DetNet-specific specifications that encompasses the data plane, OAM (Operations, Administration, and Maintenance), time synchronization, management, control, and security aspects which are required to enable a multi-hop path, and forwarding along the path, with the deterministic properties of controlled latency, low packet loss, low packet delay variation, and high reliability. The work applies to point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required. The work covers the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes. Layer 3 data plane technologies that can be used include: IP and MPLS, and Layer 2 encapsulations that run over IP and/or MPLS, such as pseudowires and GRE. The Working Group will document which deployment environments and types of topologies are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane aspects and is independent from any path setup protocol or mechanism. The Working Group will also document DetNet Controller Plane approaches that reuse existing IETF solutions, such as Path Computation Element (PCE), and identify the Working Group responsible for any extensions needed to support DetNet. Documents produced by the Working Group will be compatible with the work done in IEEE802.1 TSN and other IETF Working Groups. The Working Group's scope generally excludes modifications of transport protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss requirements for such modifications and the work will be coordinated with the Working Group responsible for the technology. DetNet is chartered to work in the following areas: Overall architecture: This work encompasses the data plane, OAM, time synchronization, management, control, and security aspects. Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet treatment over Layer 3. Other IETF defined data plane technologies may also be used. Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as "the aggregation of the Control and Management Planes". This work will document how to use IETF control plane solutions to support DetNet, including the identification of any gaps in existing solutions. Any modification to Controller Plane protocols to address identified gaps should be carried out in their associated Working Groups, but may be done in DetNet if agreed to by the relevant Working Group chairs and responsible Area Directors. Data flow information model: This work will identify the information needed for flow establishment and control and be used by reservation protocols and YANG data models. The work will be independent from the protocol(s) used to control the flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). YANG models: This work will document device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) for use in device configuration and status reporting. Such information may also be used when advertising the deterministic network elements to a control plane. Control plane related information will be independent from the protocol(s) which may be used to advertise this information (e.g. IS-IS or GMPLS extensions). Any new YANG models will be coordinated with the Working Groups that define any base models that are to be augmented. As needed, vertical requirements: This effort will detail the requirements for deterministic networks in various industries that have previously not been documented and cannot be supported using defined DetNet solutions. To investigate whether existing data plane encryption mechanisms can be applied, possibly opportunistically, to improve security and privacy. The Working Group coordinates with other relevant IETF Working Groups, including CCAMP, IPPM, LSR, PCE, PALS, TEAS, TSVWG, RAW, and 6TiSCH. As the work progresses, requirements may be provided to the responsible Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to maintain the consistency of the overall architecture and related solutions. The WG will liaise with appropriate groups in IEEE and other Standards Development Organizations (SDOs). Goals and Milestones: Sep 2022 - Adopt Enhanced DetNet Data Plane Requirements document Sep 2022 - Submit first OAM document for publication Oct 2022 - Submit OAM Solution Document(s) Dec 2022 - Adopt first Enhanced DetNet Data Plane solution document Dec 2022 - Submit controller plane framework Jul 2023 - Submit Enhanced DetNet Data Plane Requirements document for publication Dec 2023 - Submit first Enhanced DetNet Data Plane solution document for publication Internet-Drafts: - DetNet Data Plane Protocol and Solution Alternatives [draft-dt-detnet-dp-alt-04] (51 pages) - Deterministic Networking Architecture [draft-finn-detnet-architecture-08] (32 pages) - DetNet Bounded Latency [draft-finn-detnet-bounded-latency-04] (27 pages) - DetNet Configuration YANG Model [draft-geng-detnet-conf-yang-06] (51 pages) - Deterministic Networking Use Cases [draft-grossman-detnet-use-cases-01] (81 pages) - Deterministic Networking Architecture [draft-ietf-detnet-architecture-13] (38 pages) - Deterministic Networking (DetNet) Bounded Latency [draft-ietf-detnet-bounded-latency-10] (26 pages) - Deterministic Networking (DetNet) Controller Plane Framework [draft-ietf-detnet-controller-plane-framework-04] (19 pages) - Deterministic Networking (DetNet) Data Plane Framework [draft-ietf-detnet-data-plane-framework-06] (22 pages) - DetNet Data Plane Protocol and Solution Alternatives [draft-ietf-detnet-dp-alt-00] (51 pages) - DetNet Data Plane Encapsulation [draft-ietf-detnet-dp-sol-04] (39 pages) - DetNet IP Data Plane Encapsulation [draft-ietf-detnet-dp-sol-ip-02] (44 pages) - DetNet MPLS Data Plane Encapsulation [draft-ietf-detnet-dp-sol-mpls-02] (53 pages) - Flow and Service Information Model for Deterministic Networking (DetNet) [draft-ietf-detnet-flow-information-model-14] (20 pages) - Deterministic Networking (DetNet) Data Plane: IP [draft-ietf-detnet-ip-07] (21 pages) - Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane [draft-ietf-detnet-ip-oam-07] (9 pages) - Deterministic Networking (DetNet) Data Plane: IP over MPLS [draft-ietf-detnet-ip-over-mpls-09] (11 pages) - Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) [draft-ietf-detnet-ip-over-tsn-07] (10 pages) - Deterministic Networking (DetNet) Data Plane: MPLS [draft-ietf-detnet-mpls-13] (27 pages) - Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane [draft-ietf-detnet-mpls-oam-12] (13 pages) - Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP [draft-ietf-detnet-mpls-over-ip-preof-03] (12 pages) - Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) [draft-ietf-detnet-mpls-over-tsn-07] (11 pages) - Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP [draft-ietf-detnet-mpls-over-udp-ip-08] (8 pages) - Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet) [draft-ietf-detnet-oam-framework-08] (16 pages) - Deterministic Networking (DetNet): Packet Ordering Function [draft-ietf-detnet-pof-02] (12 pages) - Deterministic Networking Problem Statement [draft-ietf-detnet-problem-statement-09] (11 pages) - Requirements for Scaling Deterministic Networks [draft-ietf-detnet-scaling-requirements-02] (21 pages) - Deterministic Networking (DetNet) Security Considerations [draft-ietf-detnet-security-16] (50 pages) - Deterministic Networking (DetNet) Topology YANG Model [draft-ietf-detnet-topology-yang-01] (18 pages) - Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS [draft-ietf-detnet-tsn-vpn-over-mpls-07] (12 pages) - Deterministic Networking Use Cases [draft-ietf-detnet-use-cases-20] (97 pages) - Deterministic Networking (DetNet) YANG Model [draft-ietf-detnet-yang-17] (135 pages) - Requirements for Large-Scale Deterministic Networks [draft-liu-detnet-large-scale-requirements-05] (20 pages) - Deterministic Networking (DetNet) Security Considerations [draft-sdt-detnet-security-01] (35 pages) - Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP [draft-varga-detnet-ip-preof-02] (12 pages) - Deterministic Networking (DetNet): Packet Ordering Function [draft-varga-detnet-pof-03] (12 pages) Requests for Comments: RFC8557: Deterministic Networking Problem Statement (11 pages) RFC8578: Deterministic Networking Use Cases (97 pages) RFC8655: Deterministic Networking Architecture (38 pages) RFC8938: Deterministic Networking (DetNet) Data Plane Framework (22 pages) RFC8939: Deterministic Networking (DetNet) Data Plane: IP (21 pages) RFC8964: Deterministic Networking (DetNet) Data Plane: MPLS (27 pages) RFC9016: Flow and Service Information Model for Deterministic Networking (DetNet) (20 pages) RFC9023: Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) (10 pages) RFC9024: Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS (12 pages) RFC9025: Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP (8 pages) RFC9037: Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) (11 pages) RFC9055: Deterministic Networking (DetNet) Security Considerations (50 pages) RFC9056: Deterministic Networking (DetNet) Data Plane: IP over MPLS (11 pages) RFC9320: Deterministic Networking (DetNet) Bounded Latency (26 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Jeffrey Haas Keyur Patel Susan Hares Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Secretary: Jie Dong Mailing Lists: General Discussion: idr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/idr Archive: https://mailarchive.ietf.org/arch/browse/idr/ Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. IDR will review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested. Work Items: The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter. The current additional work items are: - Relax the definition of BGP identifiers to only require AS-wide uniqueness. This change must be made in a backward compatible way. - Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session. - Upgrade of the base BGP specification to Full Standard - Define AS_PATH based Outbound Route Filtering. - MIB v2 for BGP-4 - Augment the BGP multiprotocol extensions to support the use of multiple concurrent sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session- based attribute such as AFI/SAFI. This will provide an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. - Support for four-octet AS Numbers in BGP. - Revisions to the BGP 'Minimum Route Advertisement Interval' deprecating the previously recommended values and allowing for withdrawals to be exempted from the MRAI. - Advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Each path is identified by a path identifier in addition to the address prefix. - Revised error handling rules for optional transitive BGP attributes so that a BGP speaker is no longer required to reset the session over which a malformed attribute is received. Provide guidelines for authors of documents that define new optional transitive attributes, and re-assess procedures for existing optional transitive attributes - Specify Link Bandwidth Extended Community for use in unequal cost load balancing. - The definition of an "Accumulated IGP Metric" attribute for BGP to report the sum of the metric of each link along the path. This attribute is for use in a restricted environment where: - all ASes are subject to the administrative control - some form of tunneling is used to deliver a packet to its next BGP hop - where the path for a route leads outside the AS to which the BGP speaker adding the attribute belongs. - Advertisement of the best external route in BGP to assist with resolution of the next hop in the chosen data plane. Goals and Milestones: Mar 2015 - Submit ASpath ORF to IESG as a Proposed Standard Jun 2015 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Jun 2015 - Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Nov 2015 - Submit Multisession BGP to IESG as a Proposed Standard Nov 2015 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Dec 2015 - Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Jan 2016 - Revise WG charter Feb 2016 - Submit Yang BGP Modules to IESG as Proposed Standard Feb 2016 - Submit ASpath ORF draft to IESG as a Proposed Standard Apr 2016 - Progress base BGP specification (RFC 4271) as Full Standard Apr 2016 - Solicit work items for scalability improvements Done - Submit to BGP Capability Advertisement to the IESG Done - Submit BGP4 MIB to IESG as a Proposed Standard Done - Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done - Submit BGP4 document to IESG as a Draft Standard Done - Submit Extended Communities draft to IESG as a Proposed Standard Done - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit BGP Graceful Restart to IESG as a Proposed Standard Done - Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done - Submit 4-byte AS ID to IESG as a Proposed Standard Done - Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard Done - Prefix and ASpath ORF draft to IESG as a Proposed Standard Done - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Done - Submit BGP Support for Four-octet AS Number Space (revised version) to IESG as a Proposed Standard Done - Submit Revisions to the BGP 'Minimum Route Advertisement Interval' to IESG as a Proposed Standard Done - Submit The Accumulated IGP Metric Attribute for BGP to IESG as a Proposed Standard Done - Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard Internet-Drafts: - BGP Logical Link Discovery Protocol (LLDP) Peer Discovery [draft-acee-idr-lldp-peer-discovery-15] (18 pages) - Deterministic Route Redistribution into BGP [draft-chen-bgp-redist-03] (10 pages) - BGP for BIER-TE Path [draft-chen-idr-bier-te-path-05] (16 pages) - BGP for Mirror Binding [draft-chen-idr-mbinding-02] (7 pages) - Applying TCP User Timeout Parameter to BGP Sessions [draft-chen-idr-tcp-user-timeout-01] (6 pages) - BGP Extended Community Registries Update [draft-cl-idr-bgp-ext-com-registry-update-01] (5 pages) - BGP-LS Advertisement of Segment Routing Service Segments [draft-dawra-idr-bgp-ls-sr-service-segments-06] (12 pages) - BGP Link State Extensions for SRv6 [draft-dawra-idr-bgpls-srv6-ext-06] (24 pages) - BGP Flowspec for IETF Network Slice Traffic Steering [draft-dong-idr-flowspec-network-slice-ts-01] (10 pages) - BGP Extended Community for Identifying the Target Nodes [draft-dong-idr-node-target-ext-comm-05] (7 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-dong-idr-rtc-hierarchical-rr-02] (6 pages) - BGP SR Policy Extensions for Network Resource Partition [draft-dong-idr-sr-policy-nrp-02] (8 pages) - BGP Color-Aware Routing (CAR) [draft-dskc-bess-bgp-car-05] (54 pages) - BGP Extension for 5G Edge Service Metadata [draft-dunbar-idr-5g-edge-compute-app-meta-data-14] (16 pages) - BGP UPDATE for SDWAN Edge Discovery [draft-dunbar-idr-sdwan-edge-discovery-04] (29 pages) - Experimental BGP Flow Specification Extensions [draft-eddy-idr-flowspec-exp-00] (20 pages) - BGP Flow Specification Packet-Rate Action [draft-eddy-idr-flowspec-packet-rate-00] (4 pages) - BGP Link-State extensions for Segment Routing [draft-gredler-idr-bgp-ls-segment-routing-ext-04] (35 pages) - BGP Cease Notification Subcode For BFD [draft-haas-idr-bfd-subcode-00] (5 pages) - Interoperability Procedures for BGP Routes with Color [draft-haas-idr-bgp-diffract-00] (19 pages) - Dissemination of Flow Specification Rules for L2 VPN [draft-hao-idr-flowspec-evpn-02] (10 pages) - Dissemination of Flow Specification Rules for NVO3 [draft-hao-idr-flowspec-nvo3-03] (9 pages) - BGP Flow-Spec Redirect to Tunnel Action [draft-hao-idr-flowspec-redirect-tunnel-01] (9 pages) - Distribution of TRILL Link-State using BGP [draft-hao-idr-ls-trill-02] (12 pages) - An Information Model for Basic Network Policy and Filter Rules [draft-hares-idr-flowspec-combo-01] (45 pages) - BGP Flow Specification Version 2 [draft-hares-idr-flowspec-v2-05] (68 pages) - A BGP/IDRP Route Server alternative to a full mesh routing [draft-haskin-bgp-idrp-mesh-routing-00] (16 pages) - Advertising p2mp policies in BGP [draft-hb-idr-sr-p2mp-policy-05] (19 pages) - BGP-LS Extensions for IS-IS Flood Reflectors [draft-head-idr-bgp-ls-isis-fr-01] (5 pages) - Dissemination of Flow Specification Rules [draft-hr-idr-rfc5575bis-03] (30 pages) - BGP Provisioned IPsec Tunnel Configuration [draft-hujun-idr-bgp-ipsec-02] (15 pages) - BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration [draft-hujun-idr-bgp-ipsec-transport-mode-00] (7 pages) - BGP Protocol Analysis [draft-ietf-bgp-analysis-00] (8 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-application-03] (19 pages) - Border Gateway Protocol 3 (BGP-3) [draft-ietf-bgp-bgp3-00] (35 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-bgp-bgp4-09] (56 pages) - BGP-4 Protocol Document Roadmap and Implementation Experience [draft-ietf-bgp-bgp4-implement-01] (4 pages) - Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol [draft-ietf-bgp-defaultroute-01] (2 pages) - Experience with the BGP Protocol [draft-ietf-bgp-experience-00] (9 pages) - Application of the Border Gateway Protocol and IDRP for IP in the Internet [draft-ietf-bgp-idrp-usage-00] (21 pages) - Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 [draft-ietf-bgp-mibv4-05] (21 pages) - IP Multicast Communications Using BGP [draft-ietf-bgp-multicast-02] (10 pages) - Border Gateway Protocol NEXT-HOP-SNPA Attribute [draft-ietf-bgp-nexthop-01] (3 pages) - BGP OSPF Interaction [draft-ietf-bgp-ospfinteract-06] (14 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-usage-01] (13 pages) - BGP Extension for 5G Edge Service Metadata [draft-ietf-idr-5g-edge-service-metadata-02] (19 pages) - Advertisement of Multiple Paths in BGP [draft-ietf-idr-add-paths-15] (8 pages) - Best Practices for Advertisement of Multiple Paths in IBGP [draft-ietf-idr-add-paths-guidelines-08] (25 pages) - Advertisement of Multiple Paths in BGP: Implementation Report [draft-ietf-idr-add-paths-implementation-00] (16 pages) - BGP Advisory Message [draft-ietf-idr-advisory-00] (7 pages) - A Framework for Inter-Domain Route Aggregation [draft-ietf-idr-aggregation-framework-04] (13 pages) - Route Aggregation Tutorial [draft-ietf-idr-aggregation-tutorial-01] (8 pages) - The Accumulated IGP Metric Attribute for BGP [draft-ietf-idr-aigp-18] (15 pages) - Codification of AS 0 Processing [draft-ietf-idr-as0-06] (5 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-as4bytes-13] (10 pages) - Generic Subtype for BGP Four-octet AS specific extended community [draft-ietf-idr-as4octet-extcomm-generic-subtype-10] (6 pages) - Using a Dedicated AS for Sites Homed to a Single Provider [draft-ietf-idr-as-dedicated-00] (6 pages) - Autonomous System (AS) Number Reservation for Documentation Use [draft-ietf-idr-as-documentation-reservation-00] (4 pages) - The AS_HOPCOUNT Path Attribute [draft-ietf-idr-as-hopcount-00] (16 pages) - Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute [draft-ietf-idr-as-migration-06] (16 pages) - The AS_PATHLIMIT Path Attribute [draft-ietf-idr-as-pathlimit-03] (16 pages) - AS Path Based Outbound Route Filter for BGP-4 [draft-ietf-idr-aspath-orf-13] (7 pages) - Autonomous System (AS) Reservation for Private Use [draft-ietf-idr-as-private-reservation-05] (4 pages) - Textual Representation of Autonomous System (AS) Numbers [draft-ietf-idr-as-representation-01] (3 pages) - Guidelines for creation, selection, and registration of an Autonomous System (AS) [draft-ietf-idr-autosys-guide-03] (10 pages) - Avoid BGP Best Path Transitions from One External to Another [draft-ietf-idr-avoid-transition-05] (6 pages) - Advertisement of the best external route in BGP [draft-ietf-idr-best-external-05] (21 pages) - A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) [draft-ietf-idr-bfd-subcode-05] (5 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-idr-bgp4-26] (104 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp4-analysis-00] (10 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-bgp4-cap-neg-05] (5 pages) - Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-experience-00] (9 pages) - Experience with the BGP-4 Protocol [draft-ietf-idr-bgp4-experience-protocol-05] (19 pages) - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing [draft-ietf-idr-bgp4-ipv6-01] (5 pages) - Definitions of Managed Objects for BGP-4 [draft-ietf-idr-bgp4-mib-15] (32 pages) - Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version [draft-ietf-idr-bgp4-mibv2-15] (45 pages) - Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp4-mibv2-tc-mib-05] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-01] (9 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-v2-04] (11 pages) - Operational Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-op-experience-02] (9 pages) - BGP4/IDRP for IP---OSPF Interaction [draft-ietf-idr-bgp4ospf-interact-07] (19 pages) - BGP-4 Requirement Satisfaction Report [draft-ietf-idr-bgp4-stdreport1-02] (3 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp-analysis-07] (16 pages) - Constrain Attribute announcement within BGP [draft-ietf-idr-bgp-attribute-announcement-03] (9 pages) - Requirements and Considerations in BGP Peer Auto-Configuration [draft-ietf-idr-bgp-autoconf-considerations-02] (19 pages) - BGP Bestpath Selection Criteria Enhancement [draft-ietf-idr-bgp-bestpath-selection-criteria-12] (9 pages) - BGP BFD Strict-Mode [draft-ietf-idr-bgp-bfd-strict-mode-10] (6 pages) - BGP Color-Aware Routing (CAR) [draft-ietf-idr-bgp-car-01] (58 pages) - BGP Classful Transport Planes [draft-ietf-idr-bgp-classful-transport-planes-01] (37 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-00] (7 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-rfc1965bis-01] (11 pages) - BGP Classful Transport Planes [draft-ietf-idr-bgp-ct-03] (70 pages) - Destination Preference Attribute for BGP [draft-ietf-idr-bgp-dpa-05] (4 pages) - Enhanced Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-enhanced-route-refresh-10] (8 pages) - BGP Extended Communities Attribute [draft-ietf-idr-bgp-ext-communities-09] (12 pages) - BGP Extended Community Registries Update [draft-ietf-idr-bgp-ext-com-registry-05] (5 pages) - Extended Message Support for BGP [draft-ietf-idr-bgp-extended-messages-36] (7 pages) - Carrying Label Information for BGP FlowSpec [draft-ietf-idr-bgp-flowspec-label-02] (10 pages) - Revised Validation Procedure for BGP Flow Specifications [draft-ietf-idr-bgp-flowspec-oid-15] (12 pages) - Notification Message Support for BGP Graceful Restart [draft-ietf-idr-bgp-gr-notification-16] (10 pages) - BGP Graceful Restart - Implementation Survey [draft-ietf-idr-bgp-gr-survey-01] (10 pages) - Autonomous-System-Wide Unique BGP Identifier for BGP-4 [draft-ietf-idr-bgp-identifier-14] (4 pages) - Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP [draft-ietf-idr-bgp-ifit-capabilities-02] (11 pages) - BGP-4 Implementation Report [draft-ietf-idr-bgp-implementation-02] (97 pages) - IPv6 Extensions for Route Target Distribution [draft-ietf-idr-bgp-ipv6-rt-constrain-12] (6 pages) - Issues in Revising BGP-4 (RFC1771 to RFC4271) [draft-ietf-idr-bgp-issues-06] (170 pages) - Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) [draft-ietf-idr-bgp-ls-app-specific-attr-16] (12 pages) - BGP Link-State Extensions for BGP-only Fabric [draft-ietf-idr-bgp-ls-bgp-only-fabric-03] (24 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement [draft-ietf-idr-bgp-ls-flex-algo-12] (14 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-ietf-idr-bgpls-inter-as-topology-ext-13] (13 pages) - BGP-LS Extensions for IS-IS Flood Reflection [draft-ietf-idr-bgp-ls-isis-flood-reflection-02] (6 pages) - Signaling Maximum Transmission Unit (MTU) using BGP-LS [draft-ietf-idr-bgp-ls-link-mtu-04] (9 pages) - Advertising Node Admin Tags in BGP Link-State Advertisements [draft-ietf-idr-bgp-ls-node-admin-tag-extension-03] (11 pages) - Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries [draft-ietf-idr-bgp-ls-registry-06] (5 pages) - BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) [draft-ietf-idr-bgp-ls-sbfd-extensions-10] (6 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering [draft-ietf-idr-bgpls-segment-routing-epe-19] (15 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing [draft-ietf-idr-bgp-ls-segment-routing-ext-18] (27 pages) - Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State [draft-ietf-idr-bgp-ls-segment-routing-msd-18] (9 pages) - Signalling ERLD using BGP-LS [draft-ietf-idr-bgp-ls-segment-routing-rld-05] (6 pages) - Advertisement of Segment Routing Policies using BGP Link-State [draft-ietf-idr-bgp-ls-sr-policy-00] (46 pages) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-path-segment-04] (12 pages) - BGP-LS Advertisement of Segment Routing Service Segments [draft-ietf-idr-bgp-ls-sr-service-segments-02] (12 pages) - BGP Link State Extensions for SRv6 [draft-ietf-idr-bgpls-srv6-ext-14] (26 pages) - BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks [draft-ietf-idr-bgpls-sr-vtn-mt-02] (10 pages) - Advertisement of Traffic Engineering Paths using BGP Link-State [draft-ietf-idr-bgp-ls-te-path-00] (22 pages) - BGP AS Path Metrics [draft-ietf-idr-bgp-metrics-00] (8 pages) - BGP-4 MIB Implementation Survey [draft-ietf-idr-bgp-mibagent-survey-02] (37 pages) - YANG Model for Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp-model-16] (224 pages) - Multisession BGP [draft-ietf-idr-bgp-multisession-07] (19 pages) - Carrying next-hop cost information in BGP [draft-ietf-idr-bgp-nh-cost-03] (10 pages) - Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages [draft-ietf-idr-bgp-open-policy-24] (12 pages) - BGP Optimal Route Reflection (BGP ORR) [draft-ietf-idr-bgp-optimal-route-reflection-28] (9 pages) - Address-Prefix-Based Outbound Route Filter for BGP-4 [draft-ietf-idr-bgp-prefix-orf-05] (6 pages) - Segment Routing Prefix Segment Identifier Extensions for BGP [draft-ietf-idr-bgp-prefix-sid-27] (15 pages) - Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-route-refresh-01] (4 pages) - Border Gateway Protocol 4 (BGP-4) Send Hold Timer [draft-ietf-idr-bgp-sendholdtimer-00] (8 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5-00] (6 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5bad-01] (5 pages) - BGP Security Vulnerabilities Analysis [draft-ietf-idr-bgp-vuln-01] (22 pages) - BGP for BIER-TE Path [draft-ietf-idr-bier-te-path-01] (15 pages) - Revision to Capability Codes Registration Procedures [draft-ietf-idr-capabilities-registry-change-09] (5 pages) - Subcodes for BGP Cease Notification Message [draft-ietf-idr-cease-subcode-07] (6 pages) - BGP Communities Attribute [draft-ietf-idr-communities-00] (5 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-00] (10 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-usage-00] (9 pages) - BGP Custom Decision Process [draft-ietf-idr-custom-decision-08] (11 pages) - Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 [draft-ietf-idr-deprecate-30-31-129-02] (3 pages) - Deprecation of BGP OPEN Message Error subcodes 8, 9, and 10. [draft-ietf-idr-deprecate-8-9-10-00] (3 pages) - Deprecation of AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-set-confed-set-10] (13 pages) - Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-sets-06] (5 pages) - Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID [draft-ietf-idr-deprecate-dpa-etal-00] (3 pages) - Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing [draft-ietf-idr-dpa-application-02] (8 pages) - Dynamic Capability for BGP-4 [draft-ietf-idr-dynamic-cap-16] (9 pages) - Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) [draft-ietf-idr-eag-distribution-19] (7 pages) - BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute [draft-ietf-idr-encaps-safi-00] (13 pages) - Accelerated Routing Convergence for BGP Graceful Restart [draft-ietf-idr-enhanced-gr-06] (9 pages) - Enhanced Route Refresh Implementation Report [draft-ietf-idr-enhanced-refresh-impl-00] (5 pages) - BGP Router Capabilities Attribute [draft-ietf-idr-entropy-label-03] (14 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-error-handling-19] (19 pages) - IANA Registries for BGP Extended Communities [draft-ietf-idr-extcomm-iana-02] (16 pages) - Extended Optional Parameters Length for BGP OPEN Message [draft-ietf-idr-ext-opt-param-13] (6 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-flow-spec-09] (22 pages) - Applying BGP flowspec rules on a specific interface set [draft-ietf-idr-flowspec-interfaceset-05] (9 pages) - BGP Dissemination of L2 Flow Specification Rules [draft-ietf-idr-flowspec-l2vpn-21] (20 pages) - BGP Flow Specification Filter for MPLS Label [draft-ietf-idr-flowspec-mpls-match-02] (8 pages) - BGP Flowspec for IETF Network Slice Traffic Steering [draft-ietf-idr-flowspec-network-slice-ts-00] (10 pages) - BGP Dissemination of Flow Specification Rules for Tunneled Traffic [draft-ietf-idr-flowspec-nvo3-17] (23 pages) - BGP Flow Specification Packet-Rate Action [draft-ietf-idr-flowspec-packet-rate-01] (5 pages) - Flowspec Indirection-id Redirect [draft-ietf-idr-flowspec-path-redirect-12] (11 pages) - BGP Flow-Spec Redirect to IP Action [draft-ietf-idr-flowspec-redirect-ip-02] (9 pages) - Clarification of the Flowspec Redirect Extended Community [draft-ietf-idr-flowspec-redirect-rt-bis-05] (7 pages) - BGP Flow Specification for SRv6 [draft-ietf-idr-flowspec-srv6-03] (10 pages) - BGP Flow Specification Version 2 [draft-ietf-idr-flowspec-v2-02] (69 pages) - Dissemination of Flow Specification Rules for IPv6 [draft-ietf-idr-flow-spec-v6-22] (19 pages) - Subcodes for BGP Finite State Machine Error [draft-ietf-idr-fsm-subcode-03] (5 pages) - Inter-Domain Routing Protocol, Version 2 [draft-ietf-idr-idrp2-00] (110 pages) - IDRP for IP v4 and v6 [draft-ietf-idr-idrp-v4v6-02] (20 pages) - Internet Exchange BGP Route Server [draft-ietf-idr-ix-bgp-route-server-12] (12 pages) - Internet Exchange Route Server - Implementation Report [draft-ietf-idr-ix-bgp-route-server-implementation-00] (5 pages) - BGP Large Communities Attribute [draft-ietf-idr-large-community-12] (8 pages) - Reservation of Last Autonomous System (AS) Numbers [draft-ietf-idr-last-as-reservation-07] (5 pages) - Automatic Route Target Filtering for legacy PEs [draft-ietf-idr-legacy-rtc-08] (10 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-07] (5 pages) - Support for Long-lived BGP Graceful Restart [draft-ietf-idr-long-lived-gr-04] (24 pages) - North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP [draft-ietf-idr-ls-distribution-13] (48 pages) - BGP Link-State Information Distribution Implementation Report [draft-ietf-idr-ls-distribution-impl-04] (15 pages) - Distribution of TRILL Link-State using BGP [draft-ietf-idr-ls-trill-05] (16 pages) - Key Management Considerations for the TCP MD5 Signature Option [draft-ietf-idr-md5-keys-00] (7 pages) - Multicast Distribution Control Signaling [draft-ietf-idr-mdcs-00] (9 pages) - Multicast Distribution Reachability Signaling [draft-ietf-idr-mdrs-00] (6 pages) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-04] (4 pages) - BGP Next-Hop dependent capabilities [draft-ietf-idr-next-hop-capability-08] (13 pages) - BGP Extended Community for Identifying the Target Nodes [draft-ietf-idr-node-target-ext-comm-00] (7 pages) - BGP OPERATIONAL Message [draft-ietf-idr-operational-message-00] (29 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-optional-transitive-04] (10 pages) - Performance-based BGP Routing Mechanism [draft-ietf-idr-performance-routing-03] (10 pages) - Configuring IDRP Confederations [draft-ietf-idr-rdc-config-01] (5 pages) - Registered Wide BGP Community Values [draft-ietf-idr-registered-wide-bgp-communities-02] (18 pages) - Assigned BGP extended communities [draft-ietf-idr-reserved-extended-communities-09] (6 pages) - Graceful Restart Mechanism for BGP [draft-ietf-idr-restart-13] (15 pages) - Reclassification of RFC 1863 to Historic [draft-ietf-idr-rfc1863-historic-00] (3 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-rfc2385bis-01] (6 pages) - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) [draft-ietf-idr-rfc2796bis-02] (12 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc2842bis-01] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc2858bis-10] (12 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-rfc3065bis-06] (14 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc3392bis-05] (7 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc4760bis-03] (13 pages) - BGP Support for Four-Octet Autonomous System (AS) Number Space [draft-ietf-idr-rfc4893bis-07] (12 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-rfc5575bis-27] (36 pages) - Distribution of Link-State and Traffic Engineering Information Using BGP [draft-ietf-idr-rfc7752bis-16] (72 pages) - Extended BGP Administrative Shutdown Communication [draft-ietf-idr-rfc8203bis-08] (7 pages) - Making Route Flap Damping Usable [draft-ietf-idr-rfd-usable-04] (8 pages) - Extensions for Selective Updates in Inter Domain Routing [draft-ietf-idr-rifs-00] (9 pages) - BGP Route Flap Damping [draft-ietf-idr-route-damp-03] (37 pages) - Outbound Route Filtering Capability for BGP-4 [draft-ietf-idr-route-filter-17] (12 pages) - Methods for Detection and Mitigation of BGP Route Leaks [draft-ietf-idr-route-leak-detection-mitigation-11] (11 pages) - Border Gateway Protocol (BGP) Persistent Route Oscillation Condition [draft-ietf-idr-route-oscillation-00] (19 pages) - Solutions for BGP Persistent Route Oscillation [draft-ietf-idr-route-oscillation-stop-04] (9 pages) - BGP Route Reflection An alternative to full mesh IBGP [draft-ietf-idr-route-reflect-02] (7 pages) - BGP Route Reflection - An Alternative to Full Mesh IBGP [draft-ietf-idr-route-reflect-v2-03] (11 pages) - BGP Extensions for Routing Policy Distribution (RPD) [draft-ietf-idr-rpd-16] (22 pages) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ietf-idr-rs-bfd-09] (14 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-ietf-idr-rtc-hierarchical-rr-03] (6 pages) - Route Target Constrained Distribution of Routes with no Route Targets [draft-ietf-idr-rtc-no-rt-12] (7 pages) - Extended Communities Derived from Route Targets [draft-ietf-idr-rt-derived-community-00] (7 pages) - BGP UPDATE for SD-WAN Edge Discovery [draft-ietf-idr-sdwan-edge-discovery-09] (31 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-segment-routing-te-policy-20] (49 pages) - BGP Administrative Shutdown Communication [draft-ietf-idr-shutdown-10] (6 pages) - Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute [draft-ietf-idr-sla-exchange-13] (32 pages) - Inter-domain SLA Exchange Implementation Report-02 [draft-ietf-idr-sla-exchange-impl-02] (5 pages) - Advertising p2mp policies in BGP [draft-ietf-idr-sr-p2mp-policy-00] (20 pages) - BGP SR Policy Extensions to Enable IFIT [draft-ietf-idr-sr-policy-ifit-06] (16 pages) - Segment Routing Path MTU in BGP [draft-ietf-idr-sr-policy-path-mtu-07] (11 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-ietf-idr-sr-policy-path-segment-07] (12 pages) - Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet [draft-ietf-idr-symm-multi-prov-02] (13 pages) - Distribution of Traffic Engineering (TE) Policies and State using BGP-LS [draft-ietf-idr-te-lsp-distribution-19] (58 pages) - BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions [draft-ietf-idr-te-pm-bgp-18] (10 pages) - Traffic Steering using BGP FlowSpec with SR Policy [draft-ietf-idr-ts-flowspec-srv6-policy-02] (13 pages) - The BGP Tunnel Encapsulation Attribute [draft-ietf-idr-tunnel-encaps-22] (41 pages) - Advertising an IPv4 NLRI with an IPv6 Next Hop [draft-ietf-idr-v4nlri-v6nh-01] (10 pages) - VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 [draft-ietf-idr-vpn-prefix-orf-00] (22 pages) - BGP Community Container Attribute [draft-ietf-idr-wide-bgp-communities-11] (25 pages) - IDRP for SIP [draft-ietf-ipidrp-sip-01] (9 pages) - Border Gateway Protocol (BGP) [draft-ietf-iwg-bgp-00] (29 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-iwg-bgpapplication-00] (23 pages) - Definitions of Managed Objects for the Border Gateway Protocol: Version 3 [draft-ietf-iwg-bgp-mib-02] (13 pages) - Internet Exchange Route Server - Implementation Report [draft-jasinska-ix-bgp-route-server-implementation-00] (5 pages) - Path validation toward BGP next-hop with AUTO-BFD [draft-jdurand-auto-bfd-00] (8 pages) - Traffic Steering using BGP Flowspec with SRv6 Policy [draft-jiang-idr-ts-flowspec-srv6-policy-07] (10 pages) - BGP Classful Transport Planes [draft-kaliraj-idr-bgp-classful-transport-planes-17] (37 pages) - Application Specific Attributes Advertisement with BGP Link-State [draft-ketant-idr-bgp-ls-app-specific-attr-01] (13 pages) - BGP Link-State Extensions for BGP-only Fabric [draft-ketant-idr-bgp-ls-bgp-only-fabric-05] (25 pages) - Flexible Algorithm Definition Advertisement with BGP Link-State [draft-ketant-idr-bgp-ls-flex-algo-01] (10 pages) - Distribution of Link-State and Traffic Engineering Information Using BGP [draft-ketant-idr-rfc7752bis-01] (58 pages) - Constrain Attribute announcement within BGP [draft-keyupate-idr-bgp-attribute-announcement-01] (9 pages) - Segment Routing Prefix SID extensions for BGP [draft-keyupate-idr-bgp-prefix-sid-05] (15 pages) - Deprecation of AS_SET and AS_CONFED_SET in BGP [draft-kumari-deprecate-as-set-confed-set-14] (6 pages) - Carrying Label Information for BGP FlowSpec [draft-liang-idr-bgp-flowspec-label-02] (9 pages) - BGP FlowSpec with Time Constraints [draft-liang-idr-bgp-flowspec-time-00] (9 pages) - BGP Link-State Extensions for Seamless BFD [draft-li-idr-bgp-ls-sbfd-extensions-03] (9 pages) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-li-idr-bgp-ls-sr-policy-path-segment-03] (10 pages) - BGP FlowSpec Redirect to Generalized Segment ID Action [draft-li-idr-flowspec-redirect-generalized-sid-00] (8 pages) - BGP Extensions for Routing Policy Distribution (RPD) [draft-li-idr-flowspec-rpd-05] (18 pages) - BGP Flow Specification for SRv6 [draft-li-idr-flowspec-srv6-07] (10 pages) - BGP Extensions for Service-Oriented MPLS Path Programming (MPP) [draft-li-idr-mpls-path-programming-04] (14 pages) - Segment Routing Path MTU in BGP [draft-li-idr-sr-policy-path-mtu-03] (8 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-li-idr-sr-policy-path-segment-01] (11 pages) - Applying BGP flowspec rules on a specific interface set [draft-litkowski-idr-flowspec-interfaceset-03] (13 pages) - Inter Domain considerations for Constrained Route distribution [draft-litkowski-idr-rtc-interas-01] (8 pages) - BGP BFD Strict-Mode [draft-merciaz-idr-bgp-bfd-strict-mode-02] (7 pages) - BGP Peer Auto-Configuration [draft-minto-idr-bgp-autodiscovery-01] (15 pages) - Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) [draft-ooms-v6ops-bgp-tunnel-07] (14 pages) - Segment Routing Egress Peer Engineering BGP-LS Extensions [draft-previdi-idr-bgpls-segment-routing-epe-03] (17 pages) - Advertising Segment Routing Policies in BGP [draft-previdi-idr-segment-routing-te-policy-07] (30 pages) - Advertising Node Admin Tags in BGP Link-State Advertisements [draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05] (11 pages) - BGP SR Policy Extensions to Enable IFIT [draft-qin-idr-sr-policy-ifit-04] (15 pages) - BGP Auto Discovery [draft-raszuk-idr-bgp-auto-discovery-08] (14 pages) - Registered Wide BGP Community Values [draft-raszuk-registered-wide-bgp-communities-00] (17 pages) - Wide BGP Communities Attribute [draft-raszuk-wide-bgp-communities-05] (23 pages) - Multicast Distribution Control Signaling [draft-rekhter-mdcs-01] (9 pages) - Multicast Distribution Reachability Signaling [draft-rekhter-mdrs-01] (6 pages) - Advertisement of Multiple Paths in BGP: Implementation Report [draft-retana-idr-add-paths-implementation-01] (16 pages) - Route Target Constrained Distribution of Routes with no Route Targets [draft-rosen-idr-rtc-no-rt-01] (6 pages) - Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI [draft-rosen-idr-tunnel-encaps-03] (29 pages) - Inbound BGP Maximum Prefix Limits [draft-sas-idr-maxprefix-inbound-05] (8 pages) - Revision to Capability Codes Registration Procedures [draft-scudder-idr-capabilities-registry-change-02] (4 pages) - BGP Entropy Label Capability, Version 3 [draft-scudder-idr-entropy-label-01] (9 pages) - Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234 [draft-snijders-idr-deprecate-30-31-129-02] (3 pages) - Extended BGP Administrative Shutdown Communication [draft-snijders-idr-rfc8203bis-01] (7 pages) - The Shutdown Communication BGP Cease Notification Message subcode [draft-snijders-idr-shutdown-00] (6 pages) - Border Gateway Protocol 4 (BGP-4) Send Hold Timer [draft-spaghetti-idr-bgp-sendholdtimer-09] (8 pages) - Deprecation of BGP OPEN Message Error subcodes 8, 9, and 10. [draft-spaghetti-idr-deprecate-8-9-10-01] (3 pages) - Methods for Detection and Mitigation of BGP Route Leaks [draft-sriram-idr-route-leak-detection-mitigation-01] (17 pages) - Signaling Maximum SID Depth using Border Gateway Protocol Link-State [draft-tantsura-idr-bgp-ls-segment-routing-msd-05] (7 pages) - Support for Long-lived BGP Graceful Restart [draft-uttaro-idr-bgp-persistence-05] (25 pages) - Signalling ERLD using BGP-LS [draft-vandevelde-idr-bgp-ls-segment-routing-rld-03] (6 pages) - Flowspec Indirection-id Redirect [draft-vandevelde-idr-flowspec-path-redirect-03] (12 pages) - BGP Remote-Next-Hop [draft-vandevelde-idr-remote-next-hop-09] (17 pages) - BGP Persistent Route Oscillation Solutions [draft-walton-bgp-route-oscillation-stop-09] (9 pages) - BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities [draft-wang-idr-bgp-ifit-capabilities-05] (10 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-wang-idr-bgpls-inter-as-topology-ext-02] (10 pages) - Distribution of MPLS-TE Extended admin Group Using BGP [draft-wang-idr-eag-distribution-02] (5 pages) - Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4 [draft-wang-idr-rd-orf-08] (13 pages) - VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 [draft-wang-idr-vpn-prefix-orf-06] (22 pages) - BGP Extensions for IDs Allocation [draft-wu-idr-bgp-segment-allocation-ext-11] (16 pages) - A YANG Data Model for Flow Specification [draft-wu-idr-flowspec-yang-cfg-02] (32 pages) - BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks [draft-xie-idr-bgpls-sr-vtn-mt-04] (11 pages) - BGP Extensions for BIER [draft-xu-idr-bier-extensions-02] (7 pages) - BGP Neighbor Discovery [draft-xu-idr-neighbor-autodiscovery-12] (33 pages) - Performance-based BGP Routing Mechanism [draft-xu-idr-performance-routing-01] (9 pages) - Route Leak Prevention using Roles in Update and Open messages [draft-ymbk-idr-bgp-open-policy-03] (10 pages) - Layer-3 Neighbor Discovery [draft-ymbk-idr-l3nd-06] (28 pages) - L3ND Upper-Layer Protocol Configuration [draft-ymbk-idr-l3nd-ulpc-07] (9 pages) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ymbk-idr-rs-bfd-01] (8 pages) - BGP Flow Specification Filter for MPLS Label [draft-yong-idr-flowspec-mpls-match-00] (8 pages) - BGP SR Policy Extensions for metric [draft-zhang-idr-sr-policy-metric-04] (7 pages) - BGP Extension for SR-MPLS Entropy Label Position [draft-zhou-idr-bgp-srmpls-elp-08] (9 pages) - Signaling Maximum Transmission Unit (MTU) using BGP-LS [draft-zhu-idr-bgp-ls-path-mtu-05] (9 pages) - Extended Communities Derived from Route Targets [draft-zzhang-idr-rt-derived-community-04] (7 pages) - MPLS Label Stacks in Tunnel Encapsulation Attribute [draft-zzhang-idr-tunnel-encapsulation-label-stack-02] (8 pages) Requests for Comments: BCP172: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (5 pages) BCP6: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) RFC1163: Border Gateway Protocol (BGP) (29 pages) * Obsoletes RFC1267 RFC1164: Application of the Border Gateway Protocol in the Internet (23 pages) * Obsoletes RFC1268 RFC1265: BGP Protocol Analysis (8 pages) RFC1266: Experience with the BGP Protocol (9 pages) RFC1267: Border Gateway Protocol 3 (BGP-3) (35 pages) RFC1268: Application of the Border Gateway Protocol in the Internet (13 pages) * Obsoletes RFC1655 RFC1269: Definitions of Managed Objects for the Border Gateway Protocol: Version 3 (13 pages) * Obsoletes RFC4273 RFC1364: BGP OSPF Interaction (14 pages) * Obsoletes RFC1403 RFC1397: Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol (2 pages) RFC1654: A Border Gateway Protocol 4 (BGP-4) (56 pages) * Obsoletes RFC1771 RFC1655: Application of the Border Gateway Protocol in the Internet (19 pages) * Obsoletes RFC1772 RFC1656: BGP-4 Protocol Document Roadmap and Implementation Experience (4 pages) * Obsoletes RFC1773 RFC1657: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 (21 pages) * Obsoletes RFC4273 RFC1745: BGP4/IDRP for IP---OSPF Interaction (19 pages) RFC1773: Experience with the BGP-4 protocol (9 pages) RFC1774: BGP-4 Protocol Analysis (10 pages) RFC1863: A BGP/IDRP Route Server alternative to a full mesh routing (16 pages) * Obsoletes RFC4223 RFC1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) * Updates RFC6996 * Updates RFC7300 RFC1965: Autonomous System Confederations for BGP (7 pages) * Obsoletes RFC3065 RFC1966: BGP Route Reflection An alternative to full mesh IBGP (7 pages) * Obsoletes RFC4456 * Updates RFC2796 RFC1997: BGP Communities Attribute (5 pages) * Updates RFC7606 * Updates RFC8642 RFC1998: An Application of the BGP Community Attribute in Multi-home Routing (9 pages) RFC2270: Using a Dedicated AS for Sites Homed to a Single Provider (6 pages) RFC2283: Multiprotocol Extensions for BGP-4 (9 pages) * Obsoletes RFC2858 RFC2385: Protection of BGP Sessions via the TCP MD5 Signature Option (6 pages) * Obsoletes RFC5925 * Updates RFC6691 RFC2439: BGP Route Flap Damping (37 pages) RFC2519: A Framework for Inter-Domain Route Aggregation (13 pages) RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing (5 pages) RFC2796: BGP Route Reflection - An Alternative to Full Mesh IBGP (11 pages) * Obsoletes RFC4456 RFC2842: Capabilities Advertisement with BGP-4 (5 pages) * Obsoletes RFC3392 RFC2858: Multiprotocol Extensions for BGP-4 (11 pages) * Obsoletes RFC4760 RFC2918: Route Refresh Capability for BGP-4 (4 pages) * Updates RFC7313 RFC3065: Autonomous System Confederations for BGP (11 pages) * Obsoletes RFC5065 RFC3345: Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (19 pages) RFC3392: Capabilities Advertisement with BGP-4 (6 pages) * Obsoletes RFC5492 RFC3562: Key Management Considerations for the TCP MD5 Signature Option (7 pages) RFC4223: Reclassification of RFC 1863 to Historic (3 pages) RFC4271: A Border Gateway Protocol 4 (BGP-4) (104 pages) * Updates RFC6286 * Updates RFC6608 * Updates RFC6793 * Updates RFC7607 * Updates RFC7606 * Updates RFC7705 * Updates RFC8212 * Updates RFC8654 * Updates RFC9072 RFC4272: BGP Security Vulnerabilities Analysis (22 pages) RFC4273: Definitions of Managed Objects for BGP-4 (32 pages) RFC4274: BGP-4 Protocol Analysis (16 pages) RFC4275: BGP-4 MIB Implementation Survey (37 pages) RFC4276: BGP-4 Implementation Report (97 pages) RFC4277: Experience with the BGP-4 Protocol (19 pages) RFC4360: BGP Extended Communities Attribute (12 pages) * Updates RFC7153 * Updates RFC7606 RFC4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) (12 pages) * Updates RFC7606 RFC4486: Subcodes for BGP Cease Notification Message (6 pages) * Updates RFC8203 * Updates RFC9003 RFC4724: Graceful Restart Mechanism for BGP (15 pages) * Updates RFC8538 RFC4760: Multiprotocol Extensions for BGP-4 (12 pages) * Updates RFC7606 RFC4798: Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) (14 pages) RFC4893: BGP Support for Four-octet AS Number Space (10 pages) * Obsoletes RFC6793 RFC5004: Avoid BGP Best Path Transitions from One External to Another (6 pages) RFC5065: Autonomous System Confederations for BGP (14 pages) RFC5291: Outbound Route Filtering Capability for BGP-4 (12 pages) RFC5292: Address-Prefix-Based Outbound Route Filter for BGP-4 (6 pages) RFC5396: Textual Representation of Autonomous System (AS) Numbers (3 pages) RFC5398: Autonomous System (AS) Number Reservation for Documentation Use (4 pages) RFC5492: Capabilities Advertisement with BGP-4 (7 pages) * Updates RFC8810 RFC5575: Dissemination of Flow Specification Rules (22 pages) * Updates RFC7674 * Obsoletes RFC8955 RFC6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 (4 pages) RFC6472: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (5 pages) RFC6608: Subcodes for BGP Finite State Machine Error (5 pages) RFC6793: BGP Support for Four-Octet Autonomous System (AS) Number Space (12 pages) RFC6938: Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID (3 pages) RFC6996: Autonomous System (AS) Reservation for Private Use (4 pages) RFC7153: IANA Registries for BGP Extended Communities (16 pages) * Updates RFC9184 RFC7196: Making Route Flap Damping Usable (8 pages) RFC7300: Reservation of Last Autonomous System (AS) Numbers (5 pages) RFC7311: The Accumulated IGP Metric Attribute for BGP (15 pages) RFC7313: Enhanced Route Refresh Capability for BGP-4 (8 pages) RFC7606: Revised Error Handling for BGP UPDATE Messages (19 pages) RFC7607: Codification of AS 0 Processing (5 pages) RFC7674: Clarification of the Flowspec Redirect Extended Community (7 pages) * Obsoletes RFC8955 RFC7705: Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute (16 pages) RFC7752: North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP (48 pages) * Updates RFC9029 RFC7911: Advertisement of Multiple Paths in BGP (8 pages) RFC7947: Internet Exchange BGP Route Server (12 pages) RFC7964: Solutions for BGP Persistent Route Oscillation (9 pages) RFC8092: BGP Large Communities Attribute (8 pages) RFC8093: Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 (3 pages) RFC8203: BGP Administrative Shutdown Communication (6 pages) * Obsoletes RFC9003 RFC8538: Notification Message Support for BGP Graceful Restart (10 pages) RFC8571: BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions (10 pages) RFC8654: Extended Message Support for BGP (7 pages) RFC8669: Segment Routing Prefix Segment Identifier Extensions for BGP (15 pages) RFC8810: Revision to Capability Codes Registration Procedures (5 pages) RFC8814: Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State (9 pages) RFC8955: Dissemination of Flow Specification Rules (36 pages) * Updates RFC8956 * Updates RFC9117 * Updates RFC9184 RFC8956: Dissemination of Flow Specification Rules for IPv6 (19 pages) RFC9003: Extended BGP Administrative Shutdown Communication (7 pages) RFC9012: The BGP Tunnel Encapsulation Attribute (41 pages) RFC9029: Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries (5 pages) RFC9072: Extended Optional Parameters Length for BGP OPEN Message (6 pages) RFC9085: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing (27 pages) * Updates RFC9356 RFC9086: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering (15 pages) RFC9104: Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) (7 pages) RFC9107: BGP Optimal Route Reflection (BGP ORR) (9 pages) RFC9117: Revised Validation Procedure for BGP Flow Specifications (12 pages) RFC9184: BGP Extended Community Registries Update (5 pages) RFC9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages (12 pages) RFC9247: BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) (6 pages) RFC9294: Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) (12 pages) RFC9351: Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement (14 pages) RFC9384: A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) (5 pages) Link State Routing (lsr) ------------------------ Charter Last Modified: 2022-05-03 Current Status: Active Chairs: Acee Lindem Christian Hopps Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Secretary: Yingzhen Qu Mailing Lists: General Discussion: lsr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsr Archive: https://mailarchive.ietf.org/arch/browse/lsr/ Description of Working Group: The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of the link-state interior gateway routing protocols (IGPs) - specifically IS-IS, OSPFv2, and OSPFv3. The LSR Working Group was formed by merging the isis and ospf WGs and assigning all their existing adopted work at the time of chartering to LSR. IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR-WG’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR-WG will interact with other standards bodies that have responsibility for standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for example TRILL work) as needed. OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director. In addition to ongoing maintenance, the following topics are specific work-items for the WG. 1) Improve OSPF support for IPv6 and create at least parity with IPv4 functionality by adding OSPFv3 extensions using the OSPFv3 Extended LSAs. 2) Extensions needed for Segment Routing and associated architectural changes 3) YANG models for the management of IS-IS, OSPFv2, and OSPFv3 and extensions 4) Extensions for source-destination routing 5) Improvements to flooding (and other behaviors) to better support dense meshed network topologies, such as are commonly used in data centers. The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, PCE, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs and is compatible with IS-IS and/or OSPF from functional, architectural and performance point of views. LSR-WG will coordinate with CCAMP, TEAS, and BIER on their extensions to the LSR IGPs as applicable to LSR protocol operation and scale. LSR-WG should coordinate with other WGs as needed. Goals and Milestones: Jul 2018 - OSPF YANG Model to IESG Jul 2018 - ISIS YANG model to IESG Jul 2018 - IS-IS Reverse Metric to IESG Jul 2018 - IS-IS Segment Routing MSD to IESG Nov 2018 - OSPFv3 SR to IESG Nov 2018 - OSPFv2 Attribute Agility Mar 2019 - OSPF Segment Routing YANG Model Mar 2019 - IS-IS Segment Routing SR YANG Model Jul 2019 - OSPFv3 Dual Stack (single instance) Internet-Drafts: - IS-IS YANG Model Augmentations for Additional Features - Version 1 [draft-acee-lsr-isis-yang-augmentation-v1-04] (17 pages) - Extensions to OSPF for Advertising Prefix Administrative Tags [draft-acee-lsr-ospf-admin-tags-07] (9 pages) - OSPF Transport Instance Extensions [draft-acee-lsr-ospf-transport-instance-02] (14 pages) - YANG Model for OSPFv3 Extended LSAs [draft-acee-lsr-ospfv3-extended-lsa-yang-06] (30 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-acee-lsr-ospf-yang-augmentation-v1-01] (23 pages) - IPv6 Source/Destination Routing using IS-IS [draft-baker-ipv6-isis-dst-src-routing-07] (12 pages) - IGP Flexible Algorithms (Flex-Algorithm) In IP Networks [draft-bonica-lsr-ip-flexalgo-01] (17 pages) - ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-chen-lsr-isis-rfc5316bis-02] (20 pages) - Update to OSPF Terminology [draft-fox-lsr-ospf-terminology-01] (5 pages) - Invalid TLV Handling in IS-IS [draft-ginsberg-lsr-isis-invalid-tlv-03] (8 pages) - IS-IS Application-Specific Link Attributes [draft-ginsberg-lsr-rfc8919bis-02] (25 pages) - Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints [draft-hegde-lsr-flex-algo-bw-con-02] (27 pages) - YANG Data Model for IS-IS SRv6 [draft-hu-isis-srv6-yang-06] (24 pages) - YANG Data Model for OSPF SRv6 [draft-hu-lsr-ospf-srv6-yang-04] (25 pages) - IPv6 Source/Destination Routing using IS-IS [draft-ietf-isis-ipv6-dst-src-routing-00] (12 pages) - Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS [draft-ietf-isis-mpls-elc-13] (7 pages) - IS-IS Routing with Reverse Metric [draft-ietf-isis-reverse-metric-17] (15 pages) - IS-IS Extensions for Segment Routing [draft-ietf-isis-segment-routing-extensions-25] (28 pages) - Signaling Maximum SID Depth (MSD) Using IS-IS [draft-ietf-isis-segment-routing-msd-19] (10 pages) - YANG Data Model for IS-IS Segment Routing [draft-ietf-isis-sr-yang-15] (25 pages) - IS-IS Application-Specific Link Attributes [draft-ietf-isis-te-app-19] (20 pages) - YANG Data Model for the IS-IS Protocol [draft-ietf-isis-yang-isis-cfg-42] (103 pages) - Algorithm Related IGP-Adjacency SID Advertisement [draft-ietf-lsr-algorithm-related-adjacency-sid-05] (16 pages) - IS-IS Optimal Distributed Flooding for Dense Topologies [draft-ietf-lsr-distoptflood-01] (13 pages) - Dynamic Flooding on Dense Graphs [draft-ietf-lsr-dynamic-flooding-13] (47 pages) - IGP Flexible Algorithm [draft-ietf-lsr-flex-algo-26] (42 pages) - Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints [draft-ietf-lsr-flex-algo-bw-con-06] (30 pages) - Flooding Topology Minimum Degree Algorithm [draft-ietf-lsr-flooding-topo-min-degree-06] (12 pages) - IGP Flexible Algorithms Reverse Affinity Constraint [draft-ietf-lsr-igp-flex-algo-reverse-affinity-00] (9 pages) - IGP Flexible Algorithms (Flex-Algorithm) In IP Networks [draft-ietf-lsr-ip-flexalgo-12] (23 pages) - Area Proxy for IS-IS [draft-ietf-lsr-isis-area-proxy-09] (20 pages) - IS-IS Extended Hierarchy [draft-ietf-lsr-isis-extended-hierarchy-06] (19 pages) - IS-IS Fast Flooding [draft-ietf-lsr-isis-fast-flooding-03] (25 pages) - IS-IS Flood Reflection [draft-ietf-lsr-isis-flood-reflection-12] (19 pages) - Invalid TLV Handling in IS-IS [draft-ietf-lsr-isis-invalid-tlv-03] (8 pages) - Restart Signaling for IS-IS [draft-ietf-lsr-isis-rfc5306bis-09] (22 pages) - IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-lsr-isis-rfc5316bis-07] (19 pages) - IS-IS Traffic Engineering (TE) Metric Extensions [draft-ietf-lsr-isis-rfc7810bis-05] (21 pages) - IS-IS Routing for Spine-Leaf Topology [draft-ietf-lsr-isis-spine-leaf-ext-02] (17 pages) - IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane [draft-ietf-lsr-isis-srv6-extensions-19] (25 pages) - YANG Data Model for IS-IS SRv6 [draft-ietf-lsr-isis-srv6-yang-03] (26 pages) - Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network [draft-ietf-lsr-isis-sr-vtn-mt-04] (9 pages) - IS-IS Topology-Transparent Zone [draft-ietf-lsr-isis-ttz-07] (25 pages) - IS-IS YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-isis-yang-augmentation-v1-05] (37 pages) - Extensions to OSPF for Advertising Prefix Administrative Tags [draft-ietf-lsr-ospf-admin-tags-09] (19 pages) - OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode [draft-ietf-lsr-ospf-bfd-strict-mode-10] (10 pages) - Advertising Layer 2 Bundle Member Link Attributes in OSPF [draft-ietf-lsr-ospf-l2bundles-10] (12 pages) - OSPF Prefix Originator Extensions [draft-ietf-lsr-ospf-prefix-originator-12] (9 pages) - OSPF Reverse Metric [draft-ietf-lsr-ospf-reverse-metric-13] (11 pages) - YANG Data Model for OSPF SRv6 [draft-ietf-lsr-ospf-srv6-yang-03] (25 pages) - Update to OSPF Terminology [draft-ietf-lsr-ospf-terminology-09] (7 pages) - OSPF-GT (Generalized Transport) [draft-ietf-lsr-ospf-transport-instance-04] (15 pages) - YANG Model for OSPFv3 Extended LSAs [draft-ietf-lsr-ospfv3-extended-lsa-yang-13] (29 pages) - OSPFv3 Extensions for SRv6 [draft-ietf-lsr-ospfv3-srv6-extensions-11] (29 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-ospf-yang-augmentation-v1-09] (59 pages) - IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) [draft-ietf-lsr-pce-discovery-security-support-13] (13 pages) - IS-IS Application-Specific Link Attributes [draft-ietf-lsr-rfc8919bis-04] (25 pages) - OSPF Application-Specific Link Attributes [draft-ietf-lsr-rfc8920bis-06] (24 pages) - A YANG Module for IS-IS Reverse Metric [draft-ietf-lsr-yang-isis-reverse-metric-06] (13 pages) - OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement [draft-ietf-ospf-lls-interface-id-09] (8 pages) - Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF [draft-ietf-ospf-mpls-elc-15] (8 pages) - Host Router Support for OSPFv2 [draft-ietf-ospf-ospfv2-hbit-12] (8 pages) - OSPFv3 Extensions for Segment Routing [draft-ietf-ospf-ospfv3-segment-routing-extensions-23] (18 pages) - Signaling Maximum SID Depth (MSD) Using OSPF [draft-ietf-ospf-segment-routing-msd-25] (11 pages) - "OSPF SR (Segment Routing) YANG Data Model">YANG Data Model for OSPF Segment Routing [draft-ietf-ospf-sr-yang-20] (26 pages) - OSPF Application-Specific Link Attributes [draft-ietf-ospf-te-link-attr-reuse-16] (19 pages) - OSPF Routing with Cross-Address Family Traffic Engineering Tunnels [draft-ietf-ospf-xaf-te-07] (8 pages) - YANG Data Model for the OSPF Protocol [draft-ietf-ospf-yang-29] (116 pages) - OSPF Strict-Mode for BFD [draft-ketant-lsr-ospf-bfd-strict-mode-03] (10 pages) - Advertising L2 Bundle Member Link Attributes in OSPF [draft-ketant-lsr-ospf-l2bundles-02] (10 pages) - OSPF Reverse Metric [draft-ketant-lsr-ospf-reverse-metric-02] (12 pages) - Dynamic Flooding on Dense Graphs [draft-li-lsr-dynamic-flooding-02] (37 pages) - Area Proxy for IS-IS [draft-li-lsr-isis-area-proxy-07] (20 pages) - OSPFv3 Extensions for SRv6 [draft-li-lsr-ospfv3-srv6-extensions-00] (23 pages) - Algorithm Related IGP-Adjacency SID Advertisement [draft-peng-lsr-algorithm-related-adjacency-sid-03] (13 pages) - OSPF Application-Specific Link Attributes [draft-ppsenak-lsr-rfc8920bis-02] (23 pages) - IS-IS Flood Reflection [draft-przygienda-lsr-flood-reflection-01] (17 pages) - Advertisement of Stub Link Attributes [draft-wang-lsr-stub-link-attributes-06] (14 pages) - IS-IS Optimal Distributed Flooding for Dense Topologies [draft-white-lsr-distoptflood-03] (12 pages) Requests for Comments: RFC8476: Signaling Maximum SID Depth (MSD) Using OSPF (11 pages) RFC8491: Signaling Maximum SID Depth (MSD) Using IS-IS (10 pages) RFC8500: IS-IS Routing with Reverse Metric (15 pages) RFC8510: OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement (8 pages) RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions (21 pages) RFC8666: OSPFv3 Extensions for Segment Routing (18 pages) RFC8667: IS-IS Extensions for Segment Routing (28 pages) RFC8687: OSPF Routing with Cross-Address Family Traffic Engineering Tunnels (8 pages) RFC8706: Restart Signaling for IS-IS (22 pages) RFC8770: Host Router Support for OSPFv2 (8 pages) RFC8918: Invalid TLV Handling in IS-IS (8 pages) RFC8919: IS-IS Application-Specific Link Attributes (20 pages) RFC8920: OSPF Application-Specific Link Attributes (19 pages) RFC9084: OSPF Prefix Originator Extensions (9 pages) RFC9088: Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS (7 pages) RFC9089: Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF (8 pages) RFC9129: YANG Data Model for the OSPF Protocol (116 pages) RFC9130: YANG Data Model for the IS-IS Protocol (103 pages) RFC9194: A YANG Module for IS-IS Reverse Metric (13 pages) RFC9339: OSPF Reverse Metric (11 pages) RFC9346: IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (19 pages) RFC9350: IGP Flexible Algorithm (42 pages) RFC9352: IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane (25 pages) RFC9353: IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) (13 pages) RFC9355: OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode (10 pages) RFC9356: Advertising Layer 2 Bundle Member Link Attributes in OSPF (12 pages) RFC9377: IS-IS Flood Reflection (19 pages) Link State Vector Routing (lsvr) -------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Gunter Van de Velde Ketan Talaulikar Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: lsvr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsvr Archive: https://mailarchive.ietf.org/arch/browse/lsvr/ Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. The Link-State Vector Routing (LSVR) Working Group is chartered to develop and document a hybrid routing protocol utilizing a combination of link-state and path-vector routing mechanisms. The LSVR WG will utilize existing IPv4/IPv6 transport, packet formats and error handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (RFC7752) to facilitate Link-State Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of link attributes, neighbor information, and other and other potential attributes that can be utilized to make routing decisions. The LSVR specification is initially focused on operation within a single datacenter (DC) as a single distribution domain, which is defined as a set of participating nodes in a single administrative domain. Routing protocol functionality defined by LSVR would be typically routing within a datacenter’s underlay routing plane. The work will include coexistence considerations with BGP IPv4/IPv6 unicast address families installing and advertising routes into the same RIB. The WG will consider the effects (if any) of deploying the LSVR protocol while concurrently using the same transport session as other existing BGP address families. These considerations will be documented as part of the main protocol specification. A mechanism to be able to independently deploy LSVR from other address families may be defined (as needed). The LSVR protocol is intended as a self-standing routing protocol even if using existing BGP transport mechanisms and encodings, or if sharing the same transport session with other existing BGP address families. Similar as existing routing protocols, the LSVR protocol will not internally combine the route selection mechanisms or share routing information, except through common external interaction methods in the RIB. In order to achieve the noted objective, the working group will focus on standardization of protocol functionality, defining Link-State Vectors (LSVs) and defining standard path-vector route selection utilizing the Dijkstra SPF based algorithm, BGP-4 protocol mechanics and BGP-LS NRLI encoding. The working group will provide specifications to manage routing information from other unicast routing protocols or BGP address families to common prefixes. The LSVR WG is chartered to deliver the following documents: - Specification document describing LSV with standard Dijkstra SPF route/path selection (calculation) utilizing existing BGP protocol baseline functionality and BGP-LS packet encoding formats - Specification documenting protocol extensions required to efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with scope to include privacy and security considerations - The impact of these extensions to the security properties of BGP will be studied and documented - New attack vectors will be explored and documented - Mitigations to any new attack vectors identified will be discussed and documented - Applicability Statement for the use of LSVR in the Datacenter - YANG model specification for LSVR management The WG will closely collaborate with the idr WG. Any modifications or extension to BGP that will not be specifically constrained to be used by LSVR must be carried out in the idr WG, but may be done in this WG after agreement with all the relevant chairs and the responsible Area Directors. Goals and Milestones: Mar 2019 - LSVR with standard Dijkstra path selection Mar 2019 - LSV distribution using BGP transport Mar 2019 - Applicability statement for LSVR in DCs Jul 2019 - YANG specification for LSVR Internet-Drafts: - Usage and Applicability of Link State Vector Routing in Data Centers [draft-ietf-lsvr-applicability-09] (14 pages) - A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF [draft-ietf-lsvr-bgp-ls-yang-01] (38 pages) - BGP Link-State Shortest Path First (SPF) Routing [draft-ietf-lsvr-bgp-spf-22] (38 pages) - Layer-3 Discovery and Liveness [draft-ietf-lsvr-l3dl-09] (38 pages) - Layer-3 Discovery and Liveness Signing [draft-ietf-lsvr-l3dl-signing-04] (10 pages) - L3DL Upper-Layer Protocol Configuration [draft-ietf-lsvr-l3dl-ulpc-03] (9 pages) - Link State Over Ethernet [draft-ietf-lsvr-lsoe-01] (27 pages) - Usage and Applicability of Link State Vector Routing in Data Centers [draft-keyupate-lsvr-applicability-02] (11 pages) - Shortest Path Routing Extensions for BGP Protocol [draft-keyupate-lsvr-bgp-spf-00] (15 pages) - Layer 3 Discovery and Liveness Signing [draft-ymbk-lsvr-l3dl-signing-01] (9 pages) - L3DL Upper Layer Protocol Configuration [draft-ymbk-lsvr-l3dl-ulpc-03] (8 pages) - Link State Over Ethernet [draft-ymbk-lsvr-lsoe-03] (24 pages) No Requests for Comments Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Luigi Iannone Padma Pillay-Esnault Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Secretary: Alberto Rodriguez-Natal Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Description of Working Group: The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The scope of the LISP technology is potentially applicable to have a large span, including unicast and multicast overlays at Layer 2 as well as at Layer 3, encompassing NAT traversal, VPNs, and supporting mobility as a general feature, independently of whether it is a mobile user or a migrating Virtual Machine (VM). Hence, the LISP technology is applicable in both Data Centers and public Internet environments. The LISP WG is chartered to continue work on the LISP base protocol and produce standard-track documents. In order to produce a coherent set of documents, the first (and high priority) work item of the LISP Working Group is to develop a standard-track solution based on the completed Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs and doing the necessary enhancements to support a base set of standards track RFCs. The group will review the current set of Working Group documents to identify potential standards-track documents and do the necessary enhancements to support standards-track. In parallel with the previous main work item, the LISP WG will work on the items listed below: - Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH (Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Groups such as NVO3 and SFC. - Alternative Mapping System Design: By extending LISP with new multi-protocols support, it becomes necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models, independent mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol). - Mobility: Some LISP deployment scenarios include mobile nodes (in mobile environments) or Virtual Machines (VMs in data centers), hence, support needs to be provided in order to achieve seamless connectivity. This work item may benefit from experience of other Working Groups like DMM (Distributed Mobility Management) or NVO3 (for VM migration). - Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. This may need discussion with other Working Groups related to multicast solutions (e.g. PIM). - Data-Plane Encryption: In some scenarios, it may be desirable to encrypt LISP encapsulated traffic. In this case, the data-plane encryption mechanism itself and support for control-plane security material exchange needs to be specified. Any solution proposed in this work item has to be reviewed by security experts. - NAT-Traversal: Support for NAT-traversal solution in deployments where LISP tunnel routers are separated from correspondent tunnel routers by a NAT (e.g., LISP mobile node). - Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components of standards-track documents. Similar to the main work item, documents for these work items will as well target standard-track unless the document is of a different maturity level (e.g., Informational or Experimental). In the latter case, the Working Group will evaluate the maturity level and propose a recommended track for the document. Collaboration with other working groups, as stated in the different work items (e.g., PIM, NVO3, DMM, SFC), is important to ensure to have technologies that work smoothly together. The LISP Working Group is chartered to work on the LISP technology. It may use technologies developed in other working groups, but if it identifies needs for extensions or modifications, those extensions and modifications will be addressed in the working groups that developed those technologies. The LISP Working Group may provide feedback to other working groups based on experience gained while using their solutions. Goals and Milestones: Aug 2016 - Submit a LISP control-plane security mechanism document to the IESG for consideration as Experimental Apr 2017 - Submit a LISP unicast data-plane specification (6830bis) document to the IESG for consideration as Proposed Standard Apr 2017 - Submit a LISP multicast data-plane specification (6831bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP control-plane specification (6833bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP interworking specification (6832bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP Mobility document to the IESG for consideration as Proposed Standard Internet-Drafts: - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-boucadair-lisp-rfc8113bis-01] (5 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-chiappa-lisp-architecture-01] (19 pages) - An Introduction to the LISP Location-Identity Separation System [draft-chiappa-lisp-introduction-01] (29 pages) - LISP Configuration YANG Model [draft-ermagan-lisp-yang-01] (80 pages) - LISP Data-Plane Confidentiality [draft-farinacci-lisp-crypto-01] (10 pages) - LISP Control-Plane ECDSA Authentication and Authorization [draft-farinacci-lisp-ecdsa-auth-03] (17 pages) - LISP EID Anonymity [draft-farinacci-lisp-eid-anonymity-02] (9 pages) - LISP Geo-Coordinate Use-Cases [draft-farinacci-lisp-geo-15] (13 pages) - LISP Canonical Address Format (LCAF) [draft-farinacci-lisp-lcaf-10] (29 pages) - LISP Distinguished Name Encoding [draft-farinacci-lisp-name-encoding-15] (9 pages) - LISP Predictive RLOCs [draft-farinacci-lisp-predictive-rlocs-02] (13 pages) - LISP Traffic Engineering Use-Cases [draft-farinacci-lisp-te-12] (18 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-iannone-6834bis-00] (19 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-24] (75 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-ietf-lisp-6834bis-14] (15 pages) - Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) [draft-ietf-lisp-alt-10] (25 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-ietf-lisp-architecture-00] (19 pages) - Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality [draft-ietf-lisp-crypto-10] (18 pages) - Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) [draft-ietf-lisp-ddt-09] (44 pages) - Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations [draft-ietf-lisp-deployment-12] (30 pages) - LISP Control-Plane ECDSA Authentication and Authorization [draft-ietf-lisp-ecdsa-auth-10] (17 pages) - LISP EID Anonymity [draft-ietf-lisp-eid-anonymity-14] (12 pages) - Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [draft-ietf-lisp-eid-block-13] (12 pages) - Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [draft-ietf-lisp-eid-block-mgmnt-07] (10 pages) - LISP L2/L3 EID Mobility Using a Unified Control Plane [draft-ietf-lisp-eid-mobility-11] (26 pages) - LISP Geo-Coordinate Use-Cases [draft-ietf-lisp-geo-01] (14 pages) - Locator/ID Separation Protocol (LISP) Generic Protocol Extension [draft-ietf-lisp-gpe-19] (14 pages) - Locator/ID Separation Protocol (LISP) Impact [draft-ietf-lisp-impact-05] (18 pages) - Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites [draft-ietf-lisp-interworking-06] (19 pages) - An Architectural Introduction to the Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-introduction-15] (24 pages) - LISP Canonical Address Format (LCAF) [draft-ietf-lisp-lcaf-22] (36 pages) - The Locator/ID Separation Protocol Internet Groper (LIG) [draft-ietf-lisp-lig-06] (12 pages) - LISP Map Server Reliable Transport [draft-ietf-lisp-map-server-reliable-transport-01] (22 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-ietf-lisp-map-versioning-09] (21 pages) - Locator/ID Separation Protocol (LISP) MIB [draft-ietf-lisp-mib-13] (66 pages) - LISP Mobile Node [draft-ietf-lisp-mn-13] (25 pages) - Locator/ID Separation Protocol (LISP) Map-Server Interface [draft-ietf-lisp-ms-16] (13 pages) - The Locator/ID Separation Protocol (LISP) for Multicast Environments [draft-ietf-lisp-multicast-14] (28 pages) - LISP Distinguished Name Encoding [draft-ietf-lisp-name-encoding-01] (8 pages) - Network-Hexagons:Geolocation Mobility Network Based On H3 and LISP [draft-ietf-lisp-nexagon-50] (32 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-ietf-lisp-perspective-00] (21 pages) - LISP Predictive RLOCs [draft-ietf-lisp-predictive-rlocs-12] (16 pages) - Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-pubsub-15] (22 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-rfc6830bis-38] (33 pages) - Locator/ID Separation Protocol (LISP) Control Plane [draft-ietf-lisp-rfc6833bis-31] (42 pages) - Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations [draft-ietf-lisp-rfc8113bis-03] (5 pages) - Locator/ID Separation Protocol Security (LISP-SEC) [draft-ietf-lisp-sec-29] (23 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-ietf-lisp-signal-free-multicast-09] (21 pages) - LISP Traffic Engineering Use-Cases [draft-ietf-lisp-te-12] (19 pages) - Locator/ID Separation Protocol (LISP) Threat Analysis [draft-ietf-lisp-threats-15] (19 pages) - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-ietf-lisp-type-iana-06] (6 pages) - Vendor-Specific LISP Canonical Address Format (LCAF) [draft-ietf-lisp-vendor-lcaf-12] (5 pages) - LISP Virtual Private Networks (VPNs) [draft-ietf-lisp-vpn-11] (17 pages) - LISP YANG Model [draft-ietf-lisp-yang-19] (82 pages) - LISP Mobile Node [draft-meyer-lisp-mn-16] (22 pages) - LISP Virtual Private Networks (VPNs) [draft-moreno-lisp-vpn-00] (16 pages) - LISP L2/L3 EID Mobility Using a Unified Control Plane [draft-portoles-lisp-eid-mobility-02] (23 pages) - Publish/Subscribe Functionality for LISP [draft-rodrigueznatal-lisp-pubsub-02] (10 pages) - Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00] (5 pages) - LISP Impact [draft-saucez-lisp-impact-07] (15 pages) Requests for Comments: RFC6830: The Locator/ID Separation Protocol (LISP) (75 pages) * Updates RFC8113 * Obsoletes RFC9300 * Obsoletes RFC9301 RFC6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments (28 pages) RFC6832: Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites (19 pages) RFC6833: Locator/ID Separation Protocol (LISP) Map-Server Interface (13 pages) * Obsoletes RFC9301 RFC6834: Locator/ID Separation Protocol (LISP) Map-Versioning (21 pages) * Obsoletes RFC9302 RFC6835: The Locator/ID Separation Protocol Internet Groper (LIG) (12 pages) RFC6836: Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) (25 pages) RFC7052: Locator/ID Separation Protocol (LISP) MIB (66 pages) RFC7215: Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations (30 pages) RFC7834: Locator/ID Separation Protocol (LISP) Impact (18 pages) RFC7835: Locator/ID Separation Protocol (LISP) Threat Analysis (19 pages) RFC7954: Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block (12 pages) RFC7955: Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block (10 pages) RFC8060: LISP Canonical Address Format (LCAF) (36 pages) * Updates RFC9306 RFC8061: Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality (18 pages) RFC8111: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) (44 pages) RFC8113: Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations (6 pages) * Obsoletes RFC9304 RFC8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast (21 pages) RFC9299: An Architectural Introduction to the Locator/ID Separation Protocol (LISP) (24 pages) RFC9300: The Locator/ID Separation Protocol (LISP) (33 pages) RFC9301: Locator/ID Separation Protocol (LISP) Control Plane (42 pages) RFC9302: Locator/ID Separation Protocol (LISP) Map-Versioning (15 pages) RFC9303: Locator/ID Separation Protocol Security (LISP-SEC) (23 pages) RFC9304: Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations (5 pages) RFC9305: Locator/ID Separation Protocol (LISP) Generic Protocol Extension (14 pages) RFC9306: Vendor-Specific LISP Canonical Address Format (LCAF) (5 pages) Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Don Fedyk Ronald in 't Velt Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: manet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/manet Archive: https://mailarchive.ietf.org/arch/browse/manet/ Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing applications within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. The WG will put special attention on the standardization of a bidirectional, dynamic link exchange protocol (DLEP) between the router and the modem. The MANET WG will coordinate with other Working Groups, such as the pim WG for multicast support, the Routing Area WG (rtgwg), OSPF WG and Babel WG on the general use of DLEP, as well as the IPPM WG on topics related to traffic classification. The MANET WG is responsible for the maintenance of OLSRv2 [RFC 7181], NHDP [RFC 6130] and the Generalized MANET Packet/Message Format [RFC5444], and their extensions. Work Items: - Develop a dynamic link exchange protocol (DLEP). - DLEP extension to provide a credit-windowing scheme for destination-specific flow control. - DLEP extensions for reporting statistics by traffic classification. - Multicast MANET protocol framework based on Simplified Multicast Forwarding [RFC 6621] for scoped forwarding within MANET networks. As part of this framework the WG will produce a well defined MANET multicast forwarding information base (FIB). - Document outlining challenges and best practices for deploying and managing MANET networks. Goals and Milestones: Nov 2016 - MANET Management Document (Informational) Nov 2016 - DLEP Credit Windowing Extensions (Standards Track) Nov 2016 - DLEP (Standards Track) Jul 2017 - DLEP traffic extensions (Standards Track) Nov 2017 - Multicast FIB (Standards Track) Internet-Drafts: - Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) [draft-clausen-manet-olsrv2-sec-threats-01] (24 pages) - Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format [draft-clausen-manet-rfc5444-usage-00] (17 pages) - Link Identifier Extension to DLEP [draft-dlep-lid-02] (7 pages) - The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks (ADMR) [draft-ietf-manet-admr-01] (63 pages) - Ad hoc Multicast Routing protocol utilizing Increasing id-numberS (AMRIS) Functional Specification [draft-ietf-manet-amris-spec-00] (23 pages) - Ad hoc On-Demand Distance Vector (AODV) Routing [draft-ietf-manet-aodv-13] (37 pages) - Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing [draft-ietf-manet-aodvv2-16] (84 pages) - MANET Routing Protocol Applicability Statement [draft-ietf-manet-appl-00] (3 pages) - IP Flooding in Ad hoc Mobile Networks [draft-ietf-manet-bcast-00] (0 pages) - Cluster Based Routing Protocol(CBRP) Functional Specification [draft-ietf-manet-cbrp-spec-01] (27 pages) - Core Extraction Distributed Ad hoc Routing (CEDAR) Specification [draft-ietf-manet-cedar-spec-00] (29 pages) - Credit Windowing extension for DLEP [draft-ietf-manet-credit-window-07] (13 pages) - Differential Destination Multicast (DDM) Specification [draft-ietf-manet-ddm-00] (21 pages) - Dynamic Link Exchange Protocol (DLEP) [draft-ietf-manet-dlep-29] (82 pages) - DLEP Credit-Based Flow Control Messages and Data Items [draft-ietf-manet-dlep-credit-flow-control-11] (18 pages) - DLEP DiffServ Aware Credit Window Extension [draft-ietf-manet-dlep-da-credit-extension-13] (6 pages) - DLEP IEEE 802.1Q Aware Credit Window Extension [draft-ietf-manet-dlep-ether-credit-extension-01] (6 pages) - Dynamic Link Exchange Protocol (DLEP) Latency Range Extension [draft-ietf-manet-dlep-latency-extension-05] (5 pages) - Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension [draft-ietf-manet-dlep-lid-extension-06] (9 pages) - Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension [draft-ietf-manet-dlep-multi-hop-extension-07] (10 pages) - Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension [draft-ietf-manet-dlep-pause-extension-08] (12 pages) - DLEP Traffic Classification Data Item [draft-ietf-manet-dlep-traffic-classification-08] (13 pages) - The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 [draft-ietf-manet-dsr-10] (107 pages) - Flow State in the Dynamic Source Routing Protocol for Mobile Ad Hoc Networks [draft-ietf-manet-dsrflow-00] (30 pages) - Dynamic MANET On-demand (AODVv2) Routing [draft-ietf-manet-dymo-26] (60 pages) - Definition of Managed Objects for the DYMO Manet Routing Protocol [draft-ietf-manet-dymo-mib-04] (41 pages) - Fisheye State Routing Protocol (FSR) for Ad Hoc Networks [draft-ietf-manet-fsr-03] (17 pages) - IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols [draft-ietf-manet-iana-07] (5 pages) - Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols [draft-ietf-manet-ibs-05] (17 pages) - An Internet MANET Encapsulation Protocol (IMEP) Specification [draft-ietf-manet-imep-spec-01] (37 pages) - INSIGNIA [draft-ietf-manet-insignia-01] (22 pages) - Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations [draft-ietf-manet-issues-02] (12 pages) - Jitter Considerations in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-jitter-04] (12 pages) - Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks [draft-ietf-manet-lanmar-05] (21 pages) - Long-lived Ad Hoc Routing based on the Concept of Associativity [draft-ietf-manet-longlived-adhoc-routing-00] (18 pages) - Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing [draft-ietf-manet-maodv-00] (24 pages) - Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-15] (88 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-nhdp-mib-19] (67 pages) - Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-nhdp-olsrv2-sec-05] (15 pages) - Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs [draft-ietf-manet-nhdp-olsrv2-tlv-extension-05] (16 pages) - An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-optimization-04] (9 pages) - Using Integrity Check Values and Timestamps For Router Admittance in NHDP [draft-ietf-manet-nhdp-sec-02] (12 pages) - Security Threats for the Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-sec-threats-06] (20 pages) - On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks [draft-ietf-manet-odmrp-04] (29 pages) - Optimized Link State Routing Protocol (OLSR) [draft-ietf-manet-olsr-11] (75 pages) - The Optimized Link State Routing Protocol Version 2 [draft-ietf-manet-olsrv2-19] (115 pages) - Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-dat-metric-12] (21 pages) - Snapshot of OLSRv2-Routed MANET Management [draft-ietf-manet-olsrv2-management-snapshot-03] (14 pages) - Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale [draft-ietf-manet-olsrv2-metrics-rationale-04] (25 pages) - Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 [draft-ietf-manet-olsrv2-mib-12] (86 pages) - Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-multipath-15] (26 pages) - Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-multitopology-07] (23 pages) - Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-rmpr-optimization-01] (5 pages) - Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-sec-threats-04] (26 pages) - Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format [draft-ietf-manet-packetbb-17] (60 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-packetbb-sec-09] (21 pages) - Relative Distance Micro-discovery Ad Hoc Routing (RDMAR) Protocol [draft-ietf-manet-rdmar-00] (15 pages) - Definition of Managed Objects for Performance Reporting [draft-ietf-manet-report-mib-04] (35 pages) - Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 [draft-ietf-manet-rfc5444-usage-07] (29 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-rfc6622-bis-06] (31 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-rfc6779bis-07] (72 pages) - A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks [draft-ietf-manet-simple-mbcast-01] (11 pages) - Simplified Multicast Forwarding [draft-ietf-manet-smf-14] (55 pages) - Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process [draft-ietf-manet-smf-mib-13] (65 pages) - Security Threats to Simplified Multicast Forwarding (SMF) [draft-ietf-manet-smf-sec-threats-06] (15 pages) - SOURCE TREE ADAPTIVE ROUTING (STAR) PROTOCOL [draft-ietf-manet-star-00] (26 pages) - Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) [draft-ietf-manet-tbrpf-11] (46 pages) - Mobile Ad Hoc Networking Terminology [draft-ietf-manet-term-01] (9 pages) - Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-timetlv-08] (14 pages) - TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format [draft-ietf-manet-tlv-naming-05] (15 pages) - Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification [draft-ietf-manet-tora-spec-04] (23 pages) - The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks [draft-ietf-manet-zone-brp-02] (13 pages) - The Intrazone Routing Protocol (IARP) for Ad Hoc Networks [draft-ietf-manet-zone-iarp-02] (11 pages) - The Interzone Routing Protocol (IERP) for Ad Hoc Networks [draft-ietf-manet-zone-ierp-02] (14 pages) - The Zone Routing Protocol (ZRP) for Ad Hoc Networks [draft-ietf-manet-zone-zrp-04] (11 pages) - AMRoute: Adhoc Multicast Routing Protocol [draft-talpade-manet-amroute-00] (24 pages) Requests for Comments: RFC2501: Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (12 pages) RFC3561: Ad hoc On-Demand Distance Vector (AODV) Routing (37 pages) RFC3626: Optimized Link State Routing Protocol (OLSR) (75 pages) RFC3684: Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (46 pages) * Updates RFC9141 RFC4728: The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 (107 pages) RFC5148: Jitter Considerations in Mobile Ad Hoc Networks (MANETs) (12 pages) RFC5444: Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format (60 pages) * Updates RFC7631 * Updates RFC8245 RFC5497: Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) (14 pages) RFC5498: IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols (5 pages) RFC6130: Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (88 pages) * Updates RFC7183 * Updates RFC7188 * Updates RFC7466 RFC6621: Simplified Multicast Forwarding (55 pages) RFC6622: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) (21 pages) * Obsoletes RFC7182 RFC6779: Definition of Managed Objects for the Neighborhood Discovery Protocol (67 pages) * Obsoletes RFC7939 RFC7181: The Optimized Link State Routing Protocol Version 2 (115 pages) * Updates RFC7183 * Updates RFC7187 * Updates RFC7188 * Updates RFC7466 RFC7182: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) (31 pages) RFC7183: Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) (15 pages) RFC7184: Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 (86 pages) RFC7185: Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale (25 pages) RFC7186: Security Threats for the Neighborhood Discovery Protocol (NHDP) (20 pages) * Updates RFC7985 RFC7187: Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (5 pages) RFC7188: Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs (16 pages) * Updates RFC7722 RFC7367: Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process (65 pages) RFC7466: An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (9 pages) RFC7631: TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format (15 pages) * Updates RFC7722 RFC7722: Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (23 pages) RFC7779: Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) (21 pages) RFC7859: Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols (17 pages) RFC7939: Definition of Managed Objects for the Neighborhood Discovery Protocol (72 pages) RFC7985: Security Threats to Simplified Multicast Forwarding (SMF) (15 pages) RFC8116: Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) (26 pages) RFC8175: Dynamic Link Exchange Protocol (DLEP) (82 pages) RFC8218: Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) (26 pages) RFC8245: Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 (29 pages) RFC8629: Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension (10 pages) RFC8651: Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension (12 pages) RFC8703: Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension (9 pages) RFC8757: Dynamic Link Exchange Protocol (DLEP) Latency Range Extension (5 pages) Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2023-02-27 Current Status: Active Chairs: Loa Andersson Nicolai Leymann Tarek Saad Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Tech Advisor: George Swallow Secretary: Mach Chen Mailing Lists: General Discussion: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: https://mailarchive.ietf.org/arch/browse/mpls/ Description of Working Group: The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) for MPLS systems including the necessary management objects expressed as YANG models or MIB modules. The current WG focus areas and work items are: - Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs, in coordination with other working groups that work in overlapping areas including the BESS, BFD, CCAMP, OPSAWG, PALS, SPRING, and TEAS working groups. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE for packet networks, and LSP Ping to meet new requirements. - Document MPLS-specific aspects of traffic engineering including for multi-areas/multi-AS scenarios in cooperation with the TEAS working group. - Coordinate the work on RSVP-TE with CCAMP and TEAS. In the cases where there is an overlap, generic parts will be done by the TEAS working group, MPLS data plane specific parts will be done by the MPLS working group, and support for any other specific data planes will be done by the CCAMP working group. The TEAS working group acts as the hub for coordinating this work, and the MPLS working group will track agreements about work to be done in this working group through milestones in this charter. - Define data models for MPLS working group related solutions. YANG models and MIB modules may be considered. Coordinate with the LIME and NETMOD working groups for core YANG models. - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications. - Define the necessary extensions for MPLS key protocols for dual- stack and IPv6-only networks. - Document current implementation practices for MPLS load sharing. - Document mechanisms for securing MPLS protocols and data plane. - Document mechanisms for adding multi-topology support to existing MPLS protocols. - Define the necessary protection protocols and scenarios for transport profile MPLS applications - Document use cases for MPLS protocols. Goals and Milestones: Mar 2015 - Submit draft-ietf-mpls-tp-oam-id-mib for publication May 2015 - ++ Progress draft-ietf-mpls-seamless-mcast to publication May 2015 - ++ Progress draft-ietf-mpls-ldp-ip-pw-capability to publication May 2015 - ++ Progress draft-ietf-mpls-ldp-ipv6 for publication to publication May 2015 - Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion May 2015 - Submit draft-ietf-mpls-mldp-node-protection for publication May 2015 - Submit draft-ietf-mpls-lsp-ping-relay-reply for publication Jun 2015 - Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication Jun 2015 - Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication Jun 2015 - Submit draft-ietf-mpls-seamless-mpls for publication Jun 2015 - ++ Progress draft-ietf-mpls-in-udp to publication Jun 2015 - ++ Progress draft-ietf-mpls-oam-ipv6-rao to publication Jun 2015 - ++ Progress draft-ietf-mpls-proxy-lsp-ping to publication Jun 2015 - Submit draft-ietf-mpls-entropy-lsp-ping for publication Jul 2015 - Submit draft-ietf-mpls-te-express-path Aug 2015 - Submit draft-ietf-mpls-tp-linear-protection-mib Aug 2015 - Submit draft-ietf-mpls-lsp-ping-lag-multipath for publication Aug 2015 - Submit draft-ietf-mpls-ldp-mrt for publication Aug 2015 - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Done - Submit documents from original MPLS effort to IESG Done - Framework for IP multicast over label-switched paths ready for advancement. Done - LDP fault tolerance specification ready for advancement to Proposed Standard. Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done - Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Done - Submit draft-ietf-mpls-ldp-gtsm for publication Done - Submit draft-ietf-mpls-entropy-label for publication Done - Submit draft-ietf-mpls-tp-itu-t-identifiers for publication Done - Submit draft-ietf-mpls-mldp-in-band-signaling for publication Done - Submit draft-ietf-mpls-tp-security-framework for publication Done - Submit draft-ietf-mpls-ipv6-pw-lsp-ping for publication Done - Submit draft-ietf-mpls-gach-adv for publication Done - Submit draft-ietf-mpls-tp-ring-protection for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-retire-ach-tlv for publication Done - Submit draft-ietf-mpls-tp-rosetta-stone for publication Done - Submit draft-ietf-mpls-mldp-hsmp for publication Done - Submit draft-ietf-mpls-ldp-dod for publication Done - Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication Done - Submit draft-ietf-mpls-targeted-mldp for publication Done - Submit draft-ietf-mpls-tp-mip-mep-map for publication Done - Submit draft-ietf-mpls-tp-p2mp-framework for publication Done - draft-ietf-mpls-tp-psc-itu Done - Submit draft-ietf-mpls-moving-iana-registries for publication Done - Submit draft-ietf-mpls-forwardig for publication Done - Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication Done - Submit draft-ietf-mpls-extended-admin-group for publication Done - Submit draft-ietf-mpls-special-purpose-labels Done - Submit draft-ietf-mpls-ldp-multi-topology for publication Done - Submit draft-ietf-mpls-psc-updates for publication Done - Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication Done - Submit draft-ietf-mpls-ldp-applicability-label-adv for publication Done - Submit draft-ietf-mpls-smp-requirements for publication Done - Submit draft-ietf-mpls-deprecate-bgp-entropy-label for publication Done - Submit draft-ietf-mpls-mldp-in-band-wildcard-encoding for publication Done - Submit draft-ietf-mpls-pim-sm-over-mldp Done - Submit draft-ietf-mpls-tp-te-mib for publication Done - Submit draft-ietf-mpls-p2mp-loose-path-reopt for publicatiion Done - Submit draft-ietf-mpls-ipv6-only-gap for publication Done - Submit draft-ietf-mpls-proxy-lsp-ping fpr publication Done - Submit draft-ietf-mpls-ldp-ipv6 for publication Done - ** Progress draft-ietf-mpls-pim-sm-over-mldp to publication Done - Submit draft-ietf-mpls-seamless-mcast for publication Done - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Done - Submit draft-ietf-mpls-in-udp for publication Done - ++ Progress draft-ietf-mpls-lsp-ping-registry to publication Done - Submit draft-ietf-mpls-oam-ipv6-rao for publication Done - Submit draft-ietf-mpls-lsp-ping-registry for publication Internet-Drafts: - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) [draft-akiya-mpls-entropy-lsp-ping-04] (21 pages) - Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces [draft-akiya-mpls-lsp-ping-lag-multipath-05] (27 pages) - Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification [draft-akiya-mpls-lsp-ping-reply-mode-simple-03] (11 pages) - Updating the IANA MPLS LSP Ping Parameters [draft-andersson-mpls-lsp-ping-registries-update-02] (12 pages) - Updates to RFC 4379 IANA section [draft-andersson-mpls-lsp-ping-upd-00] (4 pages) - MPLS Network Actions Framework [draft-andersson-mpls-mna-fwk-04] (18 pages) - The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols [draft-andersson-mpls-sig-decision-03] (11 pages) - LDP Extensions to Support Maximally Redundant Trees [draft-atlas-mpls-ldp-mrt-03] (16 pages) - Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions [draft-atlas-mpls-te-express-path-04] (10 pages) - Requirements for MPLS Network Action Indicators and MPLS Ancillary Data [draft-bocci-mpls-miad-adi-requirements-04] (10 pages) - LSP Self-Ping [draft-bonica-mpls-self-ping-06] (11 pages) - MPLS Flow Identification Considerations [draft-bryant-mpls-flow-ident-03] (11 pages) - MPLS Performance Measurement UDP Return Path [draft-bryant-mpls-oam-udp-return-02] (8 pages) - RFC6374 Synonymous Flow Labels [draft-bryant-mpls-rfc6374-sfl-04] (20 pages) - A Simple Control Protocol for MPLS SFLs [draft-bryant-mpls-sfl-control-09] (14 pages) - Synonymous Flow Label Framework [draft-bryant-mpls-sfl-framework-05] (10 pages) - MPLS Segment Routing in IP Networks [draft-bryant-mpls-unified-ip-sr-03] (18 pages) - PSC protocol updates for non-revertive operation [draft-cdh-mpls-tp-psc-non-revertive-01] (23 pages) - Refresh Interval Independent FRR Facility Protection [draft-chandra-mpls-ri-rsvp-frr-04] (24 pages) - Encapsulation For MPLS Performance Measurement with Alternate Marking Method [draft-cheng-mpls-inband-pm-encapsulation-04] (14 pages) - MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology [draft-cheng-mpls-tp-shared-ring-protection-06] (46 pages) - Extensions to RSVP-TE for LSP Egress Local Protection [draft-chen-mpls-p2mp-egress-protection-11] (15 pages) - Extensions to RSVP-TE for LSP Ingress Local Protection [draft-chen-mpls-p2mp-ingress-protection-11] (28 pages) - MultiProtocol Label Switching (MPLS) Source Label [draft-chen-mpls-source-label-06] (13 pages) - Use Cases and Requirements for MPLS-TP multi-failure protection [draft-cui-mpls-tp-mfp-use-case-and-requirements-08] (8 pages) - IANA registries for LSP ping Code Points [draft-decraene-mpls-lsp-ping-registry-00] (6 pages) - Supporting the Exercise command for PSC linear protection protocol [draft-dj-mpls-tp-exer-psc-02] (10 pages) - Application-aware Targeted LDP [draft-esale-mpls-app-aware-tldp-03] (17 pages) - LDP Extensions for RMR [draft-esale-mpls-ldp-rmr-extensions-02] (13 pages) - An MPLS-Based Forwarding Plane for Service Function Chaining [draft-farrel-mpls-sfc-05] (24 pages) - MPLS Data Plane Encapsulation for In-situ OAM Data [draft-gandhi-mpls-ioam-sr-06] (17 pages) - Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane [draft-gandhi-mpls-rfc6374-sr-05] (20 pages) - Gap Analysis for Operating IPv6-only MPLS Networks [draft-george-mpls-ipv6-only-gap-05] (24 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes [draft-hegde-mpls-spring-epe-oam-07] (17 pages) - IANA Registry for the First Nibble Following a Label Stack [draft-ietf-mpls-1stnibble-00] (13 pages) - Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages [draft-ietf-mpls-3209-patherr-06] (7 pages) - Application-Aware Targeted LDP [draft-ietf-mpls-app-aware-tldp-09] (18 pages) - Multiprotocol Label Switching Architecture [draft-ietf-mpls-arch-07] (61 pages) - MPLS using LDP and ATM VC Switching [draft-ietf-mpls-atm-04] (20 pages) - A YANG Data Model for MPLS Base [draft-ietf-mpls-base-yang-17] (29 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-bfd-directed-23] (11 pages) - Carrying Label Information in BGP-4 [draft-ietf-mpls-bgp4-mpls-05] (8 pages) - Graceful Restart Mechanism for BGP with MPLS [draft-ietf-mpls-bgp-mpls-restart-05] (10 pages) - Link Bundling in MPLS Traffic Engineering (TE) [draft-ietf-mpls-bundle-06] (12 pages) - Link Bundling Management Information Base [draft-ietf-mpls-bundle-mib-04] (52 pages) - Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field [draft-ietf-mpls-cosfield-def-08] (9 pages) - Constraint-Based LSP Setup using LDP [draft-ietf-mpls-cr-ldp-06] (42 pages) - Applicability Statement for CR-LDP [draft-ietf-mpls-crldp-applic-01] (7 pages) - Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) [draft-ietf-mpls-crldp-unnum-10] (8 pages) - LSP Modification Using CR-LDP [draft-ietf-mpls-crlsp-modify-03] (11 pages) - Deprecation of BGP Entropy Label Capability Attribute [draft-ietf-mpls-deprecate-bgp-entropy-label-02] (4 pages) - Multi-Protocol Label Switching (MPLS) Support of Differentiated Services [draft-ietf-mpls-diff-ext-09] (64 pages) - Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-ext-01] (12 pages) - Requirements for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-reqts-00] (13 pages) - Avoiding Equal Cost Multipath Treatment in MPLS Networks [draft-ietf-mpls-ecmp-bcp-03] (8 pages) - A Proposal to Incorporate ECN in MPLS [draft-ietf-mpls-ecn-00] (9 pages) - MPLS Egress Protection Framework [draft-ietf-mpls-egress-protection-framework-07] (25 pages) - Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms [draft-ietf-mpls-egress-tlv-for-nil-fec-06] (10 pages) - The Use of Entropy Labels in MPLS Forwarding [draft-ietf-mpls-entropy-label-06] (25 pages) - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) [draft-ietf-mpls-entropy-lsp-ping-05] (23 pages) - Removing a Restriction on the use of MPLS Explicit NULL [draft-ietf-mpls-explicit-null-02] (7 pages) - Component Link Recording and Resource Control for TE Links [draft-ietf-mpls-explicit-resource-control-bundle-10] (13 pages) - Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) [draft-ietf-mpls-extended-admin-group-07] (7 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute [draft-ietf-mpls-fastreroute-mib-21] (53 pages) - MPLS Flow Identification Considerations [draft-ietf-mpls-flow-ident-07] (11 pages) - MPLS Forwarding Compliance and Performance Requirements [draft-ietf-mpls-forwarding-09] (59 pages) - Use of Label Switching on Frame Relay Networks Specification [draft-ietf-mpls-fr-06] (24 pages) - A Framework for MPLS [draft-ietf-mpls-framework-05] (69 pages) - Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) [draft-ietf-mpls-ftn-mib-09] (42 pages) - MPLS Generic Associated Channel (G-ACh) Advertisement Protocol [draft-ietf-mpls-gach-adv-08] (23 pages) - The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol [draft-ietf-mpls-git-uus-04] (25 pages) - PathErr Message Triggered MPLS and GMPLS LSP Reroutes [draft-ietf-mpls-gmpls-lsp-reroute-06] (12 pages) - MPLS/IP Header Compression [draft-ietf-mpls-hdr-comp-00] (14 pages) - MPLS/IP Header Compression over PPP [draft-ietf-mpls-hdr-comp-over-ppp-00] (10 pages) - Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object [draft-ietf-mpls-iana-rsvp-session-flags-01] (5 pages) - ICMP Extensions for Multiprotocol Label Switching [draft-ietf-mpls-icmp-08] (8 pages) - LDP IGP Synchronization [draft-ietf-mpls-igp-sync-01] (8 pages) - Encapsulation For MPLS Performance Measurement with Alternate Marking Method [draft-ietf-mpls-inband-pm-encapsulation-05] (14 pages) - Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) [draft-ietf-mpls-in-ip-or-gre-08] (14 pages) - Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios [draft-ietf-mpls-interas-lspping-00] (18 pages) - Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment [draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01] (17 pages) - Encapsulating MPLS in UDP [draft-ietf-mpls-in-udp-11] (19 pages) - Label Edge Router Forwarding of IPv4 Option Packets [draft-ietf-mpls-ip-options-07] (9 pages) - Gap Analysis for Operating IPv6-Only MPLS Networks [draft-ietf-mpls-ipv6-only-gap-04] (28 pages) - Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 [draft-ietf-mpls-ipv6-pw-lsp-ping-04] (8 pages) - MPLS Label Stack Encoding [draft-ietf-mpls-label-encaps-08] (23 pages) - Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition [draft-ietf-mpls-lc-if-mib-08] (22 pages) - LDP Specification [draft-ietf-mpls-ldp-11] (132 pages) - LDP Applicability [draft-ietf-mpls-ldp-applic-02] (7 pages) - Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) [draft-ietf-mpls-ldp-applicability-label-adv-03] (8 pages) - LDP Capabilities [draft-ietf-mpls-ldp-capabilities-04] (12 pages) - LDP Downstream-on-Demand in Seamless MPLS [draft-ietf-mpls-ldp-dod-09] (35 pages) - LDP DoD Graceful Restart [draft-ietf-mpls-ldp-dod-restart-00] (18 pages) - Signaling LDP Label Advertisement Completion [draft-ietf-mpls-ldp-end-of-lib-04] (9 pages) - Experience with the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-experience-00] (7 pages) - Fault Tolerance for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-ft-06] (52 pages) - The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-gtsm-09] (8 pages) - LDP Hello Cryptographic Authentication [draft-ietf-mpls-ldp-hello-crypto-auth-10] (14 pages) - Label Distribution Protocol (LDP) Internet Assigned Numbers Authority (IANA) Considerations Update [draft-ietf-mpls-ldp-iana-01] (5 pages) - LDP IGP Synchronization [draft-ietf-mpls-ldp-igp-sync-04] (7 pages) - LDP IGP Synchronization for Broadcast Networks [draft-ietf-mpls-ldp-igp-sync-bcast-06] (9 pages) - LDP Extension for Inter-Area Label Switched Paths (LSPs) [draft-ietf-mpls-ldp-interarea-04] (12 pages) - Controlling State Advertisements of Non-negotiated LDP Applications [draft-ietf-mpls-ldp-ip-pw-capability-09] (15 pages) - Updates to LDP for IPv6 [draft-ietf-mpls-ldp-ipv6-17] (24 pages) - Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-mib-14] (106 pages) - YANG Data Model for MPLS LDP and mLDP [draft-ietf-mpls-ldp-mldp-yang-00] (115 pages) - LDP Extensions to Support Maximally Redundant Trees [draft-ietf-mpls-ldp-mrt-07] (21 pages) - Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol [draft-ietf-mpls-ldp-mtu-extensions-03] (9 pages) - LDP Extensions for Multi-Topology [draft-ietf-mpls-ldp-multi-topology-12] (20 pages) - LDP Extensions for Optical User Network Interface (O-UNI) Signaling [draft-ietf-mpls-ldp-optical-uni-01] (26 pages) - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-ldp-p2mp-15] (39 pages) - Graceful Restart Mechanism for Label Distribution Protocol [draft-ietf-mpls-ldp-restart-06] (12 pages) - Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-restart-applic-01] (16 pages) - LDP Extensions for RMR [draft-ietf-mpls-ldp-rmr-extensions-03] (13 pages) - LDP State Machine [draft-ietf-mpls-ldp-state-04] (78 pages) - The Label Distribution Protocol (LDP) Implementation Survey Results [draft-ietf-mpls-ldp-survey2002-00] (23 pages) - Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) [draft-ietf-mpls-ldp-typed-wildcard-07] (10 pages) - MPLS Upstream Label Assignment for LDP [draft-ietf-mpls-ldp-upstream-10] (13 pages) - YANG Data Model for MPLS LDP [draft-ietf-mpls-ldp-yang-09] (79 pages) - Link Management Protocol (LMP) [draft-ietf-mpls-lmp-02] (58 pages) - MPLS Loop Prevention Mechanism [draft-ietf-mpls-loop-prevention-03] (44 pages) - Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-loss-delay-04] (52 pages) - Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) [draft-ietf-mpls-lsp-hierarchy-08] (14 pages) - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [draft-ietf-mpls-lsp-ping-13] (50 pages) - Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels [draft-ietf-mpls-lsp-ping-enhanced-dsmap-11] (23 pages) - Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces [draft-ietf-mpls-lsp-ping-lag-multipath-08] (29 pages) - Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping [draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16] (29 pages) - Deprecating the Use of Router Alert in LSP Ping [draft-ietf-mpls-lspping-norao-01] (7 pages) - OSPFv3 Code Point for MPLS LSP Ping [draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06] (6 pages) - Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry [draft-ietf-mpls-lsp-ping-registries-update-11] (31 pages) - IANA Registries for LSP Ping Code Points [draft-ietf-mpls-lsp-ping-registry-03] (7 pages) - Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping [draft-ietf-mpls-lsp-ping-relay-reply-11] (18 pages) - Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification [draft-ietf-mpls-lsp-ping-reply-mode-simple-05] (17 pages) - Definition of Time to Live TLV for LSP-Ping Mechanisms [draft-ietf-mpls-lsp-ping-ttl-tlv-10] (8 pages) - Multi Protocol Label Switching Label Distribution Protocol Query Message Description [draft-ietf-mpls-lsp-query-09] (19 pages) - Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [draft-ietf-mpls-lsr-mib-14] (60 pages) - Label Switching Router Self-Test [draft-ietf-mpls-lsr-self-test-07] (15 pages) - Connectivity Verification for Multicast Label Switched Paths [draft-ietf-mpls-mcast-cv-00] (13 pages) - Multiprotocol Label Switching (MPLS) Management Overview [draft-ietf-mpls-mgmt-overview-09] (32 pages) - Requirements for MPLS Network Action Indicators and MPLS Ancillary Data [draft-ietf-mpls-miad-mna-requirements-00] (22 pages) - LDP Extensions for Hub and Spoke Multipoint Label Switched Path [draft-ietf-mpls-mldp-hsmp-06] (15 pages) - Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-in-band-signaling-08] (12 pages) - Multipoint LDP (mLDP) In-Band Signaling with Wildcards [draft-ietf-mpls-mldp-in-band-wildcard-encoding-03] (16 pages) - Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-mib-05] (40 pages) - mLDP Extensions for Multi-Topology Routing [draft-ietf-mpls-mldp-multi-topology-02] (14 pages) - Multipoint LDP (mLDP) Node Protection [draft-ietf-mpls-mldp-node-protection-08] (19 pages) - Using Multipoint LDP When the Backbone Has No Route to the Root [draft-ietf-mpls-mldp-recurs-fec-04] (12 pages) - YANG Data Model for MPLS mLDP [draft-ietf-mpls-mldp-yang-10] (75 pages) - MPLS Network Actions Framework [draft-ietf-mpls-mna-fwk-03] (19 pages) - MPLS Network Action (MNA) Sub-Stack Solution [draft-ietf-mpls-mna-hdr-02] (24 pages) - Requirements for MPLS Network Actions [draft-ietf-mpls-mna-requirements-05] (12 pages) - Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data [draft-ietf-mpls-mna-usecases-02] (14 pages) - Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry [draft-ietf-mpls-moving-iana-registries-04] (7 pages) - Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol [draft-ietf-mpls-mp-ldp-reqs-08] (20 pages) - Security Framework for MPLS and GMPLS Networks [draft-ietf-mpls-mpls-and-gmpls-security-framework-09] (66 pages) - A YANG Model for MPLS MSD [draft-ietf-mpls-msd-yang-01] (9 pages) - Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment [draft-ietf-mpls-multicast-08] (30 pages) - MPLS Multicast Encapsulations [draft-ietf-mpls-multicast-encaps-10] (11 pages) - Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) [draft-ietf-mpls-multipath-use-04] (15 pages) - Definition of a Record Route Object (RRO) Node-Id Sub-Object [draft-ietf-mpls-nodeid-subobject-07] (10 pages) - A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link [draft-ietf-mpls-number-0-bw-te-lsps-12] (8 pages) - A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) [draft-ietf-mpls-oam-frmwk-05] (11 pages) - IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) [draft-ietf-mpls-oam-ipv6-rao-03] (6 pages) - Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks [draft-ietf-mpls-oam-requirements-07] (15 pages) - Opportunistic Security in MPLS Networks [draft-ietf-mpls-opportunistic-encrypt-03] (38 pages) - Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 [draft-ietf-mpls-over-l2tpv3-03] (12 pages) - BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP [draft-ietf-mpls-p2mp-bfd-04] (12 pages) - Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping [draft-ietf-mpls-p2mp-lsp-ping-18] (28 pages) - Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks [draft-ietf-mpls-p2mp-oam-reqs-01] (14 pages) - Requirements for Point to Multipoint Traffic Engineered MPLS LSPs [draft-ietf-mpls-p2mp-requirement-04] (34 pages) - Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-p2mp-sig-requirement-04] (30 pages) - P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels [draft-ietf-mpls-p2mp-te-bypass-02] (14 pages) - Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module [draft-ietf-mpls-p2mp-te-mib-09] (62 pages) - Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) [draft-ietf-mpls-pim-sm-over-mldp-03] (11 pages) - MPLS Performance Measurement UDP Return Path [draft-ietf-mpls-pm-udp-return-00] (8 pages) - Proxy MPLS Echo Request [draft-ietf-mpls-proxy-lsp-ping-05] (28 pages) - Updates to MPLS Transport Profile Linear Protection [draft-ietf-mpls-psc-updates-06] (11 pages) - Framework for Multi-Protocol Label Switching (MPLS)-based Recovery [draft-ietf-mpls-recovery-frmwrk-08] (40 pages) - Proxy LSP Ping [draft-ietf-mpls-remote-lsp-ping-03] (19 pages) - Residence Time Measurement in MPLS Networks [draft-ietf-mpls-residence-time-15] (30 pages) - Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel [draft-ietf-mpls-retire-ach-tlv-03] (5 pages) - Return Path Specified Label Switched Path (LSP) Ping [draft-ietf-mpls-return-path-specified-lsp-ping-15] (21 pages) - LDP Specification [draft-ietf-mpls-rfc3036bis-04] (135 pages) - Using BGP to Bind MPLS Labels to Address Prefixes [draft-ietf-mpls-rfc3107bis-04] (23 pages) - Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures [draft-ietf-mpls-rfc4379bis-09] (78 pages) - RFC6374 Synonymous Flow Labels [draft-ietf-mpls-rfc6374-sfl-10] (21 pages) - Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane [draft-ietf-mpls-rfc6374-sr-07] (21 pages) - UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-rfc6374-udp-return-path-05] (10 pages) - Clarification of Segment ID Sub-TLV Length for RFC 8287 [draft-ietf-mpls-rfc8287-len-clarification-04] (7 pages) - Refresh-interval Independent FRR Facility Protection [draft-ietf-mpls-ri-rsvp-frr-14] (27 pages) - Resilient MPLS Rings [draft-ietf-mpls-rmr-14] (20 pages) - Resilient MPLS Rings and Multicast [draft-ietf-mpls-rmr-multicast-00] (7 pages) - Use of Label Switching With RSVP [draft-ietf-mpls-rsvp-00] (13 pages) - Fast Reroute Extensions to RSVP-TE for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-fastreroute-07] (38 pages) - RSVP-TE: Extensions to RSVP for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-tunnel-09] (61 pages) - Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane [draft-ietf-mpls-rsvp-shared-labels-09] (24 pages) - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvpte-attributes-05] (21 pages) - Hub and Spoke Multipoint Label Switched Path Tunnels [draft-ietf-mpls-rsvp-te-hsmp-lsp-01] (8 pages) - Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths [draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09] (10 pages) - Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-mpls-rsvp-te-p2mp-07] (53 pages) - Applicability Statement for Extensions to RSVP for LSP-Tunnels [draft-ietf-mpls-rsvp-tunnel-applicability-02] (8 pages) - Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvp-unnum-08] (9 pages) - MPLS Upstream Label Assignment for RSVP-TE [draft-ietf-mpls-rsvp-upstream-05] (10 pages) - Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) [draft-ietf-mpls-seamless-mcast-17] (42 pages) - Seamless MPLS Architecture [draft-ietf-mpls-seamless-mpls-07] (42 pages) - Label Switched Path (LSP) Self-Ping [draft-ietf-mpls-self-ping-06] (12 pages) - An MPLS-Based Forwarding Plane for Service Function Chaining [draft-ietf-mpls-sfc-07] (32 pages) - MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) [draft-ietf-mpls-sfc-encapsulation-04] (9 pages) - A Simple Control Protocol for MPLS SFLs [draft-ietf-mpls-sfl-control-03] (14 pages) - Synonymous Flow Label Framework [draft-ietf-mpls-sfl-framework-11] (9 pages) - Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection [draft-ietf-mpls-smp-requirements-09] (16 pages) - MPLS Traffic Engineering Soft Preemption [draft-ietf-mpls-soft-preemption-18] (13 pages) - Allocating and Retiring Special-Purpose MPLS Labels [draft-ietf-mpls-special-purpose-labels-06] (11 pages) - Special-Purpose Label Terminology [draft-ietf-mpls-spl-terminology-06] (8 pages) - Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels [draft-ietf-mpls-spring-entropy-label-12] (22 pages) - PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks [draft-ietf-mpls-spring-inter-domain-oam-04] (22 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes [draft-ietf-mpls-spring-lsp-ping-13] (25 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes [draft-ietf-mpls-sr-epe-oam-08] (16 pages) - MPLS Segment Routing over IP [draft-ietf-mpls-sr-over-ip-07] (17 pages) - A YANG Data Model for MPLS Static LSPs [draft-ietf-mpls-static-yang-13] (18 pages) - RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels [draft-ietf-mpls-summary-frr-rsvpte-09] (18 pages) - Using LDP Multipoint Extensions on Targeted LDP Sessions [draft-ietf-mpls-targeted-mldp-04] (9 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-ietf-mpls-tc-mib-10] (20 pages) - Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions [draft-ietf-mpls-te-express-path-00] (10 pages) - Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol [draft-ietf-mpls-te-feed-06] (13 pages) - Traffic Engineering Link Management Information Base [draft-ietf-mpls-telink-mib-07] (54 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-te-mib-14] (68 pages) - An Analysis of Scaling Issues in MPLS-TE Core Networks [draft-ietf-mpls-te-scaling-analysis-05] (45 pages) - MPLS-TP 1toN Protection [draft-ietf-mpls-tp-1ton-protection-02] (36 pages) - Definition of ACH TLV Structure [draft-ietf-mpls-tp-ach-tlv-02] (9 pages) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ietf-mpls-tp-aps-updates-04] (9 pages) - Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile [draft-ietf-mpls-tp-bfd-cc-cv-00] (12 pages) - Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [draft-ietf-mpls-tp-cc-cv-rdi-06] (21 pages) - Indication of Client Failure in MPLS-TP [draft-ietf-mpls-tp-csf-02] (12 pages) - MPLS Transport Profile Data Plane Architecture [draft-ietf-mpls-tp-data-plane-04] (15 pages) - MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing [draft-ietf-mpls-tp-ethernet-addressing-08] (9 pages) - MPLS Fault Management Operations, Administration, and Maintenance (OAM) [draft-ietf-mpls-tp-fault-07] (17 pages) - A Framework for MPLS in Transport Networks [draft-ietf-mpls-tp-framework-12] (56 pages) - An In-Band Data Communication Network For the MPLS Transport Profile [draft-ietf-mpls-tp-gach-dcn-06] (8 pages) - MPLS Generic Associated Channel [draft-ietf-mpls-tp-gach-gal-06] (19 pages) - MPLS Transport Profile (MPLS-TP) Identifiers [draft-ietf-mpls-tp-identifiers-07] (17 pages) - MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions [draft-ietf-mpls-tp-itu-t-identifiers-08] (12 pages) - MPLS Transport Profile Lock Instruct and Loopback Functions [draft-ietf-mpls-tp-li-lb-08] (12 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection [draft-ietf-mpls-tp-linear-protection-09] (45 pages) - MPLS Transport Profile Linear Protection MIB [draft-ietf-mpls-tp-linear-protection-mib-12] (48 pages) - Packet Loss and Delay Measurement for the MPLS Transport Profile [draft-ietf-mpls-tp-loss-delay-00] (30 pages) - A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks [draft-ietf-mpls-tp-loss-delay-profile-04] (5 pages) - LSP-Ping and BFD encapsulation over ACH [draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01] (9 pages) - Use Cases and Requirements for MPLS-TP multi-failure protection [draft-ietf-mpls-tp-mfp-use-case-and-requirements-03] (9 pages) - Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview [draft-ietf-mpls-tp-mib-management-overview-08] (29 pages) - Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) [draft-ietf-mpls-tp-mip-mep-map-09] (11 pages) - Network Management Framework for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-framework-05] (18 pages) - Network Management Requirements for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-req-06] (24 pages) - An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-analysis-09] (21 pages) - Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-framework-11] (62 pages) - MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) [draft-ietf-mpls-tp-oam-id-mib-11] (36 pages) - Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks [draft-ietf-mpls-tp-oam-requirements-06] (17 pages) - MPLS On-Demand Connectivity Verification and Route Tracing [draft-ietf-mpls-tp-on-demand-cv-07] (22 pages) - A Framework for Point-to-Multipoint MPLS in Transport Networks [draft-ietf-mpls-tp-p2mp-framework-06] (12 pages) - IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process [draft-ietf-mpls-tp-process-05] (23 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators [draft-ietf-mpls-tp-psc-itu-04] (40 pages) - Requirements of an MPLS Transport Profile [draft-ietf-mpls-tp-requirements-10] (31 pages) - Applicability of MPLS Transport Profile for Ring Topologies [draft-ietf-mpls-tp-ring-protection-06] (30 pages) - A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations [draft-ietf-mpls-tp-rosetta-stone-13] (21 pages) - MPLS Transport Profile (MPLS-TP) Security Framework [draft-ietf-mpls-tp-security-framework-09] (15 pages) - MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology [draft-ietf-mpls-tp-shared-ring-protection-06] (56 pages) - MPLS Transport Profile (MPLS-TP) Survivability Framework [draft-ietf-mpls-tp-survive-fwk-06] (56 pages) - MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-tp-te-mib-11] (62 pages) - Requirements for Hitless MPLS Path Segment Monitoring [draft-ietf-mpls-tp-temporal-hitless-psm-14] (16 pages) - MPLS Transport Profile User-to-Network and Network-to-Network Interfaces [draft-ietf-mpls-tp-uni-nni-03] (6 pages) - MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design [draft-ietf-mpls-tp-use-cases-and-design-08] (16 pages) - Requirements for Traffic Engineering Over MPLS [draft-ietf-mpls-traffic-eng-01] (29 pages) - Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks [draft-ietf-mpls-ttl-04] (10 pages) - MPLS Upstream Label Assignment and Context-Specific Label Space [draft-ietf-mpls-upstream-label-07] (13 pages) - VCID Notification over ATM link for LDP [draft-ietf-mpls-vcid-atm-05] (19 pages) - LDP Specification [draft-ijln-mpls-rfc5036bis-04] (141 pages) - MPLS Network Action (MNA) Sub-Stack Solution [draft-jags-mpls-mna-hdr-05] (30 pages) - Hub and Spoke Multipoint Label Switched Path Tunnels [draft-jjb-mpls-rsvp-te-hsmp-lsp-04] (8 pages) - Entropy labels for source routed stacked tunnels [draft-kini-mpls-spring-entropy-label-03] (11 pages) - Label Distribution Using ARP [draft-kompella-mpls-larp-11] (12 pages) - Deprecating the Use of Router Alert in LSP Ping [draft-kompella-mpls-lspping-norao-02] (7 pages) - Resilient MPLS Rings [draft-kompella-mpls-rmr-02] (14 pages) - Multi-path Label Switched Paths Signaled Using RSVP-TE [draft-kompella-mpls-rsvp-ecmp-06] (19 pages) - Allocating and Retiring Special Purpose MPLS Labels [draft-kompella-mpls-special-purpose-labels-04] (9 pages) - Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane [draft-kumarkini-mpls-spring-lsp-ping-06] (17 pages) - Moving Generic Associated Channel (G-ACh) IANA registries to a new registry [draft-lcap-mpls-moving-iana-registries-02] (7 pages) - Proxy MPLS Echo Request [draft-lim-mpls-proxy-lsp-ping-03] (24 pages) - Entropy Values [draft-li-mpls-entropy-01] (41 pages) - Management Information Base for MPLS LDP Multi Topology [draft-li-mpls-ldp-mt-mib-06] (29 pages) - MPLS Network Actions for No Further Fast Reroute [draft-li-mpls-mna-nffrr-01] (5 pages) - MPLS Capability set [draft-loa-mpls-cap-set-01] (7 pages) - MPLS Encapsulation for SFC NSH [draft-malis-mpls-sfc-encapsulation-03] (7 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-manral-mpls-rfc3811bis-04] (24 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path [draft-mirsky-mpls-bfd-directed-04] (10 pages) - BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP [draft-mirsky-mpls-p2mp-bfd-15] (11 pages) - Residence Time Measurement in MPLS network [draft-mirsky-mpls-residence-time-07] (23 pages) - RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels [draft-mtaillon-mpls-summary-frr-rsvpte-05] (16 pages) - YANG Data Model for MPLS LSP Ping [draft-nainar-mpls-lsp-ping-yang-04] (38 pages) - RFC8287 Sub-TLV Length Clarification [draft-nainar-mpls-rfc8287-len-clarification-00] (6 pages) - PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks [draft-ninan-mpls-spring-inter-domain-oam-04] (22 pages) - Extended Administrative Groups in MPLS-TE [draft-osborne-mpls-extended-admin-groups-03] (6 pages) - Updates to PSC [draft-osborne-mpls-psc-updates-03] (8 pages) - "MPLS LSP Ping TLVs and sub-TLVs registry" [draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02] (17 pages) - Targeted LDP Hello Reduction [draft-pdutta-mpls-tldp-hello-reduce-04] (8 pages) - A YANG Model for MPLS MSD [draft-qu-mpls-mpls-msd-yang-07] (9 pages) - Entropy label for seamless MPLS [draft-ravisingh-mpls-el-for-seamless-mpls-04] (24 pages) - LDP IP and PW Capability [draft-raza-mpls-ldp-ip-pw-capability-01] (11 pages) - YANG Data Model for MPLS LDP and mLDP [draft-raza-mpls-ldp-mldp-yang-04] (114 pages) - IPv6 Router Alert Option for MPLS OAM [draft-raza-mpls-oam-ipv6-rao-02] (5 pages) - Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs [draft-rekhter-mpls-pim-sm-over-mldp-08] (12 pages) - Priority Modification for the PSC Linear Protection [draft-rhd-mpls-tp-psc-priority-01] (11 pages) - Supporting Signal Degrade in PSC Linear Protection [draft-rhd-mpls-tp-psc-sd-01] (27 pages) - Using BGP to Bind MPLS Labels to Address Prefixes [draft-rosen-mpls-rfc3107bis-01] (22 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's Requirements [draft-ryoogray-mpls-tp-psc-itu-01] (31 pages) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ryoo-mpls-tp-aps-updates-03] (7 pages) - A YANG Data Model for MPLS Base [draft-saad-mpls-base-yang-00] (10 pages) - Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data [draft-saad-mpls-miad-usecases-02] (12 pages) - A YANG Data Model for MPLS Static LSPs [draft-saad-mpls-static-yang-03] (13 pages) - Deprecation of BGP Entropy Label Capability Attribute [draft-scudder-mpls-deprecate-bgp-entropy-label-00] (3 pages) - MPLS Egress Protection Framework [draft-shen-mpls-egress-protection-framework-07] (27 pages) - Signaling RSVP-TE tunnels on a shared MPLS forwarding plane [draft-sitaraman-mpls-rsvp-shared-labels-03] (21 pages) - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [draft-smack-mpls-rfc4379bis-09] (52 pages) - MPLS Network Actions using Post-Stack Extension Headers [draft-song-mpls-extension-header-12] (14 pages) - The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) [draft-sprecher-mpls-tp-oam-considerations-03] (33 pages) - Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-tiruveedhula-mpls-mldp-mib-05] (37 pages) - Reoptimization of Point-to-Multipoint Traffic Engineering Loosely Routed LSPs [draft-tsaad-mpls-p2mp-loose-path-reopt-03] (11 pages) - Handling the TC and TTL fields in a Label Stack Entry that Contains the Generic Associated Channel Label [draft-vainshtein-mpls-gal-tc-ttl-handling-03] (7 pages) - MPLS Forwarding Compliance and Performance Requirements [draft-villamizar-mpls-forwarding-02] (50 pages) - Use of Multipath with MPLS-TP and MPLS [draft-villamizar-mpls-multipath-use-02] (13 pages) - MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) [draft-vkst-mpls-tp-te-mib-02] (39 pages) - Requirements for MPLS Shared Mesh Protection [draft-weingarten-mpls-smp-requirements-03] (13 pages) - mLDP In-Band Signaling with Wildcards [draft-wijnands-mpls-mldp-in-band-wildcard-encoding-03] (16 pages) - mLDP Extensions for Multi-Topology Routing [draft-wijnands-mpls-mldp-multi-topology-04] (14 pages) - mLDP Node Protection [draft-wijnands-mpls-mldp-node-protection-04] (16 pages) - SR-MPLS over IP [draft-xu-mpls-sr-over-ip-01] (16 pages) - Unified Source Routing Instructions using MPLS Label Stack [draft-xu-mpls-unified-source-routing-instruction-04] (14 pages) - P2MP Based mLDP Node Protection Mechanisms for mLDP LSP [draft-zhao-mpls-mldp-protections-05] (19 pages) - YANG Data Model for LSP-Ping [draft-zheng-mpls-lsp-ping-yang-cfg-10] (29 pages) - Resilient MPLS Rings and Multicast [draft-zzhang-mpls-rmr-multicast-03] (7 pages) Requests for Comments: BCP128: Avoiding Equal Cost Multipath Treatment in MPLS Networks (8 pages) RFC2702: Requirements for Traffic Engineering Over MPLS (29 pages) RFC3031: Multiprotocol Label Switching Architecture (61 pages) * Updates RFC6178 * Updates RFC6790 RFC3032: MPLS Label Stack Encoding (23 pages) * Updates RFC3443 * Updates RFC4182 * Updates RFC5332 * Updates RFC3270 * Updates RFC5129 * Updates RFC5462 * Updates RFC5586 * Updates RFC7274 * Updates RFC9017 RFC3033: The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol (25 pages) RFC3034: Use of Label Switching on Frame Relay Networks Specification (24 pages) RFC3035: MPLS using LDP and ATM VC Switching (20 pages) RFC3036: LDP Specification (132 pages) * Obsoletes RFC5036 RFC3037: LDP Applicability (7 pages) RFC3038: VCID Notification over ATM link for LDP (19 pages) * Updates RFC7274 RFC3063: MPLS Loop Prevention Mechanism (44 pages) RFC3107: Carrying Label Information in BGP-4 (8 pages) * Updates RFC6790 * Obsoletes RFC8277 RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels (61 pages) * Updates RFC3936 * Updates RFC4420 * Updates RFC4874 * Updates RFC5151 * Updates RFC5420 * Updates RFC5711 * Updates RFC6780 * Updates RFC6790 * Updates RFC7274 RFC3210: Applicability Statement for Extensions to RSVP for LSP-Tunnels (8 pages) RFC3212: Constraint-Based LSP Setup using LDP (42 pages) * Updates RFC3468 * Updates RFC7358 RFC3213: Applicability Statement for CR-LDP (7 pages) RFC3214: LSP Modification Using CR-LDP (11 pages) RFC3215: LDP State Machine (78 pages) RFC3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services (64 pages) * Updates RFC5462 RFC3353: Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment (30 pages) RFC3443: Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks (10 pages) * Updates RFC5462 RFC3468: The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols (11 pages) RFC3469: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery (40 pages) * Updates RFC5462 RFC3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) (9 pages) * Updates RFC6107 RFC3478: Graceful Restart Mechanism for Label Distribution Protocol (12 pages) RFC3479: Fault Tolerance for the Label Distribution Protocol (LDP) (52 pages) RFC3480: Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) (8 pages) RFC3612: Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) (16 pages) RFC3811: Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management (20 pages) * Updates RFC7274 RFC3812: Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) (68 pages) RFC3813: Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) (60 pages) RFC3814: Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) (42 pages) RFC3815: Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) (106 pages) RFC3988: Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol (9 pages) RFC4023: Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (14 pages) * Updates RFC5332 RFC4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels (38 pages) * Updates RFC8271 * Updates RFC8537 * Updates RFC8796 RFC4182: Removing a Restriction on the use of MPLS Explicit NULL (7 pages) * Updates RFC5462 * Updates RFC7274 RFC4201: Link Bundling in MPLS Traffic Engineering (TE) (12 pages) RFC4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) (14 pages) * Updates RFC6001 * Updates RFC6107 RFC4220: Traffic Engineering Link Management Information Base (54 pages) RFC4221: Multiprotocol Label Switching (MPLS) Management Overview (32 pages) RFC4368: Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition (22 pages) RFC4377: Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks (15 pages) RFC4378: A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) (11 pages) RFC4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures (50 pages) * Updates RFC5462 * Updates RFC6424 * Updates RFC6425 * Updates RFC6426 * Updates RFC6829 * Updates RFC7506 * Updates RFC7537 * Updates RFC7743 * Obsoletes RFC8029 RFC4420: Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (21 pages) * Obsoletes RFC5420 RFC4461: Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) (30 pages) RFC4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object (10 pages) RFC4687: Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks (14 pages) RFC4781: Graceful Restart Mechanism for BGP with MPLS (10 pages) RFC4817: Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 (12 pages) RFC4859: Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object (5 pages) RFC4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) (53 pages) * Updates RFC6510 RFC4928: Avoiding Equal Cost Multipath Treatment in MPLS Networks (8 pages) * Updates RFC7274 RFC4950: ICMP Extensions for Multiprotocol Label Switching (8 pages) RFC5036: LDP Specification (135 pages) * Updates RFC6720 * Updates RFC6790 * Updates RFC7358 * Updates RFC7552 RFC5037: Experience with the Label Distribution Protocol (LDP) (7 pages) RFC5038: The Label Distribution Protocol (LDP) Implementation Survey Results (23 pages) RFC5283: LDP Extension for Inter-Area Label Switched Paths (LSPs) (12 pages) RFC5330: A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link (8 pages) RFC5331: MPLS Upstream Label Assignment and Context-Specific Label Space (13 pages) * Updates RFC7274 RFC5332: MPLS Multicast Encapsulations (11 pages) RFC5439: An Analysis of Scaling Issues in MPLS-TE Core Networks (45 pages) RFC5443: LDP IGP Synchronization (7 pages) * Updates RFC6138 RFC5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field (9 pages) RFC5561: LDP Capabilities (12 pages) RFC5586: MPLS Generic Associated Channel (19 pages) * Updates RFC6423 * Updates RFC7026 * Updates RFC7214 * Updates RFC7274 RFC5654: Requirements of an MPLS Transport Profile (31 pages) RFC5710: PathErr Message Triggered MPLS and GMPLS LSP Reroutes (12 pages) RFC5711: Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages (7 pages) RFC5712: MPLS Traffic Engineering Soft Preemption (13 pages) RFC5718: An In-Band Data Communication Network For the MPLS Transport Profile (8 pages) RFC5860: Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks (17 pages) RFC5918: Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) (10 pages) * Updates RFC7358 RFC5919: Signaling LDP Label Advertisement Completion (9 pages) RFC5920: Security Framework for MPLS and GMPLS Networks (66 pages) RFC5921: A Framework for MPLS in Transport Networks (56 pages) * Updates RFC6215 * Updates RFC7274 RFC5950: Network Management Framework for MPLS-based Transport Networks (18 pages) RFC5951: Network Management Requirements for MPLS-based Transport Networks (24 pages) RFC5960: MPLS Transport Profile Data Plane Architecture (15 pages) * Updates RFC7274 RFC6138: LDP IGP Synchronization for Broadcast Networks (9 pages) RFC6178: Label Edge Router Forwarding of IPv4 Option Packets (9 pages) RFC6215: MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (6 pages) RFC6348: Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol (20 pages) RFC6370: MPLS Transport Profile (MPLS-TP) Identifiers (17 pages) RFC6371: Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks (62 pages) * Updates RFC6435 RFC6372: MPLS Transport Profile (MPLS-TP) Survivability Framework (56 pages) RFC6374: Packet Loss and Delay Measurement for MPLS Networks (52 pages) * Updates RFC7214 RFC6375: A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks (5 pages) RFC6378: MPLS Transport Profile (MPLS-TP) Linear Protection (45 pages) * Updates RFC7214 * Updates RFC7271 * Updates RFC7324 RFC6388: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (39 pages) * Updates RFC7358 RFC6389: MPLS Upstream Label Assignment for LDP (13 pages) RFC6424: Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels (23 pages) * Updates RFC7537 * Obsoletes RFC8029 RFC6425: Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping (28 pages) RFC6426: MPLS On-Demand Connectivity Verification and Route Tracing (22 pages) RFC6427: MPLS Fault Management Operations, Administration, and Maintenance (OAM) (17 pages) * Updates RFC7214 RFC6428: Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile (21 pages) * Updates RFC7214 RFC6435: MPLS Transport Profile Lock Instruct and Loopback Functions (12 pages) RFC6445: Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute (53 pages) RFC6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths (10 pages) RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root (12 pages) RFC6639: Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview (29 pages) RFC6669: An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks (21 pages) RFC6670: The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) (33 pages) RFC6720: The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) (8 pages) * Updates RFC7552 RFC6790: The Use of Entropy Labels in MPLS Forwarding (25 pages) * Updates RFC7274 * Updates RFC7447 * Updates RFC8012 RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (12 pages) * Updates RFC7438 RFC6829: Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 (8 pages) * Obsoletes RFC8029 RFC6923: MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions (12 pages) RFC6941: MPLS Transport Profile (MPLS-TP) Security Framework (15 pages) RFC6965: MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design (16 pages) RFC6974: Applicability of MPLS Transport Profile for Ring Topologies (30 pages) RFC7026: Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel (5 pages) RFC7032: LDP Downstream-on-Demand in Seamless MPLS (35 pages) RFC7054: Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) (11 pages) RFC7060: Using LDP Multipoint Extensions on Targeted LDP Sessions (9 pages) RFC7087: A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations (21 pages) RFC7110: Return Path Specified Label Switched Path (LSP) Ping (21 pages) * Updates RFC7737 RFC7140: LDP Extensions for Hub and Spoke Multipoint Label Switched Path (15 pages) * Updates RFC7358 RFC7167: A Framework for Point-to-Multipoint MPLS in Transport Networks (12 pages) RFC7190: Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) (15 pages) RFC7212: MPLS Generic Associated Channel (G-ACh) Advertisement Protocol (23 pages) RFC7213: MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing (9 pages) RFC7214: Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry (7 pages) RFC7271: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators (40 pages) * Updates RFC8234 RFC7274: Allocating and Retiring Special-Purpose MPLS Labels (11 pages) * Updates RFC9017 RFC7307: LDP Extensions for Multi-Topology (20 pages) RFC7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) (7 pages) RFC7324: Updates to MPLS Transport Profile Linear Protection (11 pages) RFC7325: MPLS Forwarding Compliance and Performance Requirements (59 pages) RFC7349: LDP Hello Cryptographic Authentication (14 pages) RFC7358: Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) (8 pages) RFC7394: Definition of Time to Live TLV for LSP-Ping Mechanisms (8 pages) RFC7412: Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection (16 pages) RFC7438: Multipoint LDP (mLDP) In-Band Signaling with Wildcards (16 pages) RFC7439: Gap Analysis for Operating IPv6-Only MPLS Networks (28 pages) RFC7442: Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) (11 pages) RFC7447: Deprecation of BGP Entropy Label Capability Attribute (4 pages) RFC7453: MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) (62 pages) RFC7473: Controlling State Advertisements of Non-negotiated LDP Applications (15 pages) * Updates RFC8223 RFC7506: IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) (6 pages) RFC7510: Encapsulating MPLS in UDP (19 pages) RFC7524: Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) (42 pages) * Updates RFC8534 RFC7537: IANA Registries for LSP Ping Code Points (7 pages) * Obsoletes RFC8029 RFC7552: Updates to LDP for IPv6 (24 pages) RFC7555: Proxy MPLS Echo Request (28 pages) RFC7697: MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) (36 pages) RFC7715: Multipoint LDP (mLDP) Node Protection (19 pages) RFC7737: Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification (17 pages) RFC7743: Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping (18 pages) RFC7746: Label Switched Path (LSP) Self-Ping (12 pages) RFC7759: Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping (29 pages) RFC7876: UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks (10 pages) RFC8012: Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) (23 pages) RFC8029: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures (78 pages) * Updates RFC8611 * Updates RFC9041 RFC8150: MPLS Transport Profile Linear Protection MIB (48 pages) RFC8169: Residence Time Measurement in MPLS Networks (30 pages) RFC8223: Application-Aware Targeted LDP (18 pages) RFC8227: MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology (56 pages) RFC8234: Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode (9 pages) RFC8256: Requirements for Hitless MPLS Path Segment Monitoring (16 pages) RFC8277: Using BGP to Bind MPLS Labels to Address Prefixes (23 pages) RFC8287: Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes (25 pages) * Updates RFC8690 * Updates RFC9214 RFC8320: LDP Extensions to Support Maximally Redundant Trees (21 pages) RFC8372: MPLS Flow Identification Considerations (11 pages) RFC8577: Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane (24 pages) RFC8595: An MPLS-Based Forwarding Plane for Service Function Chaining (32 pages) RFC8596: MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) (9 pages) RFC8611: Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces (29 pages) * Updates RFC9041 RFC8662: Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels (22 pages) RFC8663: MPLS Segment Routing over IP (17 pages) RFC8679: MPLS Egress Protection Framework (25 pages) RFC8690: Clarification of Segment ID Sub-TLV Length for RFC 8287 (7 pages) RFC8796: RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels (18 pages) RFC8957: Synonymous Flow Label Framework (9 pages) RFC8960: A YANG Data Model for MPLS Base (29 pages) RFC9017: Special-Purpose Label Terminology (8 pages) RFC9041: Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry (31 pages) RFC9070: YANG Data Model for MPLS LDP (79 pages) RFC9214: OSPFv3 Code Point for MPLS LSP Ping (6 pages) Network Virtualization Overlays (nvo3) -------------------------------------- Charter Last Modified: 2023-02-17 Current Status: Active Chairs: Matthew Bocci Sam Aldrin Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Tech Advisor: Ron Bonica Secretary: Yizhou Li Mailing Lists: General Discussion: nvo3@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3 Archive: https://mailarchive.ietf.org/arch/browse/nvo3/ Description of Working Group: The purpose of the NVO3 WG is to develop a set of protocols and/or protocol extensions that enable network virtualization within a data center (DC) environment that assumes an IP-based underlay. An NVO3 solution provides layer 2 and/or layer 3 services for virtual networks enabling multi-tenancy and workload mobility, addressing the issues described in the problem statement (including management and security), and consistent with the framework previously produced by the NVO3 WG. The NVO3 WG will develop solutions for network virtualization based on the following architectural tenets: - Support for an IP-based underlay data plane - A logically centralized authority for network virtualization Network virtualization approaches that do not adhere to these tenets are explicitly outside of the scope of the NVO3 WG. In pursuit of the solutions described above, the NVO3 WG will document an architecture for network virtualization within a data center environment. The NVO3 WG may produce requirements for a network virtualization control plane, and will select, extend, and/or develop one protocol for each of the functional interfaces identified to support the architecture. Such protocols are expected to fulfill the communication requirements between an End Device and a Network Virtualization Edge (NVE) in cases where the NVE is not co-resident with the End Device, and between an NVE and the Network Virtualization Authority (NVA). The internal mechanisms and protocols of a logically centralized NVA are explicitly out of scope of the NVO3 WG. Architectural issues raised by coexistence of multiple logically centralized control planes in the same data center may be considered by the WG. Inter-DC mechanisms are not in scope of the NVO3 WG at this time. The NVO3 WG may produce requirements for network virtualization data planes based on encapsulation of virtual network traffic over an IP- based underlay data plane. Such requirements should consider OAM and security. Based on these requirements the WG will select, extend, and/or develop one or more data plane encapsulation format(s). Additionally, the WG may document common use-cases for NVO3 solutions. The working group may choose to adopt a protocol or data encapsulation that was previously worked on outside the IETF as the basis for the WG's work. If the NVO3 WG anticipates the adoption of the technologies of another SDO as part of the selected protocols or data encapsulation, the NVO3 WG will first liaise with that SDO to ensure the compatibility of the approach. The NVO3 WG will not consider solutions to network virtualization within a data center environment based on extensions to BGP or LISP protocols. Goals and Milestones: Dec 2019 - Data Plane Requirements submitted for IESG review Mar 2020 - Security Requirements Submitted to IESG Mar 2020 - Security Solutions Submitted to IESG Aug 2020 - Recharter or close working group Aug 2020 - OAM Solution submitted for IESG Review Done - Problem Statement submitted for IESG review Done - Framework document submitted for IESG review Done - Use Cases submitted for IESG review Done - Architecture submitted for IESG review Done - End Device - NVE Control Plane Solution submitted for IESG review Done - Data Plane Solution submitted for IESG review Internet-Drafts: - A Framework for Multicast in NVO3 [draft-ghanwani-nvo3-mcast-framework-00] (15 pages) - Geneve: Generic Network Virtualization Encapsulation [draft-gross-geneve-02] (24 pages) - Generic UDP Encapsulation [draft-herbert-gue-03] (24 pages) - An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) [draft-ietf-nvo3-arch-08] (35 pages) - BFD for Geneve [draft-ietf-nvo3-bfd-geneve-09] (12 pages) - NVO3 Data Plane Requirements [draft-ietf-nvo3-dataplane-requirements-03] (18 pages) - Network Virtualization Overlays (NVO3) Encapsulation Considerations [draft-ietf-nvo3-encap-09] (28 pages) - Applicability of EVPN to NVO3 Networks [draft-ietf-nvo3-evpn-applicability-06] (30 pages) - Framework for Data Center (DC) Network Virtualization [draft-ietf-nvo3-framework-09] (26 pages) - NVO3 Gap Analysis - Requirements Versus Available Technology Choices [draft-ietf-nvo3-gap-analysis-01] (21 pages) - Geneve: Generic Network Virtualization Encapsulation [draft-ietf-nvo3-geneve-16] (34 pages) - OAM for use in GENEVE [draft-ietf-nvo3-geneve-oam-06] (11 pages) - Generic UDP Encapsulation [draft-ietf-nvo3-gue-05] (37 pages) - Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements [draft-ietf-nvo3-hpvr2nve-cp-req-17] (26 pages) - A Framework for Multicast in Network Virtualization over Layer 3 [draft-ietf-nvo3-mcast-framework-11] (17 pages) - Network Virtualization NVE to NVA Control Protocol Requirements [draft-ietf-nvo3-nve-nva-cp-req-05] (12 pages) - Problem Statement: Overlays for Network Virtualization [draft-ietf-nvo3-overlay-problem-statement-04] (23 pages) - Security Requirements of NVO3 [draft-ietf-nvo3-security-requirements-07] (19 pages) - Use Cases for Data Center Network Virtualization Overlay Networks [draft-ietf-nvo3-use-case-17] (16 pages) - Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks [draft-ietf-nvo3-vmm-16] (17 pages) - Network-related VM Mobility Issues [draft-ietf-nvo3-vm-mobility-issues-03] (11 pages) - Generic Protocol Extension for VXLAN (VXLAN-GPE) [draft-ietf-nvo3-vxlan-gpe-12] (22 pages) - Base YANG Data Model for NVO3 Protocols [draft-ietf-nvo3-yang-cfg-05] (26 pages) - Framework for DC Network Virtualization [draft-lasserre-nvo3-framework-03] (22 pages) - Use Cases for DC Network Virtualization Overlays [draft-mity-nvo3-use-case-04] (17 pages) - Generic Protocol Extension for VXLAN [draft-quinn-vxlan-gpe-04] (22 pages) Requests for Comments: RFC7364: Problem Statement: Overlays for Network Virtualization (23 pages) RFC7365: Framework for Data Center (DC) Network Virtualization (26 pages) RFC8014: An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) (35 pages) RFC8151: Use Cases for Data Center Network Virtualization Overlay Networks (16 pages) RFC8293: A Framework for Multicast in Network Virtualization over Layer 3 (17 pages) RFC8394: Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements (26 pages) RFC8926: Geneve: Generic Network Virtualization Encapsulation (34 pages) Path Computation Element (pce) ------------------------------ Charter Last Modified: 2023-04-24 Current Status: Active Chairs: Dhruv Dhody Julien Meuric Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Secretary: Hariharan Ananthakrishnan Mailing Lists: General Discussion: pce@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pce Archive: https://mailarchive.ietf.org/arch/browse/pce/ Description of Working Group: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may not be physically located on each head-end LSR. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. The PCE WG works on the application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between Path Computation Clients (PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g., RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS protocols specified in the CCAMP and TEAS WGs. Work Items: - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP path computation models involving PCEs. This includes the case of computing the paths of intra- and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. - Definition of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where receiving PCC/PCE chooses to not follow the recommendation. Goals and Milestones: Feb 2015 - Evaluate WG progress, recharter or close Done - Submit first draft of PCE discovery requirements and protocol extensions documents Done - Submit first draft of PCE architecture document Done - Submit first draft of the PCE communication protocol requirements Done - Submit first draft of the definition of objective metrics Done - Submit first draft of the PCE communication protocol specification Done - Submit PCE architecture specification to the IESG to be considered as Informational RFC Done - Submit first draft of the MIB module for the PCE protocol Done - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done - Submit first draft of the PCE P2MP communication requirements Done - Submit first draft of the PCE P2MP PCEP protocol extensions Done - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done - Submit applicability and metrics documents to the IESG Done - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Done - Submit inter-area/AS applicability statement to the IESG as an informational RFC Done - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Done - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Done - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Done - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Done - Submit the stateful PCE document(s) to the IESG Internet-Drafts: - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ali-pce-remote-initiated-gmpls-lsp-03] (9 pages) - PCEP extension to support Segment Routing Policy Candidate Paths [draft-barth-pce-segment-routing-policy-cp-06] (20 pages) - Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT [draft-chen-pce-pcep-ifit-06] (23 pages) - Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP) [draft-dhody-pce-pcep-exp-codepoints-03] (6 pages) - PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. [draft-dhody-pce-pcep-extension-pce-controller-srv6-10] (19 pages) - Updates for PCEPS [draft-dhody-pce-pceps-tls13-02] (6 pages) - PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE [draft-dhody-pce-stateful-pce-auto-bandwidth-09] (25 pages) - Extension for Stateful PCE to allow Optional Processing of PCEP Objects [draft-dhody-pce-stateful-pce-optional-08] (11 pages) - PCEP Extension for Stateful Inter-Domain Tunnels [draft-dugeon-pce-stateful-interdomain-04] (34 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol [draft-farrel-pce-rfc7150bis-01] (12 pages) - Updated Rules for Processing Stateful PCE Request Parameters Flags [draft-farrel-pce-stateful-flags-03] (6 pages) - Unanswered Questions in the Path Computation Element Architecture [draft-farrkingel-pce-questions-03] (25 pages) - PCEP extensions for p2mp sr policy [draft-hsd-pce-sr-p2mp-policy-03] (36 pages) - Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) [draft-ietf-pce-applicability-actn-12] (22 pages) - A Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-architecture-05] (40 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-pce-association-bidir-14] (20 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling [draft-ietf-pce-association-diversity-15] (21 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) [draft-ietf-pce-association-group-10] (28 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) [draft-ietf-pce-association-policy-16] (15 pages) - Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. [draft-ietf-pce-binding-label-sid-16] (25 pages) - A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-brpc-09] (18 pages) - Path Computation Element (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (21 pages) - Definitions of Managed Objects for Path Computation Element Discovery [draft-ietf-pce-disc-mib-04] (24 pages) - IGP protocol extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-igp-02] (37 pages) - IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-isis-08] (17 pages) - OSPF Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-ospf-08] (20 pages) - Requirements for Path Computation Element (PCE) Discovery [draft-ietf-pce-discovery-reqs-05] (19 pages) - Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol [draft-ietf-pce-dste-02] (9 pages) - Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications [draft-ietf-pce-enhanced-errors-13] (23 pages) - PCEP Extension for Flexible Grid Networks [draft-ietf-pce-flexible-grid-09] (19 pages) - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization [draft-ietf-pce-global-concurrent-optimization-10] (26 pages) - Requirements for GMPLS Applications of PCE [draft-ietf-pce-gmpls-aps-req-09] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS [draft-ietf-pce-gmpls-pcep-extensions-16] (38 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture [draft-ietf-pce-hierarchy-extensions-11] (27 pages) - The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS [draft-ietf-pce-hierarchy-fwk-05] (33 pages) - Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-area-as-applicability-08] (24 pages) - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) [draft-ietf-pce-interas-pcecp-reqs-06] (14 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-ext-12] (22 pages) - Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-frwk-10] (34 pages) - PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering [draft-ietf-pce-inter-layer-req-15] (12 pages) - Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-iro-update-07] (5 pages) - Local Protection Enforcement in PCEP [draft-ietf-pce-local-protection-enforcement-10] (12 pages) - Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) [draft-ietf-pce-lsp-control-request-11] (11 pages) - Label Switched Path (LSP) Object Flag Extension for Stateful PCE [draft-ietf-pce-lsp-extended-flags-09] (9 pages) - Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages [draft-ietf-pce-lsp-setup-type-10] (12 pages) - Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts [draft-ietf-pce-manageability-requirements-11] (13 pages) - A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-monitoring-09] (26 pages) - PCEP Extensions for Signaling Multipath Information [draft-ietf-pce-multipath-08] (24 pages) - Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-of-06] (23 pages) - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) [draft-ietf-pce-p2mp-app-02] (15 pages) - Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE [draft-ietf-pce-p2mp-req-05] (11 pages) - Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism [draft-ietf-pce-path-key-06] (19 pages) - Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering [draft-ietf-pce-pcecp-interarea-reqs-05] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model [draft-ietf-pce-pce-initiated-lsp-11] (20 pages) - Path Computation Element (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-19] (87 pages) - Path Computation Element Protocol(PCEP) Extension for Color [draft-ietf-pce-pcep-color-00] (8 pages) - Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pcep-domain-sequence-12] (35 pages) - Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pcep-exp-codepoints-05] (7 pages) - Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs [draft-ietf-pce-pcep-extension-for-pce-controller-14] (33 pages) - PCEP Extension for Native IP Network [draft-ietf-pce-pcep-extension-native-ip-21] (29 pages) - PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. [draft-ietf-pce-pcep-extension-pce-controller-sr-06] (34 pages) - PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. [draft-ietf-pce-pcep-extension-pce-controller-srv6-00] (19 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification [draft-ietf-pce-pcep-flowspec-13] (29 pages) - Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT [draft-ietf-pce-pcep-ifit-02] (23 pages) - PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08] (25 pages) - PCEP Extension for L2 Flow Specification [draft-ietf-pce-pcep-l2-flowspec-03] (14 pages) - Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module [draft-ietf-pce-pcep-mib-11] (65 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-p2mp-extensions-11] (33 pages) - Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-pmtu-03] (11 pages) - PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-pceps-18] (26 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) [draft-ietf-pce-pcep-service-aware-13] (31 pages) - A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) [draft-ietf-pce-pcep-srv6-yang-02] (24 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-controlled Networks [draft-ietf-pce-pcep-stateful-pce-gmpls-21] (27 pages) - Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations [draft-ietf-pce-pcep-svec-list-05] (18 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions [draft-ietf-pce-pcep-xro-06] (16 pages) - A YANG Data Model for Path Computation Element Communications Protocol (PCEP) [draft-ietf-pce-pcep-yang-21] (132 pages) - Policy-Enabled Path Computation Framework [draft-ietf-pce-policy-enabled-path-comp-04] (36 pages) - Unanswered Questions in the Path Computation Element Architecture [draft-ietf-pce-questions-08] (29 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ietf-pce-remote-initiated-gmpls-lsp-06] (10 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-rfc6006bis-04] (43 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol [draft-ietf-pce-rfc7150bis-01] (14 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing [draft-ietf-pce-segment-routing-16] (29 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane [draft-ietf-pce-segment-routing-ipv6-16] (27 pages) - PCEP extension to support Segment Routing Policy Candidate Paths [draft-ietf-pce-segment-routing-policy-cp-10] (21 pages) - Carrying SR Algorithm information in PCE-based Networks. [draft-ietf-pce-sid-algo-01] (13 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-ietf-pce-sr-bidir-path-11] (20 pages) - PCEP extensions for p2mp sr policy [draft-ietf-pce-sr-p2mp-policy-03] (44 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-ietf-pce-sr-path-segment-07] (26 pages) - Updated Rules for Processing Stateful PCE Request Parameters Flags [draft-ietf-pce-stateful-flags-01] (6 pages) - Hierarchical Stateful Path Computation Element (PCE) [draft-ietf-pce-stateful-hpce-15] (21 pages) - PCEP Extension for Stateful Inter-Domain Tunnels [draft-ietf-pce-stateful-interdomain-03] (37 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE [draft-ietf-pce-stateful-path-protection-11] (15 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE [draft-ietf-pce-stateful-pce-21] (57 pages) - Applicability of a Stateful Path Computation Element (PCE) [draft-ietf-pce-stateful-pce-app-08] (24 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE [draft-ietf-pce-stateful-pce-auto-bandwidth-12] (32 pages) - Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup [draft-ietf-pce-stateful-pce-inter-domain-lsp-00] (12 pages) - PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE [draft-ietf-pce-stateful-pce-lsp-scheduling-27] (23 pages) - Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects [draft-ietf-pce-stateful-pce-optional-05] (12 pages) - Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-pce-stateful-pce-p2mp-13] (33 pages) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-ietf-pce-stateful-sync-optimizations-10] (26 pages) - Inter Stateful Path Computation Element (PCE) Communication Procedures. [draft-ietf-pce-state-sync-04] (35 pages) - Definitions of Textual Conventions for Path Computation Element [draft-ietf-pce-tc-mib-05] (6 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol [draft-ietf-pce-vendor-constraints-11] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks [draft-ietf-pce-vn-association-11] (12 pages) - PCC-PCE Communication Requirements for VPNs [draft-ietf-pce-vpn-req-02] (16 pages) - Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment [draft-ietf-pce-wson-routing-wavelength-15] (12 pages) - The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) [draft-ietf-pce-wson-rwa-ext-17] (26 pages) - PCEP Extensions for Signaling Multipath Information [draft-koldychev-pce-multipath-05] (19 pages) - Extensions to the Path Computation Element Protocol (PCEP) for residual path bandwidth support [draft-lazzeri-pce-residual-bw-01] (16 pages) - Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks [draft-leedhody-pce-vn-association-08] (14 pages) - PCEP Extension for Flexible Grid Networks [draft-lee-pce-flexible-grid-03] (20 pages) - PCEP Extension for L2 Flow Specification [draft-li-pce-pcep-l2-flowspec-00] (13 pages) - Support for Path MTU (PMTU) in the Path Computation Element (PCE) communication Protocol (PCEP). [draft-li-pce-pcep-pmtu-05] (11 pages) - PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-li-pce-sr-bidir-path-07] (16 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-li-pce-sr-path-segment-08] (26 pages) - Inter Stateful Path Computation Element (PCE) Communication Procedures. [draft-litkowski-pce-state-sync-10] (32 pages) - Secure Transport for PCEP [draft-lopez-pce-pceps-02] (12 pages) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-minei-pce-stateful-sync-optimizations-02] (19 pages) - PCEP Extensions for Segment Routing leveraging the IPv6 data plane [draft-negi-pce-segment-routing-ipv6-04] (20 pages) - Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-palle-pce-stateful-pce-p2mp-09] (32 pages) - Path Computation Element Protocol(PCEP) Extension for Color [draft-rajagopalan-pce-pcep-color-03] (8 pages) - Carrying Binding Label/Segment-ID in PCE-based Networks. [draft-sivabalan-pce-binding-label-sid-07] (16 pages) - Local Protection Enforcement in PCEP [draft-stone-pce-local-protection-enforcement-02] (11 pages) - Carrying SID Algorithm information in PCE-based Networks. [draft-tokar-pce-sid-algo-05] (12 pages) - LSP Object Flag Extension of Stateful PCE [draft-xiong-pce-lsp-flag-03] (6 pages) - PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. [draft-zhao-pce-pcep-extension-pce-controller-sr-09] (32 pages) Requests for Comments: RFC4655: A Path Computation Element (PCE)-Based Architecture (40 pages) RFC4657: Path Computation Element (PCE) Communication Protocol Generic Requirements (21 pages) RFC4674: Requirements for Path Computation Element (PCE) Discovery (19 pages) RFC4927: Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering (12 pages) RFC5088: OSPF Protocol Extensions for Path Computation Element (PCE) Discovery (20 pages) * Updates RFC9353 RFC5089: IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (17 pages) * Updates RFC9353 RFC5376: Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) (14 pages) RFC5394: Policy-Enabled Path Computation Framework (36 pages) RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP) (87 pages) * Updates RFC7896 * Updates RFC8253 * Updates RFC8356 RFC5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths (18 pages) RFC5455: Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol (9 pages) RFC5520: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism (19 pages) RFC5521: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions (16 pages) RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (23 pages) RFC5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization (26 pages) RFC5623: Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (34 pages) RFC5671: Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) (15 pages) RFC5862: Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE (11 pages) RFC5886: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture (26 pages) RFC6006: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (33 pages) * Obsoletes RFC8306 RFC6007: Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations (18 pages) RFC6123: Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts (13 pages) RFC6457: PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (12 pages) RFC6805: The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS (33 pages) RFC7025: Requirements for GMPLS Applications of PCE (12 pages) RFC7150: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (12 pages) * Obsoletes RFC7470 RFC7334: PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths (25 pages) RFC7399: Unanswered Questions in the Path Computation Element Architecture (29 pages) RFC7420: Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module (65 pages) RFC7449: Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (12 pages) RFC7470: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (14 pages) RFC7896: Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) (5 pages) RFC7897: Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) (35 pages) RFC8051: Applicability of a Stateful Path Computation Element (PCE) (24 pages) RFC8231: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE (57 pages) * Updates RFC8786 * Updates RFC9353 RFC8232: Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE (26 pages) RFC8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) (31 pages) RFC8253: PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) (26 pages) RFC8281: Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model (20 pages) RFC8282: Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering (22 pages) RFC8306: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (43 pages) * Updates RFC9353 RFC8356: Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) (7 pages) RFC8408: Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages (12 pages) * Updates RFC8664 RFC8623: Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) (33 pages) RFC8637: Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) (22 pages) RFC8664: Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (29 pages) RFC8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture (27 pages) RFC8694: Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering (24 pages) RFC8697: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) (28 pages) RFC8733: Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE (32 pages) RFC8741: Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) (11 pages) RFC8745: Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE (15 pages) RFC8751: Hierarchical Stateful Path Computation Element (PCE) (21 pages) RFC8779: Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS (38 pages) RFC8780: The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) (26 pages) RFC8786: Updated Rules for Processing Stateful PCE Request Parameters Flags (6 pages) RFC8800: Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling (21 pages) RFC8934: PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE (23 pages) RFC9005: Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) (15 pages) RFC9050: Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs (33 pages) RFC9059: Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) (20 pages) RFC9168: Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification (29 pages) RFC9357: Label Switched Path (LSP) Object Flag Extension for Stateful PCE (9 pages) RFC9358: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks (12 pages) Protocols for IP Multicast (pim) -------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Mike McBride Stig Venaas Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Tech Advisor: Brian Haberman Mailing Lists: General Discussion: pim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pim/ Archive: https://mailarchive.ietf.org/arch/browse/pim/ Description of Working Group: The Protocols for IP Multicast (PIM) working group, is chartered to work on multiple IP multicast protocols. The Working Group is responsible for the maintenance of PIM, IGMP, and MLD. The Working Group will work on the following specific items: 1) Management: YANG models for PIM, IGMP, and MLD will be developed, for both configuration and operational states. If updates to existing MIB modules are necessary, the WG may work on those. 2) Improve PIM authentication. 3) Improve and Extend PIM Join Attributes to support different types of multicast applications. 4) Optimization approaches for IGMP and MLD to adapt to link conditions in wireless and mobile networks and be more robust to packet loss. Additional work items may be added with a recharter. The WG should discuss and develop new ideas related to multicast protocols and distribution of multicast related information. The WG is expected to use its extensive multicast knowledge to actively review and participate in WG Last Calls with multicast work that occurs in other WGs, such as MBONED, LISP, MPLS, BESS, ROLL, and BIER. The WG should investigate any extensions needed to support other work and, if additional work is required, the WG may be rechartered to accomplish the specific extensions. Goals and Milestones: Nov 2015 - mld yang model submitted to iesg Nov 2015 - igmp yang model submitted to iesg Nov 2015 - Resubmit explicit-rpf-vector draft to IESG Nov 2015 - Submit PIM Join Attributes for LISP Environments to IESG Apr 2016 - submit solutions for IGMP and MLD to adapt to wireless link conditions Apr 2016 - pim sm yang model submitted to iesg Jul 2016 - pim ssm yang model submitted to iesg Jul 2016 - Adopt a draft which provides improvements to pim authentication Internet-Drafts: - IANA Considerations for Internet Group Management Protocols [draft-ietf-pim-3228bis-01] (5 pages) - Internet Group Management Protocol, Version 3 [draft-ietf-pim-3376bis-06] (55 pages) - Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [draft-ietf-pim-3810bis-06] (66 pages) - Anycast-RP Using Protocol Independent Multicast (PIM) [draft-ietf-pim-anycast-rp-07] (12 pages) - PIM Assert Message Packing [draft-ietf-pim-assert-packing-12] (25 pages) - PIM Backup Designated Router Procedure [draft-ietf-pim-bdr-01] (7 pages) - Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks [draft-ietf-pim-bfd-p2mp-use-case-10] (7 pages) - Bidirectional Protocol Independent Multicast (BIDIR-PIM) [draft-ietf-pim-bidir-09] (43 pages) - Protocol Independent Multicast (PIM) Bootstrap Router MIB [draft-ietf-pim-bsr-mib-06] (23 pages) - Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) [draft-ietf-pim-dm-new-v2-05] (61 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement [draft-ietf-pim-dr-improvement-14] (13 pages) - PIM Designated Router Load Balancing [draft-ietf-pim-drlb-15] (18 pages) - Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect [draft-ietf-pim-ecmp-05] (12 pages) - Explicit Reverse Path Forwarding (RPF) Vector [draft-ietf-pim-explicit-rpf-vector-09] (9 pages) - IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers [draft-ietf-pim-explicit-tracking-13] (11 pages) - PIM Group-to-Rendezvous-Point Mapping [draft-ietf-pim-group-rp-mapping-10] (11 pages) - PIM Neighbor Hello GenId Option [draft-ietf-pim-hello-genid-01] (3 pages) - An Interface Identifier (ID) Hello Option for PIM [draft-ietf-pim-hello-intid-01] (6 pages) - Hierarchical Join/Prune Attributes [draft-ietf-pim-hierarchicaljoinattr-08] (8 pages) - Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension [draft-ietf-pim-igmp-mld-extension-08] (12 pages) - A YANG Data Model for IGMP/MLD Proxy [draft-ietf-pim-igmp-mld-proxy-yang-10] (22 pages) - A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping [draft-ietf-pim-igmp-mld-snooping-yang-20] (37 pages) - IGMP and MLD Snooping Yang Module Extension for L2VPN [draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext-02] (21 pages) - IGMP/MLD Optimizations in Wireless and Mobile Networks [draft-ietf-pim-igmp-mld-wireless-mobile-00] (13 pages) - A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) [draft-ietf-pim-igmp-mld-yang-15] (45 pages) - Use of PIM Address List Hello across address families [draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02] (5 pages) - Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) [draft-ietf-pim-ipv6-04] (5 pages) - The Protocol Independent Multicast (PIM) Join Attribute Format [draft-ietf-pim-join-attributes-06] (10 pages) - PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments [draft-ietf-pim-join-attributes-for-lisp-06] (9 pages) - PIM Join/ Prune Attributes for LISP Environments using Underlay Multicast [draft-ietf-pim-jp-extensions-lisp-03] (5 pages) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages) - PIM Light [draft-ietf-pim-light-00] (7 pages) - Protocol Independent Multicast MIB [draft-ietf-pim-mib-v2-10] (90 pages) - Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute [draft-ietf-pim-mofrr-tilfa-01] (12 pages) - A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) [draft-ietf-pim-msdp-yang-18] (37 pages) - PIM Multi-Topology ID (MT-ID) Join Attribute [draft-ietf-pim-mtid-10] (13 pages) - Multicast Lessons Learned from Decades of Deployment Experience [draft-ietf-pim-multicast-lessons-learned-00] (14 pages) - Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces [draft-ietf-pim-multiple-upstreams-reqs-08] (14 pages) - PIM Null-Register packing [draft-ietf-pim-null-register-packing-16] (9 pages) - P2MP Policy Ping [draft-ietf-pim-p2mp-policy-ping-03] (7 pages) - Population Count Extensions to Protocol Independent Multicast (PIM) [draft-ietf-pim-pop-count-07] (15 pages) - A Reliable Transport Mechanism for PIM [draft-ietf-pim-port-09] (29 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis [draft-ietf-pim-proposed-req-02] (8 pages) - Format for using PIM proxies [draft-ietf-pim-proxy-00] (7 pages) - State Refresh in PIM-DM [draft-ietf-pim-refresh-02] (10 pages) - A Registry for PIM Message Types [draft-ietf-pim-registry-04] (4 pages) - PIM Message Type Space Extension and Reserved Bits [draft-ietf-pim-reserved-bits-04] (8 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-rfc4601bis-06] (137 pages) - Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments [draft-ietf-pim-rfc4601-update-survey-report-03] (12 pages) - PIM Message Type Space Extension and Reserved Bits [draft-ietf-pim-rfc8736bis-04] (8 pages) - The Reverse Path Forwarding (RPF) Vector TLV [draft-ietf-pim-rpf-vector-08] (8 pages) - Simple Key Management Protocol for PIM [draft-ietf-pim-simplekmp-02] (8 pages) - Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) [draft-ietf-pim-sm-bsr-12] (42 pages) - Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages [draft-ietf-pim-sm-linklocal-10] (21 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-sm-v2-new-12] (150 pages) - PIM Flooding Mechanism (PFM) and Source Discovery (SD) [draft-ietf-pim-source-discovery-bsr-12] (18 pages) - Segment Routing Point-to-Multipoint Policy [draft-ietf-pim-sr-p2mp-policy-06] (20 pages) - Authenticating PIM version 2 messages [draft-ietf-pim-v2-auth-01] (4 pages) - Protocol Independent Multicast Version 2 Dense Mode Specification [draft-ietf-pim-v2-dm-03] (18 pages) - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification [draft-ietf-pim-v2-sm-01] (65 pages) - YANG Data Model for Protocol Independent Multicast (PIM) [draft-ietf-pim-yang-17] (92 pages) Requests for Comments: RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (61 pages) * Updates RFC8736 RFC4601: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (150 pages) * Updates RFC5059 * Updates RFC5796 * Updates RFC6226 * Obsoletes RFC7761 RFC4602: Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis (8 pages) RFC4610: Anycast-RP Using Protocol Independent Multicast (PIM) (12 pages) RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM) (43 pages) * Updates RFC8736 RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (42 pages) * Updates RFC8736 RFC5060: Protocol Independent Multicast MIB (90 pages) RFC5240: Protocol Independent Multicast (PIM) Bootstrap Router MIB (23 pages) RFC5294: Host Threats to Protocol Independent Multicast (PIM) (12 pages) RFC5384: The Protocol Independent Multicast (PIM) Join Attribute Format (10 pages) * Updates RFC7887 RFC5496: The Reverse Path Forwarding (RPF) Vector TLV (8 pages) RFC5796: Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages (21 pages) RFC6166: A Registry for PIM Message Types (4 pages) * Obsoletes RFC8736 RFC6226: PIM Group-to-Rendezvous-Point Mapping (11 pages) RFC6395: An Interface Identifier (ID) Hello Option for PIM (6 pages) RFC6420: PIM Multi-Topology ID (MT-ID) Join Attribute (13 pages) RFC6559: A Reliable Transport Mechanism for PIM (29 pages) RFC6754: Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect (12 pages) * Updates RFC8736 RFC6807: Population Count Extensions to Protocol Independent Multicast (PIM) (15 pages) RFC7063: Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments (12 pages) RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages) * Updates RFC8736 RFC7887: Hierarchical Join/Prune Attributes (8 pages) RFC7891: Explicit Reverse Path Forwarding (RPF) Vector (9 pages) RFC8059: PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments (9 pages) RFC8364: PIM Flooding Mechanism (PFM) and Source Discovery (SD) (18 pages) * Updates RFC8736 RFC8652: A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) (45 pages) RFC8736: PIM Message Type Space Extension and Reserved Bits (8 pages) RFC8775: PIM Designated Router Load Balancing (18 pages) RFC8916: A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) (37 pages) RFC9128: YANG Data Model for Protocol Independent Multicast (PIM) (92 pages) RFC9166: A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping (37 pages) RFC9186: Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks (7 pages) RFC9279: Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension (12 pages) STD83: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages) Pseudowire And LDP-enabled Services (pals) ------------------------------------------ Charter Last Modified: 2023-03-28 Current Status: Active Chairs: Andrew G. Malis Stewart Bryant Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Secretary: Dave Sinicrope Mailing Lists: General Discussion: pals@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pals Archive: https://mailarchive.ietf.org/arch/browse/pals/ Description of Working Group: Many services that run in the Internet are facilitated in MPLS networks by the Label Distribution Protocol (LDP) and/or are established over pseudowires that emulate point-to-point or point-to-multipoint links and provide communication connectivity that is perceived by its users as an unshared link or circuit of an emulated Layer-1, Layer-2, or Layer-3 service type. Layer-2 Virtual Private Networks (L2VPNs) are one such service that provides an emulation of a "native" service over a packet switched network that is adequately faithful to, but may not be entirely indistinguishable from, the native service itself. The Pseudowire And LDP-enabled Services (PALS) working group is chartered to define, specify, and extend network services based on pseudowires and/or signaled using LDP. In particular, the working group will work on the following services: - All types of MPLS-based and L2TPv3-based pseudowire services including point-to-point and point-to-multipoint pseudowires, single segment and multi-segment pseudowires, single and multi-domain pseudowires, and signaled and statically provisioned pseudowires. - All types of dynamic or static provider-provisioned L2VPNs that operate over pseudowires or that are enabled over MPLS networks using LDP as a control plane mechanism. - IP-only L2VPN solutions (for IP-only services over a packet switched network). The working group may also suggest new services to be supported by LDP or pseudowires and these may be added to the working group charter subject to re-chartering. The working group is also responsible for the maintenance and development of pseudowires formerly carried out by the PWE3 working group The PALS working group will not define any mechanisms that exert control over the underlying packet switched network. When necessary it may, however, recommend or require the use of existing QoS and path control mechanisms between the edge nodes that provide the connectivity to the services. The working group may work on: - New pseudowire encapsulations or types for services emulated over IETF-specified Packet Switched Networks. - Operations, Administration, and Management (OAM) for pseudowires including interworking of OAM for pseudowires and native services, and OAM for other services worked on by PALS (including L2VPNs). But new techniques should be shared with the BFD and MPLS working groups to ensure consistency with existing OAM techniques, and with the LIME working group to provide for consistency of operation. - Protocol extensions for LDP in support of new pseudowire function and new services, but all protocol extensions must be reviewed by the MPLS working group which is responsible for the consistency and stability of LDP. - Mechanisms to enhance pseudowire and L2VPN functionality by including security, protection and restoration, congestion avoidance, and load balancing across parallel packet switched tunnels. - Mechanisms to permit optimization of multicast data traffic within an L2VPN. - Enhancements to increase the scalability of the control plane and data plane of L2VPN solutions and application of L2VPN solutions in the data center, the latter in coordination with the NVO3 working group - L2VPN discovery and membership mechanisms that utilize pseudowire control and management procedures. - Data models for modeling, managing, and operating the services worked on by the PALS working group using SMI or YANG. The PALS working group will not work on L2VPNs enabled using BGP, and where L2VPNs that are within the scope of the PALS working group use BGP to add functionality (for example for discovery of membership of a VPN) this work will be coordinated with the BESS working group. This also includes work on particular types of L2VPNs that support both LDP and BGP signaling, such as VPLS. Any contention between these working groups on the placement of such work will be resolved by the chairs. The PALS working group will coordinate closely with the MPLS working group for all work involving LDP and the MPLS data plane. It will also coordinate with the MPLS working group in developing shared security, and with the BFD and MPLS working groups on OAM solutions. Where extensions to pseudowires are needed to support time or frequency transfer, this work will be done by the PALS working group in consultation with the TICTOC working group. L2TP specifics of L2TPv3-based pseudowires will continue to be the responsibility of the L2TPEXT working group. Goals and Milestones: Jun 2016 - Submit LDP-VPLS for Ethernet Broadcast and Multicast to the IESG Jun 2017 - Submit L2VPN applicability statement for data center applications to the IESG Done - Submit STP Application of ICCP to the IESG Done - Submit PW Congestion Considerations to the IESG Done - Submit Pseudowire Redundancy on S-PE to the IESG Done - Submit Unified Control Channel for PWs to the IESG Done - Submit MAC Address Withdrawal over Static Pseudowire to the IESG Done - Submit S-PE resilience for statically provisioned MS-PWs to the IESG Done - Submit LDP extensions for PW Binding to LSP Tunnels to the IESG Done - Submit P2MP PW Signaling (root initiated) to the IESG Done - Submit PW Endpoint Fast Failure Protection to the IESG Done - Submit MPLS LSP PW status refresh reduction for Static PWs to the IESG Done - Submit PIM Snooping over VPLS to the IESG Done - Submit E-Tree Support in VPLS to the IESG jointly with the BESS WG Work transferred to the BESS working group - Submit YANG data model for SS-PWs and MS-PWs to the IESG Internet-Drafts: - Use of Ethernet Control Word RECOMMENDED [draft-bryant-pals-ethernet-cw-01] (8 pages) - Seamless BFD for VCCV [draft-gp-pals-seamless-vccv-01] (10 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-l2vpn-ldp-vpls-broadcast-exten-08] (19 pages) - MAC Address Withdrawal over Static Pseudowire [draft-ietf-l2vpn-mpls-tp-mac-wd-00] (8 pages) - Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pe-etree-11] (26 pages) - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pim-snooping-07] (39 pages) - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-04] (13 pages) - Pseudowire Congestion Considerations [draft-ietf-pals-congcons-02] (27 pages) - Pseudowire (PW) Endpoint Fast Failure Protection [draft-ietf-pals-endpoint-fast-protection-05] (43 pages) - Recommendation to Use the Ethernet Control Word [draft-ietf-pals-ethernet-cw-07] (9 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-pals-ldp-vpls-broadcast-exten-01] (19 pages) - Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS [draft-ietf-pals-mc-pon-05] (16 pages) - Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection [draft-ietf-pals-mpls-tp-dual-homing-coordination-06] (17 pages) - Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires [draft-ietf-pals-mpls-tp-dual-homing-protection-06] (11 pages) - Media Access Control (MAC) Address Withdrawal over Static Pseudowire [draft-ietf-pals-mpls-tp-mac-wd-03] (10 pages) - LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pals-mpls-tp-oam-config-03] (30 pages) - LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels [draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09] (16 pages) - Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires [draft-ietf-pals-ms-pw-protection-04] (9 pages) - Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP [draft-ietf-pals-p2mp-pw-04] (20 pages) - Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms [draft-ietf-pals-p2mp-pw-lsp-ping-05] (10 pages) - Pseudowire Redundancy on the Switching Provider Edge (S-PE) [draft-ietf-pals-redundancy-spe-03] (9 pages) - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) [draft-ietf-pals-rfc4447bis-05] (35 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) [draft-ietf-pals-seamless-vccv-03] (11 pages) - MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs [draft-ietf-pals-status-reduction-05] (20 pages) - Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator [draft-ietf-pals-vccv-for-gal-06] (9 pages) - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-pals-vpls-pim-snooping-06] (43 pages) - Pseudowire Congestion Considerations [draft-ietf-pwe3-congcons-02] (22 pages) - PW Endpoint Fast Failure Protection [draft-ietf-pwe3-endpoint-fast-protection-02] (29 pages) - Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) [draft-ietf-pwe3-iccp-stp-05] (25 pages) - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pwe3-mpls-tp-oam-config-01] (23 pages) - LDP extensions for Pseudowire Binding to LSP Tunnels [draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-03] (15 pages) - Pseudowire Redundancy on S-PE [draft-ietf-pwe3-redundancy-spe-03] (8 pages) - Pseudowire Setup and Maintenance using the Label Distribution Protocol [draft-ietf-pwe3-rfc4447bis-03] (32 pages) - A Unified Control Channel for Pseudowires [draft-ietf-pwe3-vccv-for-gal-02] (9 pages) - Definition of P2MP PW TLV for LSP-Ping Mechanisms [draft-jain-pwe3-p2mp-pw-lsp-ping-03] (8 pages) - Private Line Emulation over Packet Switched Networks [draft-schmutzer-pals-ple-04] (29 pages) Requests for Comments: RFC7708: Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator (9 pages) RFC7727: Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) (25 pages) RFC7769: Media Access Control (MAC) Address Withdrawal over Static Pseudowire (10 pages) RFC7771: Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires (9 pages) RFC7795: Pseudowire Redundancy on the Switching Provider Edge (S-PE) (9 pages) RFC7796: Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) (26 pages) RFC7885: Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) (11 pages) RFC7893: Pseudowire Congestion Considerations (27 pages) RFC7965: LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels (16 pages) RFC8024: Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS (16 pages) RFC8077: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) RFC8104: Pseudowire (PW) Endpoint Fast Failure Protection (43 pages) RFC8184: Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires (11 pages) RFC8185: Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection (17 pages) RFC8220: Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) (43 pages) RFC8237: MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs (20 pages) RFC8338: Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP (20 pages) RFC8339: Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms (10 pages) RFC8469: Recommendation to Use the Ethernet Control Word (9 pages) STD84: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) Reliable and Available Wireless (raw) ------------------------------------- Charter Last Modified: 2023-03-23 Current Status: Active Chairs: Eve Schooler Rick Taylor Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Mailing Lists: General Discussion: raw@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/raw Archive: https://mailarchive.ietf.org/arch/browse/raw/ Description of Working Group: Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity over a wireless medium. The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS), etc. Similar to DetNet, RAW will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability. While DetNet solutions apply to both wireless and wired, there has been recent industry interest for wireless applications which were not initially included in the DetNet use cases. One critical application is Aeronautical Data Communications. The Aeronautical standards work on a physical layer and data link layer for data communications is reaching maturity and there is significant interest in IP connectivity applications. Other examples of potential wireless applications include industrial, pro audio and video, gaming, and edge robotics. In the interests of providing timely solutions for these newly identified industry applications, RAW’s focus will be on specifying use cases associated with these new applications and defining requirements derived from them. RAW will solicit input on deployment plans, requirements, and operational practices (including security and privacy aspects) for these newer industrial applications. RAW’s primary focus is on identifying areas where the DetNet adaptation to wireless networks and other IETF technologies may require additional supporting mechanisms. The RAW Working Group will also examine the applicability of other existing IETF work, e.g., MANET's dynamic link exchange protocol (DLEP). The RAW Working Group will provide input to the DetNet Working Group, MANET Working Group, and other IETF Working Groups, and cooperate in reviewing solutions to RAW’s identified deployment problems. RAW is not chartered to work on a solution. If solution work is needed, the Working Group will coordinate with the IESG to determine where the work will be done. If RAW is chosen for the solution work, the Working Group will recharter. The RAW Working Group is planned to be a short timeframe (12-18 months) Working Group to quickly address these newer industry applications. The initial milestones will be published as Informational documents: Use Cases, Requirements, Architecture/Framework Aspects for a Wireless Network, and an Evaluation of Existing IETF Technologies and Gap Analysis. Additional documents may be published or exist on a git repository, the publication format will be agreed by the Working Group at the time the document is adopted by the group. The Use Case document may consist of one or more documents to allow users/operators the opportunity to provide comprehensive deployment plans for these new (to IETF) technologies, e.g., the Aeronautical Data Communication applications. The group will closely coordinate with the DetNet and MANET Working Groups. The work produced by this group may be of interest to other SDOs, 3GPP, IEEE, and the Aeronautical industry. Goals and Milestones: Feb 2022 - Technologies Document submit to IESG Mar 2022 - OAM Document submitted to IESG May 2022 - Architecture/Framework Aspects for a Wireless Network Document submit to IESG Nov 2022 - Working Group Adoption of Evaluation of Existing IETF Technologies and Gap Analysis Document Feb 2023 - Framework Aspects for a Wireless Network Document Jul 2023 - Evaluation of Existing IETF Technologies and Gap Analysis Document submit to IESG Done - Working Group Adoption of Technologies Document Done - Working Group Adoption of Use Cases Document Done - Working Group Adoption of LDACS Document Done - Working Group Adoption of OAM Document Done - LDACS Document submitted to IESG Done - Working Group Adoption of Architecture/Framework Aspects for a Wireless Network Document Done - Use Cases Document submit to IESG Internet-Drafts: - Reliable and Available Wireless Architecture [draft-ietf-raw-architecture-11] (40 pages) - Reliable and Available Wireless Framework [draft-ietf-raw-framework-01] (18 pages) - Requirements for Reliable Wireless Industrial Services [draft-ietf-raw-industrial-requirements-00] (23 pages) - L-Band Digital Aeronautical Communications System (LDACS) [draft-ietf-raw-ldacs-14] (35 pages) - Operations, Administration and Maintenance (OAM) features for RAW [draft-ietf-raw-oam-support-06] (17 pages) - Reliable and Available Wireless Technologies [draft-ietf-raw-technologies-06] (71 pages) - RAW Use-Cases [draft-ietf-raw-use-cases-11] (29 pages) Requests for Comments: RFC9372: L-Band Digital Aeronautical Communications System (LDACS) (35 pages) Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Jeff Tantsura Yingzhen Qu Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: rtgwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtgwg Archive: https://mailarchive.ietf.org/arch/browse/rtgwg/ Description of Working Group: The Routing Area working group (RTGWG) is chartered to provide a venue to discuss, evaluate, support and develop proposals for new work in the Routing Area and may work on specific small topics that do not fit with an existing working group. Options for handling new work include: - Directing the work to an existing WG (including RTGWG) - Developing a proposal for a BoF. - Developing a charter and establishing consensus for a new WG. This option will primarily be used with fairly mature and/or well-defined efforts. - Careful evaluation, leading to deferring or rejecting work. It is expected that the proposals for new work will only include items which are not aligned with the work of other WGs or that may span multiple WGs. The Area Directors and WG Chairs can provide guidance if there is any doubt whether a topic should be discussed in RTGWG. A major objective of the RTGWG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. If RTGWG decides that a particular topic should be addressed by a new WG, the chairs will recommend the work to the Routing ADs with a summary of the evaluation. The Routing ADs may then choose to follow the normal IETF chartering process (potential BoF, IETF-wide review of the proposed charter, etc.). Guiding principles for evaluation of new work by RTGWG will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts to manage the trade-offs between urgency, interest, and available resources in the Routing Area. 3. Looking for commonalities among ongoing efforts. Such commonalities may indicate the need to develop more general, reusable solutions. 4. Ensuring appropriate cross-WG and cross-area review. 5. Protecting the architectural integrity of the protocols developed in the Routing Area and ensuring that work has significant applicability. RTGWG may also work on specific small topics that do not fit with an existing working group. An example of a small topic is a draft that might otherwise be AD-sponsored but which could benefit from the review and consensus that RTGWG can provide. RTGWG may work on larger topics, but must be explicitly rechartered to add the topic. The specific larger topics that RTGWG is currently chartered to work on: * Enhancements to hop-by-hop distributed routing (e.g., multicast, LDP-MPLS, unicast routing) related to fast-reroute and loop-free convergence. A specific goal of fast-reroute mechanisms is to provide up to complete coverage when the potential failure would not partition the network. All work in this area should be specifically evaluated by the WG in terms of practicality and applicability to deployed networks. * Routing-related YANG models that are not appropriate for other RTG working groups. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. Goals and Milestones: Nov 2014 - Submit Remote LFA (link protection) for publication as Proposed Standard Mar 2015 - Submit initial Internet Draft on Multicast IP Fast Reroute Architecture Mar 2015 - Submit Composite-Link Framework to IESG for publication as Informational Mar 2015 - Submit Composite-Link Requirements to IESG for publication as Informational Jul 2015 - Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard Jul 2015 - Submit Document on Operational Experience of using BGP in a Data Center for publication as Informational Jul 2015 - Submit Operational Management for LFA for publication as Proposed Standard Jul 2015 - Submit Remote LFA (node protection) for publication as Proposed Standard Nov 2015 - Submit MIB for IP Fast-Reroute for publication as Proposed Standard Internet-Drafts: - RIB YANG Data Model [draft-acee-rtgwg-yang-rib-extend-10] (21 pages) - YANG Model for QoS [draft-asechoud-rtgwg-qos-model-11] (89 pages) - Topology Independent Fast Reroute using Segment Routing [draft-bashandy-rtgwg-segment-routing-ti-lfa-05] (19 pages) - Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution [draft-bowbakova-rtgwg-enterprise-pa-multihoming-01] (45 pages) - Routing Timer Parameter Synchronization [draft-bryant-rtgwg-param-sync-03] (10 pages) - YANG Data Model for ARP [draft-ding-rtgwg-arp-yang-model-02] (15 pages) - Calculating IGP routes over Traffic Engineering tunnels [draft-hsmit-mpls-igp-spf-01] (6 pages) - SRv6 Path Egress Protection [draft-hu-rtgwg-srv6-egress-protection-08] (16 pages) - YANG Data Model for ARP [draft-ietf-rtgwg-arp-yang-model-03] (17 pages) - A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network [draft-ietf-rtgwg-atn-bgp-20] (27 pages) - Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs [draft-ietf-rtgwg-backoff-algo-10] (14 pages) - BGP Prefix Independent Convergence [draft-ietf-rtgwg-bgp-pic-19] (32 pages) - Use of BGP for Routing in Large-Scale Data Centers [draft-ietf-rtgwg-bgp-routing-large-dc-11] (35 pages) - Advanced Multipath Framework in MPLS [draft-ietf-rtgwg-cl-framework-04] (43 pages) - Requirements for Advanced Multipath in MPLS Networks [draft-ietf-rtgwg-cl-requirement-16] (17 pages) - Advanced Multipath Use Cases and Design Considerations [draft-ietf-rtgwg-cl-use-cases-06] (24 pages) - Network Device YANG Logical Organization [draft-ietf-rtgwg-device-model-02] (22 pages) - Destination/Source Routing [draft-ietf-rtgwg-dst-src-routing-07] (21 pages) - Encapsulation Considerations [draft-ietf-rtgwg-dt-encap-02] (42 pages) - Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions [draft-ietf-rtgwg-enterprise-pa-multihoming-12] (43 pages) - Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels [draft-ietf-rtgwg-igp-shortcut-01] (8 pages) - IP Fast Reroute Framework [draft-ietf-rtgwg-ipfrr-framework-13] (15 pages) - IP MIB for IP Fast-Reroute [draft-ietf-rtgwg-ipfrr-ip-mib-08] (28 pages) - A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses [draft-ietf-rtgwg-ipfrr-notvia-addresses-11] (34 pages) - Basic Specification for IP Fast Reroute: Loop-Free Alternates [draft-ietf-rtgwg-ipfrr-spec-base-12] (31 pages) - Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks [draft-ietf-rtgwg-lfa-applicability-06] (35 pages) - Operational Management of Loop-Free Alternates [draft-ietf-rtgwg-lfa-manageability-11] (31 pages) - A Framework for Loop-Free Convergence [draft-ietf-rtgwg-lf-conv-frmwk-07] (22 pages) - YANG Model for Logical Network Elements [draft-ietf-rtgwg-lne-model-10] (49 pages) - Analysis and Minimization of Microloops in Link-state Routing Protocols [draft-ietf-rtgwg-microloop-analysis-01] (17 pages) - Multicast-Only Fast Reroute [draft-ietf-rtgwg-mofrr-08] (14 pages) - An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) [draft-ietf-rtgwg-mrt-frr-algorithm-09] (118 pages) - An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) [draft-ietf-rtgwg-mrt-frr-architecture-10] (44 pages) - Selection of Loop-Free Alternates for Multi-Homed Prefixes [draft-ietf-rtgwg-multihomed-prefix-lfa-09] (20 pages) - Networks Connecting to Hybrid Cloud DCs: Gap Analysis [draft-ietf-rtgwg-net2cloud-gap-analysis-09] (19 pages) - Status of this Memo [draft-ietf-rtgwg-net2cloud-problem-statement-26] (20 pages) - YANG Data Model for Network Instances [draft-ietf-rtgwg-ni-model-12] (44 pages) - Node Potential Oriented Multi-NextHop Routing Protocol [draft-ietf-rtgwg-npmnrp-00] (25 pages) - Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach [draft-ietf-rtgwg-ordered-fib-12] (28 pages) - A YANG Data Model for Routing Policy [draft-ietf-rtgwg-policy-model-31] (38 pages) - YANG Models for Quality of Service (QoS) [draft-ietf-rtgwg-qos-model-10] (96 pages) - Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) [draft-ietf-rtgwg-remote-lfa-11] (29 pages) - The Generalized TTL Security Mechanism (GTSM) [draft-ietf-rtgwg-rfc3682bis-10] (16 pages) - Remote-LFA Node Protection and Manageability [draft-ietf-rtgwg-rlfa-node-protection-13] (22 pages) - Routing Timer Parameter Synchronization [draft-ietf-rtgwg-routing-timer-param-sync-00] (10 pages) - Common YANG Data Types for the Routing Area [draft-ietf-rtgwg-routing-types-17] (43 pages) - Topology Independent Fast Reroute using Segment Routing [draft-ietf-rtgwg-segment-routing-ti-lfa-10] (24 pages) - Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops [draft-ietf-rtgwg-spf-uloop-pb-statement-10] (15 pages) - SRv6 Path Egress Protection [draft-ietf-rtgwg-srv6-egress-protection-09] (16 pages) - Micro-loop Prevention by Introducing a Local Convergence Delay [draft-ietf-rtgwg-uloop-delay-09] (26 pages) - Fast failure detection in VRRP with Point to Point BFD [draft-ietf-rtgwg-vrrp-bfd-p2p-01] (21 pages) - Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) [draft-ietf-rtgwg-vrrp-p2mp-bfd-04] (6 pages) - Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 [draft-ietf-rtgwg-vrrp-rfc5798bis-06] (43 pages) - YANG Data Model for Key Chains [draft-ietf-rtgwg-yang-key-chain-24] (25 pages) - RIB Extension YANG Data Model [draft-ietf-rtgwg-yang-rib-extend-21] (25 pages) - A YANG Data Model for the Routing Information Protocol (RIP) [draft-ietf-rtgwg-yang-rip-11] (40 pages) - A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) [draft-ietf-rtgwg-yang-vrrp-11] (45 pages) - Destination/Source Routing [draft-lamparter-rtgwg-dst-src-routing-01] (8 pages) - Microloop prevention by introducing a local convergence delay [draft-litkowski-rtgwg-uloop-delay-04] (15 pages) - A YANG Data Model for Routing Information Protocol (RIP) [draft-liu-rtgwg-yang-rip-01] (30 pages) - A YANG Data Model for Virtual Router Redundancy Protocol (VRRP) [draft-liu-rtgwg-yang-vrrp-04] (30 pages) - LFA selection for Multi-Homed Prefixes [draft-psarkar-rtgwg-multihomed-prefix-lfa-04] (16 pages) - Remote-LFA Node Protection and Manageability [draft-psarkar-rtgwg-rlfa-node-protection-05] (16 pages) - Encapsulation Considerations [draft-rtg-dt-encap-02] (41 pages) - Network Device YANG Organizational Models [draft-rtgyangdt-rtgwg-device-model-05] (22 pages) - Logical Network Element Model [draft-rtgyangdt-rtgwg-lne-model-00] (13 pages) - Network Instance Model [draft-rtgyangdt-rtgwg-ni-model-00] (15 pages) - Routing Area Common YANG Data Types [draft-rtgyangdt-rtgwg-routing-types-00] (16 pages) - Routing Policy Configuration Model for Service Provider Networks [draft-shaikh-rtgwg-policy-model-01] (30 pages) - A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network [draft-templin-atn-bgp-08] (18 pages) Requests for Comments: RFC3906: Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels (8 pages) RFC5082: The Generalized TTL Security Mechanism (GTSM) (16 pages) RFC5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates (31 pages) * Updates RFC8518 RFC5714: IP Fast Reroute Framework (15 pages) RFC5715: A Framework for Loop-Free Convergence (22 pages) RFC6571: Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks (35 pages) RFC6976: Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach (28 pages) RFC6981: A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses (34 pages) RFC7226: Requirements for Advanced Multipath in MPLS Networks (17 pages) RFC7431: Multicast-Only Fast Reroute (14 pages) RFC7490: Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) (29 pages) RFC7811: An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) (118 pages) RFC7812: An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) (44 pages) RFC7916: Operational Management of Loop-Free Alternates (31 pages) RFC7938: Use of BGP for Routing in Large-Scale Data Centers (35 pages) RFC8102: Remote-LFA Node Protection and Manageability (22 pages) RFC8177: YANG Data Model for Key Chains (25 pages) RFC8294: Common YANG Data Types for the Routing Area (43 pages) RFC8333: Micro-loop Prevention by Introducing a Local Convergence Delay (26 pages) RFC8347: A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) (45 pages) RFC8405: Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs (14 pages) RFC8518: Selection of Loop-Free Alternates for Multi-Homed Prefixes (20 pages) RFC8529: YANG Data Model for Network Instances (44 pages) RFC8530: YANG Model for Logical Network Elements (49 pages) RFC8541: Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops (15 pages) RFC8678: Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions (43 pages) RFC8695: A YANG Data Model for the Routing Information Protocol (RIP) (40 pages) RFC9067: A YANG Data Model for Routing Policy (38 pages) Routing In Fat Trees (rift) --------------------------- Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Jeff Tantsura Zhaohui (Jeffrey) Zhang Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Mailing Lists: General Discussion: rift@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rift Archive: https://mailarchive.ietf.org/arch/search/?email_list=rift Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. Clos and Fat-Tree topologies have gained popularity in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services. The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence. It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification that will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed, security and privacy mitigations for the protocol as identified in the threat analysis document. (q.v.) - A YANG module focused on configuration and monitoring of protocol instances - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors, which shall be sent for publication at the same time as the protocol specification Goals and Milestones: Apr 2020 - Submit protocol specification to IESG for publication Aug 2020 - Submit YANG module to IESG for publication Aug 2020 - Submit Applicability Statement to IESG for publication Done - Adopt a protocol specification document Internet-Drafts: - RIFT Applicability [draft-ietf-rift-applicability-11] (34 pages) - RIFT Auto-EVPN [draft-ietf-rift-auto-evpn-03] (90 pages) - RIFT Key/Value Structure and Registry [draft-ietf-rift-kv-registry-05] (10 pages) - RIFT: Routing in Fat Trees [draft-ietf-rift-rift-17] (174 pages) - SRIFT: Segment Routing in Fat Trees [draft-ietf-rift-sr-00] (9 pages) - A YANG Data Model for Routing in Fat Trees (RIFT) [draft-ietf-rift-yang-06] (41 pages) - RIFT: Routing in Fat Trees [draft-przygienda-rift-05] (67 pages) - RIFT Applicability [draft-wei-rift-applicability-02] (23 pages) - RIFT YANG Model [draft-zhang-rift-yang-02] (22 pages) No Requests for Comments Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Charter Last Modified: 2023-04-21 Current Status: Active Chairs: Dominique Barthel Ines Robles Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: John Scudder Secretary: Michael Richardson Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: https://mailarchive.ietf.org/arch/browse/roll/ Description of Working Group: Low power and Lossy Networks (LLNs ) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. RFC7102 discusses ROLL specific aspects of LLNs, and RFC7228 provides additional terminology for constrained devices. RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from several application perspectives. The Working Group has focused on routing solutions for the areas: connected home, building, and urban sensor networks. It has developed a Framework that takes into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group continues to focus on routing issues for LLN and to maintain, improve and streamline the protocols already developed, including RPL and MPL. The focus is on IPv6 work only. The Working Group will pay particular attention to routing security and manageability (e.g., self-configuration) issues. The working group will consider the transport characteristics that routing protocol messages will experience. ROLL will coordinate closely with the working groups in other areas that focus on constrained networks and/or constrained nodes, such as 6lo, 6tisch, ipwave, lwig and CoRE. Other working groups such as pim, bier and manet will be consulted as needed. The Working group will align with the 6man WG when needed. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Additional protocol elements to reduce packet size and the amount of required routing states - Automatic selection of MPL forwarders to reduce message replication. - Data models for RPL and MPL management. - Multicast enhancements algorithms. Goals and Milestones: May 2022 - Initial submission of a root initiated routing state in RPL to the IESG Sep 2022 - Initial submission of Controlling Secure Network Enrollment in RPL networks draft to the IESG Nov 2022 - Initial submission of Mode of Operation extension for RPL to the IESG Jun 2023 - Initial submission of Capabilities for RPL to the IESG Nov 2023 - Recharter WG or close Nov 2023 - Initial submission of Fast Border Router Crash Detection in RPL to the IESG Nov 2023 - Initial submission of a YANG model for MPL to the IESG Nov 2023 - Initial submission of a proposal for Source-Route Multicast for RPL to the IESG Nov 2023 - Initial submission of a proposal to augment DIS flags and options to the IESG Done - Initial submission of a solution to the problems due to the use of No-Path DAO Messages to the IESG Done - Initial submission of Common Ancestor Objective Functions and Parent Set DAG Metric Container Extension to the IESG Done - Initial submission of routing for RPL Leaves draft to the IESG Done - Initial submission to the IESG of mechanism to turn on RFC8138 compression feature within a RPL network Done - Initial submission of a reactive P2P route discovery mechanism based on AODV-RPL protocol to the IESG Done - Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG Internet-Drafts: - MPL Parameter Configuration Option for DHCPv6 [draft-doi-roll-mpl-parameter-configuration-05] (10 pages) - Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-admin-local-policy-03] (15 pages) - Supporting Asymmetric Links in Low Power Networks: AODV-RPL [draft-ietf-roll-aodv-rpl-17] (44 pages) - Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks [draft-ietf-roll-applicability-ami-15] (24 pages) - Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control [draft-ietf-roll-applicability-home-building-12] (38 pages) - ROLL Applicability Statement Template [draft-ietf-roll-applicability-template-09] (10 pages) - Building Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-building-routing-reqs-09] (26 pages) - RPL Capabilities [draft-ietf-roll-capabilities-09] (17 pages) - Constrained-Cast: Source-Routed Multicast for RPL [draft-ietf-roll-ccast-01] (10 pages) - Root initiated routing state in RPL [draft-ietf-roll-dao-projection-31] (87 pages) - DIS Modifications [draft-ietf-roll-dis-modifications-01] (15 pages) - Efficient Route Invalidation [draft-ietf-roll-efficient-npdao-18] (21 pages) - Controlling Secure Network Enrollment in RPL networks [draft-ietf-roll-enrollment-priority-09] (9 pages) - Home Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-home-routing-reqs-11] (17 pages) - Industrial Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-indus-routing-reqs-06] (27 pages) - The Minimum Rank with Hysteresis Objective Function [draft-ietf-roll-minrank-hysteresis-of-11] (13 pages) - Mode of Operation extension [draft-ietf-roll-mopex-06] (9 pages) - Mode of Operation extension and Capabilities [draft-ietf-roll-mopex-cap-01] (10 pages) - MPL Forwarder Select (MPLFS) [draft-ietf-roll-mpl-forw-select-00] (10 pages) - Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 [draft-ietf-roll-mpl-parameter-configuration-08] (10 pages) - A YANG model for Multicast Protocol for Low power and lossy Networks (MPL) [draft-ietf-roll-mpl-yang-02] (30 pages) - Common Ancestor Objective Function and Parent Set DAG Metric Container Extension [draft-ietf-roll-nsa-extension-11] (18 pages) - Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-roll-of0-20] (14 pages) - A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network [draft-ietf-roll-p2p-measurement-10] (29 pages) - Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [draft-ietf-roll-p2p-rpl-17] (40 pages) - Overview of Existing Routing Protocols for Low Power and Lossy Networks [draft-ietf-roll-protocols-survey-07] (26 pages) - RNFD: Fast border router crash detection in RPL [draft-ietf-roll-rnfd-01] (24 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header [draft-ietf-roll-routing-dispatch-05] (37 pages) - Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks [draft-ietf-roll-routing-metrics-19] (30 pages) - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [draft-ietf-roll-rpl-19] (157 pages) - RPL applicability in industrial networks [draft-ietf-roll-rpl-industrial-applicability-02] (31 pages) - RPL Observations [draft-ietf-roll-rpl-observations-07] (21 pages) - A Security Framework for Routing over Low Power and Lossy Networks [draft-ietf-roll-security-framework-07] (49 pages) - A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) [draft-ietf-roll-security-threats-11] (40 pages) - Terms Used in Routing for Low-Power and Lossy Networks [draft-ietf-roll-terminology-13] (8 pages) - The Trickle Algorithm [draft-ietf-roll-trickle-08] (13 pages) - Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-trickle-mcast-12] (29 pages) - A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header [draft-ietf-roll-turnon-rfc8138-18] (9 pages) - Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves [draft-ietf-roll-unaware-leaves-30] (36 pages) - Routing Requirements for Urban Low-Power and Lossy Networks [draft-ietf-roll-urban-routing-reqs-05] (21 pages) - Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane [draft-ietf-roll-useofrplinfo-44] (49 pages) - ROLL Applicability Statement Template [draft-richardson-roll-applicability-template-02] (15 pages) - MPL forwarder policy for multicast with admin-local scope [draft-vanderstok-roll-admin-local-policy-00] (8 pages) Requests for Comments: RFC5548: Routing Requirements for Urban Low-Power and Lossy Networks (21 pages) RFC5673: Industrial Routing Requirements in Low-Power and Lossy Networks (27 pages) RFC5826: Home Automation Routing Requirements in Low-Power and Lossy Networks (17 pages) RFC5867: Building Automation Routing Requirements in Low-Power and Lossy Networks (26 pages) RFC6206: The Trickle Algorithm (13 pages) RFC6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (157 pages) * Updates RFC9008 * Updates RFC9010 RFC6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (30 pages) RFC6552: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (14 pages) RFC6719: The Minimum Rank with Hysteresis Objective Function (13 pages) RFC6997: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (40 pages) RFC6998: A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network (29 pages) RFC7102: Terms Used in Routing for Low-Power and Lossy Networks (8 pages) RFC7416: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) (40 pages) RFC7731: Multicast Protocol for Low-Power and Lossy Networks (MPL) (29 pages) RFC7732: Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) (15 pages) RFC7733: Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control (38 pages) RFC7774: Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 (10 pages) RFC8036: Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (24 pages) RFC8138: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header (37 pages) * Updates RFC9008 * Updates RFC9035 RFC9008: Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane (49 pages) RFC9009: Efficient Route Invalidation (21 pages) RFC9010: Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves (36 pages) RFC9035: A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header (9 pages) Service Function Chaining (sfc) ------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Jim Guichard Joel M. Halpern Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Andrew Alston Secretary: Tal Mizrahi Mailing Lists: General Discussion: sfc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sfc Archive: https://mailarchive.ietf.org/arch/browse/sfc/ Description of Working Group: Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. The SFC Working Group has developed an Architecture [RFC 7665] and the Network Service Header [RFC 8300] for service function chaining. The focus of the SFC working group moving forward is on aspects of the architecture and/or protocol that need to be addressed to enable effective deployment and usage of this work. In order to maintain focus, the working group primarily produces and advances documents on four topics: 1) Metadata - Define the common type-length-value encoded metadata types with Standards Track RFCs, and produce Informational RFCs to describe common fixed-length (MD-1) metadata usages. 2) Security and Privacy - Mechanisms and guidance for securing metadata via authentication, integrity protection, confidentiality, and/or data minimization are not yet defined. What can be effectively provided, for which scenarios, and how those tools can be provided need to be determined and the tools standardized. 3) OAM and Operations & Management - In order for operators to use these tools in production networks, they need Operations, Administration, and Maintenance tools, as well as management mechanisms. This includes YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs. 4) Transport Considerations - This will capture the expectations SFC places on transport behavior, including dealing with issues such as congestion indications and responses. This should define how NSH works on standardized transports that are expected to see widespread use. Specifically, the SFC WG is chartered to deliver the following: 1. A Standards Track base set of the metadata MD-2 type codes within the metadata class reserved for IETF usage, as specified in RFC 8300. 2. Related Metadata drafts that require more explanation than is reasonable to include in the base MD-2 draft, including MD-1 descriptions and items done once the base draft is complete. 3. YANG models for the management of SFC Components. 4. One or more security related Standards Track and / or Informational RFCs. At least one Standards Track security mechanism RFC is needed. 5. OAM Framework document to provide a common basis for OAM work. This draft will include guidance on how active, passive, and hybrid OAM are to be supported if at all. 6. Specific OAM mechanism documents to provide the tools needed for operational environments. 7. Transport Considerations RFC to cover the expectations SFC and NSH place on transport, and the operational constraints transports used by NSH need to meet. The SFC WG may work on Informational applicability documents that show how the technology, meta-data, and associated control-plane mechanisms can be used in specific use-cases. The SFC WG may work on Informational documents that provide operational considerations. The SFC WG will coordinate with BESS and PCE on the control-plane work related to SFC. Goals and Milestones: Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Oct 2018 - Informational document defining the Operation, Administration and Maintenance (OAM) framework for SFC Dec 2018 - Submit to IESG Informational documents specifying the format of MD-type 1 metadata in DC and Broadband environments Dec 2018 - Submit to IESG Standards Track document specifying MD-type 2 metadata formats Mar 2019 - YANG models for SFF and classifier Jul 2019 - Submit to IESG Informational document defining authentication, integrity protection, and confidentiality of SFC metadata Jul 2019 - Informational document defining transport considerations applicable to SFC Internet-Drafts: - An Update to the OAM Behavior in the Network Service Header (NSH) [draft-boucadair-sfc-oam-packet-03] (6 pages) - Proof of Transit [draft-brockners-proof-of-transit-05] (23 pages) - NSH Encapsulation for In-situ OAM Data [draft-brockners-sfc-ioam-nsh-01] (9 pages) - Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) [draft-eastlake-sfc-nsh-ecn-support-03] (21 pages) - Operating the Network Service Header (NSH) with Next Protocol "None" [draft-farrel-sfc-convent-06] (12 pages) - Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center) [draft-guichard-sfc-nsh-dc-allocation-07] (9 pages) - A Service Chain Aggregation Architecture [draft-ietf-sfc-aggregation-00] (5 pages) - Service Function Chaining (SFC) Architecture [draft-ietf-sfc-architecture-11] (32 pages) - Service Function Chaining (SFC) Control Plane Components & Requirements [draft-ietf-sfc-control-plane-08] (29 pages) - Service Function Chaining Use Cases In Data Centers [draft-ietf-sfc-dc-use-cases-06] (23 pages) - Hierarchical Service Function Chaining (hSFC) [draft-ietf-sfc-hierarchical-11] (29 pages) - Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data [draft-ietf-sfc-ioam-nsh-13] (9 pages) - SFC Long-lived Flow Use Cases [draft-ietf-sfc-long-lived-flow-use-cases-03] (10 pages) - Active OAM for Service Function Chaining (SFC) [draft-ietf-sfc-multi-layer-oam-23] (37 pages) - Network Service Header (NSH) [draft-ietf-sfc-nsh-28] (40 pages) - NSH Context Header Allocation for Broadband [draft-ietf-sfc-nsh-broadband-allocation-01] (9 pages) - Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center) [draft-ietf-sfc-nsh-dc-allocation-02] (8 pages) - Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX [draft-ietf-sfc-nsh-ecn-support-11] (31 pages) - Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers [draft-ietf-sfc-nsh-integrity-09] (25 pages) - Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers [draft-ietf-sfc-nsh-tlv-15] (15 pages) - Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework [draft-ietf-sfc-oam-framework-15] (20 pages) - OAM Packet and Behavior in the Network Service Header (NSH) [draft-ietf-sfc-oam-packet-03] (6 pages) - Service Function Simple Offloads [draft-ietf-sfc-offloads-00] (17 pages) - Problem Statement for Service Function Chaining [draft-ietf-sfc-problem-statement-13] (13 pages) - Proof of Transit [draft-ietf-sfc-proof-of-transit-08] (32 pages) - Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) [draft-ietf-sfc-serviceid-header-14] (11 pages) - Service Function Chaining Use Cases in Mobile Networks [draft-ietf-sfc-use-case-mobility-09] (26 pages) - Performance Measurement (PM) with Alternate Marking Method in Service Function Chaining (SFC) Domain [draft-mirsky-sfc-pmamm-14] (8 pages) - NSH Context Header Allocation -- Broadband [draft-napper-sfc-nsh-broadband-allocation-04] (9 pages) - Network Service Header TLVs [draft-quinn-sfc-nsh-tlv-04] (8 pages) - Integrity Protection for Network Service Header (NSH) and Encryption of Sensitive Context Headers [draft-rebo-sfc-nsh-integrity-03] (28 pages) - Service Function Chaining: Subscriber and Service Identification Use Cases and Variable-Length NSH Context Headers [draft-sarikaya-sfc-hostid-serviceheader-07] (15 pages) - Service Function Chaining: Subscriber and Policy Identification Variable-Length Network Service Header (NSH) Context Headers [draft-sfc-serviceid-header-02] (9 pages) - Active OAM for Service Function Chains in Networks [draft-wang-sfc-multi-layer-oam-12] (15 pages) Requests for Comments: RFC7498: Problem Statement for Service Function Chaining (13 pages) RFC7665: Service Function Chaining (SFC) Architecture (32 pages) RFC8300: Network Service Header (NSH) (40 pages) RFC8393: Operating the Network Service Header (NSH) with Next Protocol "None" (12 pages) RFC8459: Hierarchical Service Function Chaining (hSFC) (29 pages) RFC8924: Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework (20 pages) RFC8979: Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) (11 pages) RFC9145: Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers (25 pages) RFC9263: Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers (15 pages) Source Address Validation in Intra-domain and Inter-domain Networks (savnet) ---------------------------------------------------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Aijun Wang Joel M. Halpern Routing Area Directors: Andrew Alston Jim Guichard John Scudder Routing Area Advisor: Jim Guichard Secretary: Haoyu Song Mailing Lists: General Discussion: savnet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/savnet Archive: https://mailarchive.ietf.org/arch/browse/savnet/ Description of Working Group: Source address validation (SAV) is one important way to mitigate source address spoofing attacks in the data plane. Therefore, it is desirable to deploy SAV in intra-domain and inter-domain networks. However, existing SAV mechanisms like uRPF-related technologies may improperly permit spoofed traffic or block legitimate traffic. The "Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET)" working group will define routing-protocol-independent architectures and procedures to accurately determine the valid incoming router interfaces for specific source prefixes. The accuracy of the new SAV mechanisms is expected to improve upon the current ones. The WG will not work on extending existing mechanisms. The scope of the SAVNET WG includes the SAV function for both intra-domain and inter-domain networks and the validation o