6lo 6man ace acme add anima asap asdf avtcore babel bess bfd bier bmwg bpf calext cats cbor ccamp ccwg cdni cellar core cose dance deleg detnet dhc dispatch dmarc dmm dnsop dnssd dprive drip dtn dult ecrit emailcore emu extra gendispatch gnap grow httpapi httpbis idr intarea iotops ippm ipsecme ivy jmap jose keytrans kitten lake lamps lisp lsr lsvr madinas mailmaint manet masque mboned mediaman mimi mlcodec mls mops moq mpls netconf netmod nfsv4 nmop ntp nvo3 oauth ohai openpgp opsawg pals pce pim ppm pquip privacypass quic radext rats regext rift roll rtgwg satp savnet schc scim scitt secdispatch sidrops sipcore sml snac spice spring srv6ops stir suit taps tcpm teas teep tictoc tls tsvwg tvr uta v6ops vcon webtrans wimse wish IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ Charter Last Modified: 2024-07-22 Current Status: Active Chairs: Carles Gomez Shwetha Bhandari Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke 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-19] (41 pages) - Transmission of IPv6 Packets over Near Field Communication [draft-ietf-6lo-nfc-22] (17 pages) - Transmission of IPv6 Packets over Short-Range Optical Wireless Communications [draft-ietf-6lo-owc-01] (16 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-07] (34 pages) - Transmission of IPv6 Packets over Power Line Communication (PLC) Networks [draft-ietf-6lo-plc-11] (20 pages) - IPv6 Neighbor Discovery Prefix Registration [draft-ietf-6lo-prefix-registration-04] (24 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-06] (42 pages) - Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo) [draft-ietf-6lo-use-cases-16] (24 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) RFC9428: Transmission of IPv6 Packets over Near Field Communication (17 pages) RFC9453: Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo) (24 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2024-07-31 Current Status: Active Chairs: Bob Hinden Jen Linkova 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: Jun 2021 - Investigate new Routing Headers, such as compact routing headers and safe replacement for RH0 Done - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Done - Determine way forward for ULA-C specification 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) - RFC 6296bis IPv6-to-IPv6 Network Prefix Translation [draft-bctb-6man-rfc6296-bis-02] (36 pages) - The IPv6 Compact Routing Header (CRH) [draft-bonica-6man-comp-rtg-hdr-31] (14 pages) - Deprecation Of The IPv6 Router Alert Option [draft-bonica-6man-deprecate-router-alert-02] (8 pages) - Preference for IPv6 ULAs over IPv4 addresses in RFC6724 [draft-buraglio-6man-rfc6724-update-03] (12 pages) - Clarification of IPv6 Address Assignment Policy [draft-carpenter-6man-addr-assign-02] (7 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) - Entering IPv6 Zone Identifiers in User Interfaces [draft-carpenter-6man-zone-ui-04] (9 pages) - IPv6 Node Requirements [draft-clw-rfc6434-bis-01] (34 pages) - Signalling DHCPv6 Prefix Delegation Availability to Hosts [draft-collink-6man-pio-pflag-03] (12 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) - Stub Router Flag in ICMPv6 Router Advertisement Messages [draft-hui-6man-stub-router-ra-flag-00] (4 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) - Clarification of IPv6 Address Assignment Policy [draft-ietf-6man-addr-assign-00] (7 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) - The IPv6 Compact Routing Header (CRH) [draft-ietf-6man-comp-rtg-hdr-10] (16 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) - Deprecation Of The IPv6 Router Alert Option [draft-ietf-6man-deprecate-router-alert-01] (9 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-15] (17 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-15] (11 pages) - Carrying Network Resource Partition (NRP) Information in IPv6 Extension Header [draft-ietf-6man-enhanced-vpn-vtn-id-07] (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 Processing Procedures [draft-ietf-6man-hbh-processing-20] (23 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-06] (16 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-06] (56 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) - 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) - Signalling DHCPv6 Prefix per Client Availability to Hosts [draft-ietf-6man-pio-pflag-09] (12 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) - Prioritizing known-local IPv6 ULAs through address selection policy [draft-ietf-6man-rfc6724-update-09] (17 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-rfc6874bis-09] (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 Segment Routing Header (SRH) [draft-ietf-6man-segment-routing-header-26] (27 pages) - SRv6 Segment Identifiers in the IPv6 Addressing Architecture [draft-ietf-6man-sids-06] (8 pages) - Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events [draft-ietf-6man-slaac-renum-07] (15 pages) - SNAC Router Flag in ICMPv6 Router Advertisement Messages [draft-ietf-6man-snac-router-ra-flag-01] (4 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) - Entering IPv6 Zone Identifiers in User Interfaces [draft-ietf-6man-zone-ui-03] (10 pages) - Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-02] (7 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) - IPv6 Addresses for Ad Hoc Networks [draft-templin-6man-mla-24] (12 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: 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) RFC9631: The IPv6 Compact Routing Header (CRH) (14 pages) Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- Charter Last Modified: 2023-11-10 Current Status: Active Chairs: Loganaden Velvindron Tim Hollebeek Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: https://mailarchive.ietf.org/arch/browse/ace/ Description of Working Group: The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is not considered to be constrained. Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized. The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). In addition to the ongoing maintenance work, the Working Group will extend the framework (originally designed to protect the exchange between single client and single RS) as needed for applicability to group communications. The initial focus will be on using (D)TLS and (Group) OSCORE as the underlying communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager. The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP (in coordination with the EMU WG), and standardize as needed. Goals and Milestones: Feb 2021 - Call for adoption of "Protecting EST Payloads with OSCORE" Jun 2021 - Submission to IESG of "CoAP Transport for CMPV2" (if adopted) Jul 2021 - Submission to the IESG of "An Authorization Information Format (AIF) for ACE" Jul 2021 - Submission to the IESG of "Protecting EST Payloads with OSCORE" Jul 2021 - Submission to the IESG of Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) Jul 2021 - Submission to the IESG of "Key Provisioning for Group Communication using ACE" Aug 2021 - Submission to the IESG of "EAP-based Authentication Service for CoAP" Sep 2021 - Submission to the IESG of "Key Management for OSCORE Groups in ACE" Dec 2021 - Submission to the IESG of "Admin Interface for the OSCORE Group Manager" Done - Adoption call for "CoAP Transport for CMPV2" Done - Submission to the IESG of "OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework" Done - Adoption call of "EAP-based Authentication Service for CoAP" Done - Submit DTLS Profile for ACE to the IESG for publication as a proposed standard Internet-Drafts: - An Authorization Information Format (AIF) for ACE [draft-bormann-core-ace-aif-09] (11 pages) - An architecture for authorization in constrained environments [draft-ietf-ace-actors-07] (31 pages) - An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-aif-07] (14 pages) - CBOR Web Token (CWT) [draft-ietf-ace-cbor-web-token-15] (25 pages) - Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol [draft-ietf-ace-cmpv2-coap-transport-10] (9 pages) - EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol [draft-ietf-ace-coap-est-18] (41 pages) - Protecting EST Payloads with OSCORE [draft-ietf-ace-coap-est-oscore-05] (24 pages) - Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) [draft-ietf-ace-cwt-proof-of-possession-11] (14 pages) - Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-dtls-authorize-18] (23 pages) - Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-edhoc-oscore-profile-05] (64 pages) - Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) [draft-ietf-ace-extend-dtls-authorize-07] (6 pages) - The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-group-oscore-profile-02] (48 pages) - Key Provisioning for Group Communication using ACE [draft-ietf-ace-key-groupcomm-19] (124 pages) - Key Management for OSCORE Groups in ACE [draft-ietf-ace-key-groupcomm-oscore-16] (104 pages) - Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-mqtt-tls-profile-17] (33 pages) - Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) [draft-ietf-ace-oauth-authz-46] (72 pages) - Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-oauth-params-16] (11 pages) - Admin Interface for the OSCORE Group Manager [draft-ietf-ace-oscore-gm-admin-12] (84 pages) - Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager [draft-ietf-ace-oscore-gm-admin-coral-02] (30 pages) - The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-oscore-profile-19] (28 pages) - Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-pubsub-profile-10] (56 pages) - Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-revoked-token-notification-08] (75 pages) - Use Cases for Authentication and Authorization in Constrained Environments [draft-ietf-ace-usecases-10] (30 pages) - EAP-based Authentication Service for CoAP [draft-ietf-ace-wg-coap-eap-10] (38 pages) - Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-workflow-and-params-02] (52 pages) - CoAP Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-palombini-ace-coap-pubsub-profile-06] (19 pages) - Key Provisioning for Group Communication using ACE [draft-palombini-ace-key-groupcomm-02] (17 pages) - MQTT-TLS profile of ACE [draft-sengul-ace-mqtt-tls-profile-04] (23 pages) - Key Management for OSCORE Groups in ACE [draft-tiloca-ace-oscoap-joining-05] (17 pages) - Admin Interface for the OSCORE Group Manager [draft-tiloca-ace-oscore-gm-admin-02] (29 pages) - EST over secure CoAP (EST-coaps) [draft-vanderstok-ace-coap-est-04] (30 pages) Requests for Comments: RFC7744: Use Cases for Authentication and Authorization in Constrained Environments (30 pages) RFC8392: CBOR Web Token (CWT) (25 pages) RFC8747: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) (14 pages) RFC9148: EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol (41 pages) RFC9200: Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) (72 pages) RFC9201: Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) (11 pages) RFC9202: Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) (23 pages) * Updates RFC9430 RFC9203: The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework (28 pages) RFC9237: An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) (14 pages) RFC9430: Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) (6 pages) RFC9431: Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework (33 pages) RFC9482: Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol (9 pages) RFC9594: Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE) (97 pages) Automated Certificate Management Environment (acme) --------------------------------------------------- Charter Last Modified: 2024-03-21 Current Status: Active Chairs: Tomofumi Okubo Yoav Nir Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: acme@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/acme Archive: https://mailarchive.ietf.org/arch/browse/acme/ Description of Working Group: Historically, issuance of certificates for Internet applications (e.g., web servers) has involved many manual identity validation steps by the certification authority (CA). The ACME WG will specify conventions for automated X.509 certificate management, including validation of control over an identifier, certificate issuance, certificate renewal, and certificate revocation. The initial focus of the ACME WG will be on domain name certificates (as used by web servers), but other uses of certificates can be considered as work progresses. ACME certificate management must allow the CA to verify, in an automated manner, that the party requesting a certificate has authority over the requested identifiers, including the subject and subject alternative names. The processing must also confirm that the requesting party has access to the private key that corresponds to the public key that will appear in the certificate. All of the processing must be done in a manner that is compatible with common service deployment environments, such as hosting environments. ACME certificate management must, in an automated manner, allow an authorized party to request revocation of a certificate. The ACME working group is specifying ways to automate certificate issuance, validation, revocation and renewal. The ACME working group is not reviewing or producing certificate policies or practices. The starting point for ACME WG discussions shall be draft-barnes-acme. Goals and Milestones: Apr 2024 - Delay-Tolerant Networking (DTN) extensions submitted to IESG Jul 2024 - End user client and code signing certificates extension submitted to IESG or abandoned Nov 2024 - Send draft-ietf-acme-dns-account-challenge to the IESG for standards track publication Nov 2024 - Send draft-ietf-acme-onion the IESG for standards track publication Nov 2024 - Send Renewal Information Extension to the IESG for standards track publication Done - Initial working group draft Done - Submit working group draft to IESG as Proposed Standard Done - TNAuthlist extension submitted to IESG Done - S/MIME extension submitted to IESG Done - Profile for delegated STAR certificates submitted to IESG Done - ACME integration with with EST, BRSKI and TEAP use cases submitted to IESG Internet-Drafts: - Automated Certificate Management Environment (ACME) Device Attestation Extension [draft-acme-device-attest-03] (13 pages) - Automatic Certificate Management Environment (ACME) [draft-ietf-acme-acme-18] (95 pages) - Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension [draft-ietf-acme-ari-05] (11 pages) - Automated Certificate Management Environment (ACME) Challenges Using an Authority Token [draft-ietf-acme-authority-token-09] (11 pages) - TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token [draft-ietf-acme-authority-token-tnauthlist-13] (15 pages) - Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding [draft-ietf-acme-caa-10] (11 pages) - ACME End User Client and Code Signing Certificates [draft-ietf-acme-client-07] (14 pages) - Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge [draft-ietf-acme-dns-account-01-01] (8 pages) - Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge [draft-ietf-acme-dns-account-challenge-01] (8 pages) - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension [draft-ietf-acme-dtnnodeid-14] (31 pages) - Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates [draft-ietf-acme-email-smime-14] (12 pages) - Extensions to Automatic Certificate Management Environment for email TLS [draft-ietf-acme-email-tls-05] (8 pages) - ACME Integrations for Device Certificate Enrollment [draft-ietf-acme-integrations-17] (23 pages) - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension [draft-ietf-acme-ip-08] (5 pages) - Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names [draft-ietf-acme-onion-03] (20 pages) - Automated Certificate Management Environment (ACME) Scoped DNS Challenges [draft-ietf-acme-scoped-dns-challenges-01] (12 pages) - ACME Identifiers and Challenges for VoIP Service Providers [draft-ietf-acme-service-provider-02] (9 pages) - Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) [draft-ietf-acme-star-11] (22 pages) - An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates [draft-ietf-acme-star-delegation-09] (42 pages) - Automated Certificate Management Environment (ACME) for Subdomains [draft-ietf-acme-subdomains-07] (20 pages) - ACME Identifiers and Challenges for Telephone Numbers [draft-ietf-acme-telephone-01] (8 pages) - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension [draft-ietf-acme-tls-alpn-07] (8 pages) - CA Account URI Binding for CAA Records [draft-landau-acme-caa-01] (8 pages) - ACME End User Client and Code Signing Certificates [draft-moriarty-acme-client-05] (14 pages) - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension [draft-sipos-acme-dtnnodeid-01] (16 pages) Requests for Comments: RFC8555: Automatic Certificate Management Environment (ACME) (95 pages) RFC8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (11 pages) RFC8737: Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension (8 pages) RFC8738: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension (5 pages) RFC8739: Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) (22 pages) RFC8823: Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates (12 pages) RFC9115: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates (42 pages) RFC9444: Automated Certificate Management Environment (ACME) for Subdomains (20 pages) RFC9447: Automated Certificate Management Environment (ACME) Challenges Using an Authority Token (11 pages) RFC9448: TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token (15 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] (16 pages) - DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) [draft-ietf-add-dnr-16] (23 pages) - Encrypted DNS Server Redirection [draft-ietf-add-encrypted-dns-server-redirection-00] (13 pages) - Requirements for Discovering Designated Resolvers [draft-ietf-add-requirements-00] (13 pages) - DNS Resolver Information [draft-ietf-add-resolver-info-13] (11 pages) - Establishing Local DNS Authority in Validated Split-Horizon Environments [draft-ietf-add-split-horizon-authority-14] (25 pages) - Service Binding Mapping for DNS Servers [draft-ietf-add-svcb-dns-09] (10 pages) - Handling Encrypted DNS Server Redirection [draft-jt-add-dns-server-redirection-04] (13 pages) - Discovery of Equivalent Encrypted Resolvers [draft-pauly-add-deer-00] (11 pages) - Delegated Credentials to Host Encrypted DNS Forwarders on CPEs [draft-reddy-add-delegated-credentials-03] (15 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) Requests for Comments: RFC9461: Service Binding Mapping for DNS Servers (10 pages) RFC9462: Discovery of Designated Resolvers (16 pages) RFC9463: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) (23 pages) RFC9606: DNS Resolver Information (10 pages) Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Sheng Jiang Toerless Eckert Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani 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-12] (41 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-10] (27 pages) - Discovery for BRSKI variations [draft-ietf-anima-brski-discovery-04] (44 pages) - BRSKI with Pledge in Responder Mode (BRSKI-PRM) [draft-ietf-anima-brski-prm-15] (113 pages) - Join Proxy for Bootstrapping of Constrained Network Elements [draft-ietf-anima-constrained-join-proxy-15] (26 pages) - Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) [draft-ietf-anima-constrained-voucher-25] (88 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-11] (23 pages) - JWS signed Voucher Artifacts for Bootstrapping Protocols [draft-ietf-anima-jws-voucher-12] (16 pages) - A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services [draft-ietf-anima-network-service-auto-deployment-06] (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-12] (43 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) 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 Orie Steele 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-12] (41 pages) - The 'sip-trunking-capability' Link Relation Type [draft-ietf-asap-siptrunkingcapability-link-05] (5 pages) - Automatic Peering for SIP Trunks [draft-kinamdar-dispatch-sip-auto-peer-05] (32 pages) Requests for Comments: RFC9409: The 'sip-trunking-capability' Link Relation Type (5 pages) 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 Orie Steele 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 In 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. After some exploratory work this resulted in a successful proposal to create the ASDF WG. As a common language for writing down these models, the Semantic Definition Format went through the IETF process, producing (draft-ietf-asdf-sdf). This SDF Base specification has now reached WG Consensus, to be published. SDF represents these models in JSON, enabling re-use of specification formats such as CDDL (RFC 8610) 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. SDF does not directly address data serialization. Instead, SDF focuses solely on modeling the structure and semantics of the data being exchanged. Consequently, the task of data serialization (including RPC semantics) is delegated to other standards, which are typically established by existing IoT SDOs. ## The ASDF Working Group The ASDF WG has developed SDF into a standards-track specification for thing interaction and data modeling. In the process of developing this specification, further functional requirements have emerged that can be addressed as extensions to the base SDF specification. The ASDF WG will liaise with OneDM and other relevant organizations. ASDF will extend SDF to cover the following standard track extensions: * modeling of links and relationships between elements of models, * modeling of non-affordance attribute (e.g., location) information/interaction for digital twins where the corresponding physical objects can be described with SDF, * additional SDF modeling mechanisms to enable property mapping between additional IoT SDOs' objects (including instances, and types), and * information/interaction modeling and protocol mappings to enable gateway interactions between IP and non-IP transports, with draft-brinckman-nipc-00 as a starting point. To increase ease of use, ASDF WG will also complete work on the proposal for a Compact Notation for SDF. As work evolves, ASDF will observe and may want to interact with IRTF Research Groups such as the Usable Formal Methods Research Group (UFMRG). ASDF will work with Thing-to-Thing Research Group (T2TRG) and its WISHI (Work on IoT Semantic/Hypermedia Interoperability, https://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: Sep 2024 - Submit to the IESG a standards track extension to SDF to describe sdfTyped links. Nov 2024 - Submit to the IESG a standards track extension to SDF to describe relationships between elements of models (beyond sdfRef). Jan 2025 - Submit to the IESG a standards track document on Compact Notation for SDF. May 2025 - Submit to the IESG a standards track specification on how to use SDF to communicate over IP with non-IP based devices. Aug 2025 - Submit to the IESG a standards track extension which allows for industry specific attributes to be associated with a common SDF model. Aug 2025 - Submit to the IESG a standards track specification on describing instances that are based on SDF models. Sep 2025 - Submit to the IESG a standards track extension to SDF to allow for inclusion of physical information and other non-affordance attribute information/interactions as an SDF attribute (e.g., to provide modeling support for digital twins). Internet-Drafts: - Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation [draft-bormann-asdf-sdf-compact-06] (8 pages) - Semantic Definition Format (SDF): Mapping files [draft-bormann-asdf-sdf-mapping-04] (11 pages) - An sdfType for Links [draft-bormann-asdf-sdftype-link-03] (5 pages) - An Application Layer Interface for Non-IP device control (NIPC) [draft-brinckman-nipc-01] (109 pages) - An Application Layer Interface for Non-IP device control (NIPC) [draft-ietf-asdf-nipc-01] (101 pages) - Semantic Definition Format (SDF) for Data and Interactions of Things [draft-ietf-asdf-sdf-18] (103 pages) - Extended information of Semantic Definition Format (SDF) for Digital Twin [draft-lee-asdf-digital-twin-03] (12 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: 2024-03-20 Current Status: Active Chairs: Dr. Bernard D. Aboba Jonathan Lennox Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker 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: - H.265 Profile for WebRTC [draft-aboba-avtcore-hevc-webrtc-02] (6 pages) - 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) - H.265 Profile for WebRTC [draft-ietf-avtcore-hevc-webrtc-03] (6 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] (8 pages) - RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution [draft-ietf-avtcore-rtcp-green-metadata-03] (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-07] (50 pages) - RTP Payload for Haptics [draft-ietf-avtcore-rtp-haptics-01] (21 pages) - RTP Payload Format for sub-codestream latency JPEG 2000 streaming [draft-ietf-avtcore-rtp-j2k-scl-03] (33 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 (RoQ) [draft-ietf-avtcore-rtp-over-quic-11] (75 pages) - Closing the RTP Payload Format Media Types IANA Registry [draft-ietf-avtcore-rtp-payload-registry-02] (5 pages) - RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec [draft-ietf-avtcore-rtp-scip-09] (18 pages) - Options for Securing RTP Sessions [draft-ietf-avtcore-rtp-security-options-10] (37 pages) - RTP Payload Format for SFrame [draft-ietf-avtcore-rtp-sframe-00] (5 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-06] (43 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-16] (16 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) * Updates RFC9443 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) RFC9443: Multiplexing Scheme Updates for QUIC (8 pages) RFC9584: RTP Payload Format for Essential Video Coding (EVC) (42 pages) RFC9607: RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec (15 pages) Babel routing protocol (babel) ------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Donald E. Eastlake 3rd Russ White Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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-05] (8 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-07] (14 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) * Updates RFC9467 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) RFC9467: Relaxed Packet Counter Verification for Babel MAC Authentication (8 pages) RFC9616: Delay-Based Metric Extension for the Babel Routing Protocol (13 pages) BGP Enabled ServiceS (bess) --------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Matthew Bocci Stephane Litkowski Zhaohui (Jeffrey) Zhang Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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-08] (31 pages) - Controller Based BGP Multicast Signaling [draft-ietf-bess-bgp-multicast-controller-13] (30 pages) - BGP Usage for SD-WAN Overlay Networks [draft-ietf-bess-bgp-sdwan-usage-23] (30 pages) - SRv6 Argument Signaling for BGP Services [draft-ietf-bess-bgp-srv6-args-01] (13 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-05] (13 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-04] (14 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-07] (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) - Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks [draft-ietf-bess-evpn-dpath-01] (16 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-10] (16 pages) - EVPN control plane for Geneve [draft-ietf-bess-evpn-geneve-08] (11 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 Support for L3 Fast Convergence and Aliasing/Backup Path [draft-ietf-bess-evpn-ip-aliasing-01] (22 pages) - EVPN Interworking with IPVPN [draft-ietf-bess-evpn-ipvpn-interworking-11] (33 pages) - Extended Mobility Procedures for EVPN-IRB [draft-ietf-bess-evpn-irb-extended-mobility-17] (26 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-ietf-bess-evpn-irb-mcast-11] (80 pages) - EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols [draft-ietf-bess-evpn-l2gw-proto-04] (13 pages) - Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) [draft-ietf-bess-evpn-lsp-ping-11] (17 pages) - EVPN Port-Active Redundancy Mode [draft-ietf-bess-evpn-mh-pa-10] (13 pages) - BGP EVPN Multi-Homing Extensions for Split Horizon Filtering [draft-ietf-bess-evpn-mh-split-horizon-11] (20 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-07] (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-10] (11 pages) - Preference-based EVPN DF Election [draft-ietf-bess-evpn-pref-df-13] (20 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-10] (33 pages) - Weighted Multi-Path Procedures for EVPN Multi-Homing [draft-ietf-bess-evpn-unequal-lb-22] (22 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-15] (24 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) - EVPN-VPWS Seamless Integration with L2VPN VPWS [draft-ietf-bess-evpn-vpws-seamless-00] (18 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-06] (15 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-14] (17 pages) - Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication [draft-ietf-bess-mvpn-evpn-sr-p2mp-09] (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 C-MAC-Flush [draft-ietf-bess-pbb-evpn-isid-cmacflush-09] (13 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-10] (72 pages) - Secure EVPN [draft-ietf-bess-secure-evpn-00] (37 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) - IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI [draft-ietf-bess-v4-v6-pe-all-safi-01] (54 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) - EVPN Support for L3 Fast Convergence and Aliasing/Backup Path [draft-sajassi-bess-evpn-ip-aliasing-09] (20 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-02] (25 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 * Updates RFC9573 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) RFC9489: Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) (17 pages) RFC9541: Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN) (11 pages) RFC9572: Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures (19 pages) RFC9573: MVPN/EVPN Tunnel Aggregation with Common Labels (14 pages) RFC9574: Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs) (28 pages) RFC9625: EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding (63 pages) Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2022-07-23 Current Status: Active Chairs: Jeffrey Haas Reshad Rahman Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde 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-11] (14 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-18] (24 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) - Meticulous Keyed ISAAC for BFD Authentication [draft-ietf-bfd-secure-sequence-numbers-16] (20 pages) - BFD Stability [draft-ietf-bfd-stability-15] (21 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-10] (12 pages) - Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications [draft-ietf-bfd-unsolicited-16] (16 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-15] (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) RFC9468: Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications (16 pages) Bit Indexed Explicit Replication (bier) --------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Greg Shepherd Tony Przygienda Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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 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-07] (9 pages) - BGP Link-State extensions for BIER [draft-ietf-bier-bgp-ls-bier-ext-17] (11 pages) - Supporting BIER in IPv6 Networks (BIERin6) [draft-ietf-bier-bierin6-10] (10 pages) - YANG Data Model for BIER Protocol [draft-ietf-bier-bier-yang-09] (19 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-14] (15 pages) - BIER Fast ReRoute [draft-ietf-bier-frr-04] (31 pages) - BGP Extensions for BIER [draft-ietf-bier-idr-extensions-11] (13 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-03] (13 pages) - BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols [draft-ietf-bier-mld-08] (17 pages) - M-LDP Signaling Through BIER Core [draft-ietf-bier-mldp-signaling-over-bier-03] (10 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-03] (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-15] (7 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-17] (9 pages) - BIER Penultimate Hop Popping [draft-ietf-bier-php-11] (8 pages) - PIM Signaling Through BIER Core [draft-ietf-bier-pim-signaling-12] (13 pages) - BIER Ping and Trace [draft-ietf-bier-ping-14] (30 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-15] (9 pages) - BIER Prefix Redistribute [draft-ietf-bier-prefix-redistribute-07] (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-06] (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-10] (8 pages) - OSPF Extensions for BIER-TE [draft-ietf-bier-te-ospf-10] (14 pages) - OSPFv3 Extensions for BIER-TE [draft-ietf-bier-te-ospfv3-08] (6 pages) - Tethering A BIER Router To A BIER incapable Router [draft-ietf-bier-tether-05] (9 pages) - A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-yang-07] (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) RFC9624: EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index Explicit Replication (BIER) (13 pages) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2023-07-26 Current Status: Active Chairs: Giuseppe Fioccola Sarah Banks Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari 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: Dec 2023 - Draft on General VNF Benchmarking Automation to IESG Review Dec 2023 - Considerations for Benchmarking Network Virtualization Platforms to IESG Review Jan 2024 - Draft on Selecting and Applying Model(s) for Benchmarking to IESG Review Sep 2024 - Benchmarking for Stateful NATxy Gateways using RFC4814 Pseudorandom port numbers to IESG review Jan 2025 - Draft on Multiple Loss Ratio Search 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: - Considerations for Benchmarking Network Performance in Containerized Infrastructures [draft-dcn-bmwg-containerized-infra-13] (25 pages) - 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-09] (31 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) - Considerations for Benchmarking Network Performance in Containerized Infrastructures [draft-ietf-bmwg-containerized-infra-01] (27 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-11] (27 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-07] (50 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-04] (26 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 Methodology for Segment Routing [draft-ietf-bmwg-sr-bench-meth-01] (27 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) BPF/eBPF (bpf) -------------- Charter Last Modified: 2023-06-27 Current Status: Active Chairs: David Vernet Suresh Krishnan Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Tech Advisors: Alexei Starovoitov Christoph Hellwig Dave Thaler Mailing Lists: General Discussion: bpf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bpf Archive: https://mailarchive.ietf.org/arch/browse/bpf/ Description of Working Group: eBPF (which is no longer an acronym for anything), also commonly referred to as BPF, is a technology with origins in the Linux kernel that can run untrusted programs in a privileged context such as the operating system kernel. BPF is increasingly being used beyond just the Linux kernel, with implementations in network interface cards, Microsoft Windows, etc. The BPF working group is initially tasked with documenting the existing state of the BPF ecosystem, and creating a clear process for extensions, including initial extensions that are widely useful and showcase the process. The working group will not adopt work focused on new versions or extensions until all documents required to capture the existing goals, particularly those in the bullets below, have completed IESG approval. The working group will produce one or more documents on the following work item topics (with intended document status annotations, e.g. [PS] Proposed Standard and [I] Informational): * [PS] the BPF instruction set architecture (ISA) that defines the instructions and low-level virtual machine for BPF programs, * [I] verifier expectations and building blocks for allowing safe execution of untrusted BPF programs, * [PS] the BPF Type Format (BTF) that defines debug information and introspection capabilities for BPF programs, * [I] one or more documents that recommend conventions and guidelines for producing portable BPF program binaries, * [PS] cross-platform map types allowing native data structure access from BPF programs, * [PS] cross-platform helper functions, e.g., for manipulation of maps, * [PS] cross-platform BPF program types that define the higher level execution environment for BPF programs, and * [I] an architecture and framework document. The BPF working group shall actively engage the BPF Foundation steering committee and the broader implementation community to ensure inclusion in the IETF's consensus-driven process. The working group is intended to only work on cross-platform aspects of BPF that are useful to the wider internet community and are not otherwise operating system or platform specific. Goals and Milestones: Mar 2024 - eBPF Instruction Set Specification [wg adoption] Internet-Drafts: - BPF Instruction Set Architecture (ISA) [draft-ietf-bpf-isa-04] (46 pages) No Requests for Comments Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Bron Gondwana Daniel Migault Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele 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: Apr 2024 - Submit subscription upgrade document to IESG Apr 2024 - Submit task draft to IESG Jul 2024 - Submit vpoll document to IESG for publication Nov 2024 - Submit JSCalendar mapping document to IESG for publication Nov 2024 - Submit calendar series document to IESG for publication Done - Submit JSON Contact document to IESG on hold - Adopt a draft updating iTIP 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-10] (33 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-17] (87 pages) - JSContact: Converting from and to vCard [draft-ietf-calext-jscontact-vcard-15] (65 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-11] (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-12] (22 pages) - VPOLL: Consensus Scheduling Component for iCalendar [draft-ietf-calext-vpoll-06] (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) RFC9553: JSContact: A JSON Representation of Contact Data (73 pages) RFC9554: vCard Format Extensions for JSContact (21 pages) RFC9555: JSContact: Converting from and to vCard (60 pages) Computing-Aware Traffic Steering (cats) --------------------------------------- Charter Last Modified: 2024-07-24 Current Status: Active Chairs: Adrian Farrel Mohamed Boucadair Peng Liu Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde 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: Mar 2025 - Adopt document describing CATS metrics Nov 2025 - Submit the CATS Framework and Architecture document to the IESG for publication as Informational Mar 2026 - Submit document describing CATS metrics to the IESG for publication as Informational Done - Adopt the CATS Problem Statement, Use Cases, Gap Analysis, and Requirements documents Done - Adopt the CATS Framework and Architecture document Internet-Drafts: - A Framework for Computing-Aware Traffic Steering (CATS) [draft-ietf-cats-framework-02] (25 pages) - Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements [draft-ietf-cats-usecases-requirements-03] (34 pages) - A Framework for Computing-Aware Traffic Steering (CATS) [draft-ldbc-cats-framework-06] (25 pages) - Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements [draft-yao-cats-ps-usecases-03] (24 pages) No Requests for Comments Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Barry Leiba Christian Amsüss Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele 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: Jun 2027 - Updated version of CDDL, replacing RFC 8610 and its updates, submitted to IESG Internet-Drafts: - Additional Control Operators for CDDL [draft-bormann-cbor-cddl-control-02] (10 pages) - CDDL Module Structure [draft-bormann-cbor-cddl-modules-00] (12 pages) - More Control Operators for CDDL [draft-bormann-cbor-cddl-more-control-01] (11 pages) - CBOR Common Deterministic Encoding (CDE) [draft-bormann-cbor-cde-00] (9 pages) - Application-Oriented Literals in CBOR Extended Diagnostic Notation [draft-bormann-cbor-edn-literals-02] (8 pages) - External References to Values in CBOR Diagnostic Notation (EDN) [draft-bormann-cbor-e-ref-00] (9 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) - Updates to the CDDL grammar of RFC 8610 [draft-bormann-cbor-update-8610-grammar-00] (12 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) - CDDL Module Structure [draft-ietf-cbor-cddl-modules-03] (14 pages) - More Control Operators for CDDL [draft-ietf-cbor-cddl-more-control-06] (13 pages) - CBOR Common Deterministic Encoding (CDE) [draft-ietf-cbor-cde-05] (15 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-ietf-cbor-date-tag-07] (6 pages) - External References to Values in CBOR Diagnostic Notation (EDN) [draft-ietf-cbor-edn-e-ref-00] (10 pages) - CBOR Extended Diagnostic Notation (EDN) [draft-ietf-cbor-edn-literals-12] (42 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-13] (30 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-12] (24 pages) - Updates to the CDDL grammar of RFC 8610 [draft-ietf-cbor-update-8610-grammar-06] (15 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) RFC9581: Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period (21 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: Jim Guichard John Scudder Gunter Van de Velde 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 WSON tunnel YANG model to IESG for review 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 - Submit L1CSM YANG model to IESG for review Aug 2022 - First version of client tunnel YANG model working group draft 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 WSON IV info 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 - 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 - Post strawman WG goals and charter Done - Build appropriate design teams Done - Submit WG document defining path setup portions of common control plane protocol Done - Submit WG document defining common measurement plane protocol Done - Submit LMP MIB to IESG Done - Submit ASON signaling requirements doc to IESG Done - Submit protection & restoration documents to IESG Done - Submit GMPLS MIBs 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 - First version WG I-D MPLS to GMPLS migration strategies Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF 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 - First version WG I-D Requirements for Multi-Layer and Multi-Region Networks 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 Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - Submit GMPLS signaling in support of Call Management I-D for IESG review Done - Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done - First version WG I-D for Protocol solutions for MLN/MRN Done - First version of WG I-D for OSPF-TE/GMPLS MIB module Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions 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 GMPLS OAM Requirements Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review 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 - Submit VCAT/LCAS with GMPLS for IESG review Done - Submit TE MIB module IESG review Done - First version of LMP Negotiation Working Group draft Done - First version of G.709 enhancements framework Working Group drafts Done - First version of Working Group draft providing Control Plane Framework for MPLS-TP Done - First version of OAM configuration solutions Working Group draft Done - Submit Lambda labels draft for IESG review Done - Submit WSON framework draft for IESG review 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 LMP Negotiation for IESG review Done - Submit OAM configuration framework 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 last OAM configuration solutions for IESG review Done - Submit first set of OAM configuration solutions for IESG review Done - Submit WSON signaling related draft for IESG review Done - Submit WSON routing related drafts 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-01] (12 pages) - A YANG Data Model for Transport Network Client Signals [draft-ietf-ccamp-client-signal-yang-13] (68 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-09] (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-11] (25 pages) - A YANG Data Model for Ethernet TE Topology [draft-ietf-ccamp-eth-client-te-topo-yang-06] (72 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-04] (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-03] (41 pages) - A YANG Data Model for Flexi-Grid Optical Networks [draft-ietf-ccamp-flexigrid-yang-17] (70 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-01] (12 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-26] (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) - Common YANG Data Types for Layer 1 Networks [draft-ietf-ccamp-layer1-types-18] (55 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-12] (45 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-02] (43 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-16] (148 pages) - YANG Data Models for requesting Path Computation in WDM Optical Networks [draft-ietf-ccamp-optical-path-computation-yang-04] (31 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-03] (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-19] (87 pages) - OTN Tunnel YANG Model [draft-ietf-ccamp-otn-tunnel-model-21] (49 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) - Common YANG Data Types for Layer 0 Networks [draft-ietf-ccamp-rfc9093-bis-11] (73 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-17] (92 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-ietf-ccamp-transport-nbi-use-cases-01] (28 pages) - Conveying Transceiver-Related Information within RSVP-TE Signaling [draft-ietf-ccamp-tsvmode-signaling-00] (14 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 YANG Data Model for WDM Tunnels [draft-ietf-ccamp-wdm-tunnel-yang-02] (75 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-09] (43 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-07] (33 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) Congestion Control Working Group (ccwg) --------------------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Eric Kinnear Reese Enghardt Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: ccwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccwg Archive: https://mailarchive.ietf.org/arch/browse/ccwg/ Description of Working Group: RFC 5033 describes a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed. Congestion control algorithm proponents now often have the opportunity to test and deploy at scale without IETF review. The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond. There is more interest in specialized use cases such as data centers and real-time protocols. Finally, the community has gained much more experience with indications of congestion beyond packet loss. The Congestion Control Working Group will analyze some of the impediments to congestion control work occurring in the IETF and can generalize transports from TCP to all of the relevant transport protocols. This will inform a revision of RFC 5033 (5033bis) that encourages IETF review of congestion control proposals and standardization of mature congestion control algorithms. The congestion control expertise in the working group also makes it a natural venue to take on other work related to indications of congestion such as delay, queuing algorithms, rate pacing, multipath, interaction with other layers, among others. In particular, it can address congestion control algorithms with empirical evidence of safety (for example - avoiding congestion collapse) and stated intent to deploy by major implementations. The working group is intended to be a home for such work, and it is chartered to adopt proposals in this space if such congestion control algorithms are presented before or after the completion of the primary deliverable i.e. 5033bis. The group will coordinate closely with other relevant working and research groups, including ICCRG, TCPM, QUIC, and TSVWG. Documents in CCWG will remain as transport protocol agnostic as possible, but they may have short specific instructions, such as header options or parameter formats, for one or more protocols. Documents that are wholly specific to mechanisms in a single protocol will remain in the maintenance working group for that protocol. Algorithms proposed for Experimental status, in consultation with ICCRG, based on an assessment of their maturity and likelihood of near-term wide-scale deployment, are in scope. Publication of Informational RFCs analyzing the published standard congestion control algorithms is within CCWG scope. However, it is not chartered to document the state of congestion control in the Internet, including assessments of whether any particular implementation complies with existing standards. Other venues, such as the IRTF, may be more appropriate for publishing such documents. Goals and Milestones: Jun 2024 - Submit 5033bis to IESG for publication. Dec 2024 - Submit an Informational RFC analyzing the published standard congestion controllers Internet-Drafts: - Specifying New Congestion Control Algorithms [draft-ietf-ccwg-rfc5033bis-08] (28 pages) No Requests for Comments Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2024-03-11 Current Status: Active Chairs: Chris Lemmons Kevin J. Ma Sanjay Mishra Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport 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: Dec 2024 - Submit specification of CDNI Control Triggers Interface Extensions to IESG as Proposed Standard Dec 2024 - Submit specification of CDNI Edge Control Metadata to IESG as Proposed Standard Dec 2024 - Submit specification of CDNI Protected Secrets Metadata to IESG as Proposed Standard Dec 2024 - Submit specification of CDNI Cache Control Metadata to IESG as Proposed Standard Apr 2025 - 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 Done - Submit specification of CDNI Extensions for HTTPS ACME STAR Delegation to IESG as Proposed Standard Done - Submit specification of CDNI Extensions for HTTPS TLS Subcert Delegation to IESG as Proposed Standard Done - Submit specification of CDNI Extensions for Capacity Capability Advertisement Internet-Drafts: - CDNI SVA Request Routing Extensions [draft-finkelman-cdni-rr-sva-extensions-01] (11 pages) - Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union [draft-ietf-cdni-additional-footprint-types-12] (11 pages) - CDNI Cache Control Metadata [draft-ietf-cdni-cache-control-metadata-02] (15 pages) - CDNI Capacity Capability Advertisement Extensions [draft-ietf-cdni-capacity-insights-extensions-07] (16 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition [draft-ietf-cdni-ci-triggers-rfc8007bis-14] (101 pages) - CDNI Client Access Control Metadata [draft-ietf-cdni-client-access-control-metadata-00] (16 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-05] (11 pages) - CDNI Edge Control Metadata [draft-ietf-cdni-edge-control-metadata-02] (14 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-12] (13 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) - CDNI Logging Extensions [draft-ietf-cdni-logging-extensions-00] (54 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 Delivery Network Interconnection (CDNI) Named Footprints [draft-ietf-cdni-named-footprints-00] (19 pages) - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-08] (32 pages) - CDNI Protected Secrets Metadata [draft-ietf-cdni-protected-secrets-metadata-02] (18 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) * Updates RFC9388 RFC8804: Content Delivery Network Interconnection (CDNI) Request Routing Extensions (17 pages) RFC9246: URI Signing for Content Delivery Network Interconnection (CDNI) (37 pages) RFC9388: Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union (11 pages) RFC9538: Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment (10 pages) Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Michael Richardson Spencer Dawkins Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele 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: Jul 2022 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Dec 2024 - Submit Matroska Media Container Tag Specifications to IESG (Standards Track) Jun 2025 - Submit specification for Matroska Media Container Codec Specifications 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 Done - Submit specification for Matroska container to IESG (Standards Track) Done - Submit specification for FLAC audio codec to IESG (Standards Track) Internet-Drafts: - Matroska Media Container Chapter Codecs Specifications [draft-ietf-cellar-chapter-codecs-05] (8 pages) - Matroska Media Container Codec Specifications [draft-ietf-cellar-codec-13] (56 pages) - Matroska Media Container Control Track Specifications [draft-ietf-cellar-control-05] (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-22] (57 pages) - Free Lossless Audio Codec [draft-ietf-cellar-flac-14] (96 pages) - Matroska Media Container Format Specification [draft-ietf-cellar-matroska-23] (179 pages) - Matroska Media Container Tag Specifications [draft-ietf-cellar-tags-13] (30 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) Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2024-07-09 Current Status: Active Chairs: Carsten Bormann Jaime Jimenez Marco Tiloca Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport 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: Aug 2024 - Secure group communication for CoAP submitted to IESG for PS Aug 2024 - Group communication for CoAP bis submitted to IESG for PS Sep 2024 - DNS over CoAP (DoC) submitted to IESG for PS Nov 2024 - Constrained Resource Identifiers submitted to IESG for PS Nov 2024 - Conditional Attributes for Constrained RESTful Environments submitted to IESG for PS Mar 2025 - Publish-subscribe architecture for CoAP submitted to IESG for PS Mar 2025 - Management over CoAP (COMI) submitted to IESG for PS Nov 2025 - Dynamic Resource Linking for Constrained RESTful Environments submitted to IESG as Informational Nov 2025 - Management over CoAP (YANG Library) submitted to IESG for PS Mar 2026 - Constrained RESTful Application Language (CoRAL) submitted to IESG for PS Dec 2026 - CoRE Interfaces submitted to IESG as Informational 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 - Patch and Fetch Methods for CoAP submitted to IESG for PS Done - Representing CoRE Link Collections in JSON submitted to IESG Done - CoAP over TCP, TLS, and WebSockets submitted to IESG for PS Done - CBOR Encoding of Data Modeled with YANG 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 - CoRE Resource Directory submitted to IESG for PS Done - Concise Problem Details For CoAP APIs submitted to IESG for PS Done - Creation of IANA registry for CoRE target attributes submitted to IESG as Informational RFC Done - Using EDHOC with CoAP and OSCORE 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-04] (21 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) - ALPN ID Specification for CoAP over DTLS [draft-ietf-core-coap-dtls-alpn-00] (5 pages) - Constrained Application Protocol (CoAP) Performance Measurement Option [draft-ietf-core-coap-pm-02] (16 pages) - A publish-subscribe architecture for the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-pubsub-14] (33 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-18] (48 pages) - Conditional Attributes for Constrained RESTful Environments [draft-ietf-core-conditional-attributes-07] (25 pages) - The Constrained RESTful Application Language (CoRAL) [draft-ietf-core-coral-06] (47 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-07] (20 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-11] (89 pages) - Proxy Operations for CoAP Group Communication [draft-ietf-core-groupcomm-proxy-02] (60 pages) - Constrained Application Protocol (CoAP) Hop-Limit Option [draft-ietf-core-hop-limit-07] (8 pages) - Constrained Resource Identifiers [draft-ietf-core-href-16] (59 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-09] (95 pages) - OSCORE-capable Proxies [draft-ietf-core-oscore-capable-proxies-02] (55 pages) - Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) [draft-ietf-core-oscore-edhoc-11] (33 pages) - Group Object Security for Constrained RESTful Environments (Group OSCORE) [draft-ietf-core-oscore-groupcomm-22] (114 pages) - Identifier Update for OSCORE [draft-ietf-core-oscore-id-update-01] (25 pages) - Key Usage Limits for OSCORE [draft-ietf-core-oscore-key-limits-03] (14 pages) - Key Update for OSCORE (KUDOS) [draft-ietf-core-oscore-key-update-08] (62 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-24] (50 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-06] (8 pages) - "Too Many Requests" Response Code for the Constrained Application Protocol [draft-ietf-core-too-many-reqs-06] (6 pages) - CoAP Transport Indication [draft-ietf-core-transport-indication-06] (46 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) - ALPN ID Specification for CoAP over DTLS [draft-lenders-core-coap-dtls-svcb-01] (5 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) RFC9423: Constrained RESTful Environments (CoRE) Target Attributes Registry (8 pages) RFC9595: YANG Schema Item iDentifier (YANG SID) (44 pages) CBOR Object Signing and Encryption (cose) ----------------------------------------- Charter Last Modified: 2022-03-23 Current Status: Active Chairs: Ivaylo Petrov Matthew A. Miller Michael B. Jones Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: cose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: https://mailarchive.ietf.org/arch/browse/cose/ Description of Working Group: CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to create and process signatures, message authentication codes, and encryption using Concise Binary Object Representation (CBOR, RFC 7049) for serialization. COSE additionally describes a representation for cryptographic keys. COSE has been picked up and is being used both by a number of groups within the IETF (i.e., ACE, CORE, ANIMA, 6TiSCH and SUIT) and outside the IETF (i.e., W3C and FIDO). There are a number of implementations, both open source and private, now in existence. The specification has advanced to STD status. The COSE working group will deal with two types of documents going forward: 1. Documents that describe the use of cryptographic algorithms in COSE. 2. Documents which describe additional attributes for COSE. The WG will evaluate, and potentially adopt, documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms. Potential candidates would include those algorithms that have been evaluated by the CFRG and algorithms which have gone through a public review and evaluation process such as was done for the NIST SHA-3 algorithms. Potential candidates would not include national-standards-based algorithms that have not gone through a similar public review process. The WG will produce documents for new attributes only if they are in the list of deliverables below. A re-charter will be required to expand that list. The WG is expected as part of normal processing to review and comment on attributes that are not in charter but are of general public interest. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs, active CFRG or IETF WG documents, or algorithms which have been positively reviewed by the CFRG. The working group will coordinate its progress with the ACE, SUIT and CORE working groups to ensure that it is fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded, in consultation with the responsible Area Director. The WG currently has two work items: 1. One or more documents describing the proper use of algorithms. These algorithms must meet the requirements outlined above. 2. A CBOR encoding of the certificate profile defined in RFC 5280. It is expected that the encoding works with RFC 7925 and takes into consideration any updates in draft-ietf-uta-tls13-iot-profile-00. The encoding may also include other important IoT certificate profiles like IEEE 802.1AR. The main objective is to define a method of encoding current X.509 certificates that meet a specific profile into a smaller format. This encoding is invertible, so they can be expanded and normal X.509 certificate processing can be used. The data structures used for such encoding of X.509 certificates are expected to produce a compact encoding for certificate information, and are not necessarily tied specifically to X.509 certificates. Accordingly, a secondary objective is to reuse these data structures to produce a natively signed CBOR certificate encoding; such a structure is relevant in situations where DER parsing and the machinery to convert between CBOR and DER encodings are unnecessary overhead, such as embedded implementations. The possibility of a joint certificate artifact, conveyed in CBOR encoding but including signatures over both the CBOR and DER encodings, may be explored. CBOR encoding of other X.509 certificate related data structures may also be specified to support relevant functions such as revocation: Certificate Revocation List (RFC 5280) or OSCP Request/Response (RFC 6960); or certificate enrollment: Certificate Signing Request (RFC 2986). draft-mattsson-cose-cbor-cert-compress is expected to be a good starting point for this work. The working group will collaborate and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and validate the requirements and solution. Goals and Milestones: Jun 2021 - Adopt draft for compressed certificate encoding as a Working Group item Dec 2021 - Submit draft for compressed certificate encoding to the IESG for publication Internet-Drafts: - CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC [draft-ietf-cose-aes-ctr-and-cbc-06] (10 pages) - Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE [draft-ietf-cose-bls-key-representations-05] (22 pages) - CBOR Encoded X.509 Certificates (C509 Certificates) [draft-ietf-cose-cbor-encoded-cert-11] (73 pages) - CBOR Object Signing and Encryption (COSE): Countersignatures [draft-ietf-cose-countersign-10] (18 pages) - CBOR Web Token (CWT) Claims in COSE Headers [draft-ietf-cose-cwt-claims-in-headers-10] (8 pages) - ML-DSA for JOSE and COSE [draft-ietf-cose-dilithium-03] (13 pages) - JOSE and COSE Encoding for Falcon [draft-ietf-cose-falcon-01] (15 pages) - CBOR Object Signing and Encryption (COSE): Hash Algorithms [draft-ietf-cose-hash-algs-09] (9 pages) - COSE Hash Envelope [draft-ietf-cose-hash-envelope-00] (8 pages) - Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-hash-sig-09] (15 pages) - Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-hpke-09] (24 pages) - CBOR Object Signing and Encryption (COSE) Key Thumbprint [draft-ietf-cose-key-thumbprint-06] (13 pages) - COSE Receipts [draft-ietf-cose-merkle-tree-proofs-05] (24 pages) - CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-msg-24] (121 pages) - JOSE and COSE Encoding for Post-Quantum Signatures [draft-ietf-cose-post-quantum-signatures-01] (60 pages) - CBOR Object Signing and Encryption (COSE): Initial Algorithms [draft-ietf-cose-rfc8152bis-algs-12] (41 pages) - CBOR Object Signing and Encryption (COSE): Structures and Process [draft-ietf-cose-rfc8152bis-struct-15] (66 pages) - SLH-DSA for JOSE and COSE [draft-ietf-cose-sphincs-plus-04] (13 pages) - COSE Header parameter for RFC 3161 Time-Stamp Tokens [draft-ietf-cose-tsa-tst-header-parameter-03] (10 pages) - COSE "typ" (type) Header Parameter [draft-ietf-cose-typ-header-parameter-05] (6 pages) - CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms [draft-ietf-cose-webauthn-algorithms-08] (10 pages) - CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates [draft-ietf-cose-x509-09] (12 pages) - CBOR Encoded Message Syntax [draft-schaad-cose-msg-01] (48 pages) Requests for Comments: RFC8152: CBOR Object Signing and Encryption (COSE) (121 pages) * Obsoletes RFC9052 * Obsoletes RFC9053 RFC8778: Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) (15 pages) RFC8812: CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms (10 pages) RFC9052: CBOR Object Signing and Encryption (COSE): Structures and Process (66 pages) * Updates RFC9338 RFC9053: CBOR Object Signing and Encryption (COSE): Initial Algorithms (41 pages) RFC9054: CBOR Object Signing and Encryption (COSE): Hash Algorithms (9 pages) RFC9338: CBOR Object Signing and Encryption (COSE): Countersignatures (18 pages) RFC9360: CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates (12 pages) RFC9459: CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC (10 pages) RFC9596: CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter (5 pages) RFC9597: CBOR Web Token (CWT) Claims in COSE Headers (6 pages) DANE Authentication for Network Clients Everywhere (dance) ---------------------------------------------------------- Charter Last Modified: 2023-03-28 Current Status: Active Chairs: Joey Salazar Wes Hardaker Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: dance@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dance Archive: https://mailarchive.ietf.org/arch/browse/dance/ Description of Working Group: # Objective The DANE Authentication for Network Clients Everywhere (DANCE) WG seeks to extend DANE (RFC 6698) to encompass TLS client authentication using certificates or Raw Public Keys (RPK). # Problem Statement The process of establishing trust in public-key-authenticated identity typically involves the use of a Public Key Infrastructure (PKI), and a shared PKI root of trust between the parties exchanging public keys. A Certification Authority (CA) is one example of a root of trust for a PKI, which can be then used for establishing trust in certified public keys. The DNS namespace, together with DNSSEC, forms the most widely-recognized namespace and authenticated lookup mechanism on the Internet. DANE built on this authenticated lookup mechanism to enable public key-based TLS authentication which is resilient to impersonation, but only for TLS server identities. However, the DANE WG did not define authentication for TLS client identities. In response to the challenges related to ambiguity between identically named identities issued by different CAs, application owners frequently choose to onboard client identities to a single private PKI with a limited CA set that is specific to that vertical. This creates a silo effect where different parts of large deployments can not communicate. Examples of where DANCE could be useful includes SMTP transport client authentication, authentication of DNS authoritative server to server zone file transfers over TLS, authentication to DNS recursive servers, and Internet of Things (IoT) device identification. # Scope of work DANCE will specify the DANE-enabled TLS client authentication use cases and an architecture describing the primary components and interaction patterns. DANCE will define how DNS DANE records will represent client identities for TLS connections. DANCE will coordinate with the TLS working group to define any TLS protocol updates required to support client authentication using DANE. The DANCE scope of work will be initially limited to just TLS client authentication. Future work may include using client identifiers for other tasks including object security, or authenticating to other protocols. # Deliverables: * DANCE architecture and use cases (e.g., IoT, SMTP client, authentication to DNS services) document (9 months) * DANE client authentication and publication practices (6 months after architecture) * A TLS extension to indicate DANE identification capability and the client's DANE identity name (6 months after architecture) Goals and Milestones: Jul 2022 - DANCE architecture and use cases to WGLC (informational) Jan 2023 - DANE client authentication and publication practice to WGLC (PS) Jan 2023 - TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS) Internet-Drafts: - TLS Client Authentication via DANE TLSA records [draft-huque-dane-client-cert-08] (9 pages) - TLS Extension for DANE Client Identity [draft-huque-tls-dane-clientid-06] (5 pages) - An Architecture for DNS-Bound Client and Sender Identities [draft-ietf-dance-architecture-06] (20 pages) - TLS Client Authentication via DANE TLSA records [draft-ietf-dance-client-auth-05] (10 pages) - TLS Extension for DANE Client Identity [draft-ietf-dance-tls-clientid-03] (5 pages) - An Architecture for DNS-Bound Client and Sender Identities [draft-wilson-dance-architecture-02] (14 pages) No Requests for Comments DNS Delegation (deleg) ---------------------- Charter Last Modified: 2024-06-26 Current Status: Active Chairs: Brian Haberman Duane Wessels Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Warren Kumari Secretary: Tommy Jensen Mailing Lists: General Discussion: dd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dd Archive: https://mailarchive.ietf.org/arch/browse/dd/ Description of Working Group: # Background and Problem Space The DNS protocol has limited ability for authoritative servers to signal their capabilities to recursive resolvers. In part, this stems from the lack of a mechanism for parents (often registries) to specify additional information about child delegations (often registrants) beyond NS, DS, and glue records. Further complicating matters is the similar lack of a mechanism for a registrant to signal that the operation of a delegation point is being outsourced to a different operator, leaving a challenge when operators need to update parental information that is only in the control of the child. Data is often out of synchronization between parents and children, which causes significant operational problems. # Objective and Scope To address these challenges, the DELEG working group will first document the requirements for adding a new DNS signaling mechanism that allows parents to return additional DNS delegation information about their children. This includes the requirement for the new mechanism to interoperate with the existing DNS and to not break DNS resolvers and clients that are not aware of it. In addition, this document could also list the other types of information not available today that might be provided over a designed signaling mechanism. The first use cases for the working group will be new DNS authoritative signaling mechanisms for alternative DNS transports, and delegation aliasing (where the parent returns a pointer to the service provider that will then return the needed delegation information). The working group should also consider how well different solutions can be deployed, and should study possible consequences of deploying alternative delegation mechanisms. The working group will then define the semantics of a new DNS signaling mechanism, taking future extensibility into account. The working group will specify extensions to the DNS. The initial version of the requirements document should have broad general consensus and must be adopted by the WG before work on the solution documents begins. - The WG will coordinate closely with other WGs, including DNSOP, ADD, and other working groups and directorates as appropriate. This is especially true for WG adoption and Last Calls. # Deliverables - A document listing the requirements for a new signaling mechanism allowing parents to return additional information when communicating about a delegated child. This is expected to be published as an informational RFC. - A specification defining the new delegation information distribution mechanism. The WG will carry out an operational impact assessment and include corresponding operational and deployment considerations sections in the specification. The specification will include a concept of operations that describes how both current and future systems will interact in an Internet-wide interoperable way. This is expected to be published as a standards-track RFC. - A specification for how to use the new delegation information to perform aliasing of delegation information. This is expected to be published as a standards-track RFC. - A specification for facilitating the use of additional transports for DNS. This is expected to be published as a standards-track RFC. Goals and Milestones: Dec 2024 - A document listing the requirements for a new signaling mechanism allowing parents to return additional information when communicating about a delegated child. Feb 2025 - A specification defining the new delegation information distribution mechanism. Jun 2025 - A specification for how to use the new delegation information to perform aliasing of delegation information. Dec 2025 - A specification for facilitating the use of additional transports for DNS. Internet-Drafts: - Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements [draft-ietf-deleg-requirements-00] (6 pages) - Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements [draft-wirelela-deleg-requirements-01] (7 pages) No Requests for Comments Deterministic Networking (detnet) --------------------------------- Charter Last Modified: 2024-04-26 Current Status: Active Chairs: János Farkas Lou Berger Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Tech Advisor: David Black Secretary: Eve Schooler 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 reordering, latency, loss, and packet delay variation (jitter), and high reliability. DetNet solutions apply to both wireless and wired networks. 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 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 encompass 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 of 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 specify 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 of 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 of the protocol(s) that 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. DetNets including Wireless: This work will define how DetNet solutions operate over networks that include wired and wireless network technologies. The work may include providing DetNet reliability and availability for scheduled wireless segments and other wireless 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. This work will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability. 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: Mar 2024 - Adopt first Enhanced DetNet Data Plane solution document Mar 2024 - Submit RAW OAM document for publication as Informational Mar 2024 - Submit RAW architecture document for publication as Informational Jul 2024 - Submit controller plane framework for publication as Informational Jul 2024 - Submit Requirements for Scaling Deterministic Networks for publication as Informational Sep 2024 - Submit RAW framework document for publication as informational Dec 2024 - Submit first Enhanced DetNet Data Plane solution document for publication as Standards Track 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-07] (19 pages) - Deterministic Networking (DetNet) Data Plane Framework [draft-ietf-detnet-data-plane-framework-06] (22 pages) - Dataplane Enhancement Taxonomy [draft-ietf-detnet-dataplane-taxonomy-01] (19 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-13] (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-15] (14 pages) - Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP [draft-ietf-detnet-mpls-over-ip-preof-11] (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-11] (16 pages) - Deterministic Networking (DetNet): Packet Ordering Function [draft-ietf-detnet-pof-11] (12 pages) - Deterministic Networking Problem Statement [draft-ietf-detnet-problem-statement-09] (11 pages) - Requirements for Reliable Wireless Industrial Services [draft-ietf-detnet-raw-industrial-req-01] (24 pages) - Requirements for Scaling Deterministic Networks [draft-ietf-detnet-scaling-requirements-06] (22 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-20] (136 pages) - Reliable and Available Wireless Architecture [draft-ietf-raw-architecture-20] (43 pages) - Reliable and Available Wireless Framework [draft-ietf-raw-framework-02] (18 pages) - Reliable and Available Wireless Technologies [draft-ietf-raw-technologies-10] (66 pages) - Dataplane Enhancement Taxonomy [draft-joung-detnet-taxonomy-dataplane-01] (14 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) RFC9546: Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane (12 pages) RFC9550: Deterministic Networking (DetNet): Packet Ordering Function (11 pages) RFC9551: Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) (14 pages) RFC9566: Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP (10 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: Dec 2024 - Advance DHCPv6 RFC to Internet Standard Jul 2025 - 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 IPv6-Only-Preferred Option for DHCP Done - Adopt DHCPv6 Prefix Delegating relay Done - WGLC Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Done - WGLC DHCPv6 Prefix Delegating relay Done - WGLC IPv6-Only-Preferred Option for DHCP Done - WGLC draft-ietf-dhc-dhcpv6-yang Done - WGLC for Registering Self-generated IPv6 Addresses using DHCPv6 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 using DHCPv6 [draft-ietf-dhc-addr-notification-13] (19 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-05] (141 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: 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) * Updates RFC9445 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) Dispatch (dispatch) ------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Jim Fenton Shuping Peng Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy 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-07-25 Current Status: Active Chairs: Barry Leiba Seth Blank Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele 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) - Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting [draft-ietf-dmarc-aggregate-reporting-19] (29 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-33] (77 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-11] (14 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) Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2023-07-04 Current Status: Active Chairs: 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: Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' 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) - Architecture Discussion on SRv6 Mobile User plane [draft-ietf-dmm-srv6mob-arch-00] (8 pages) - Segment Routing over IPv6 for the Mobile User Plane [draft-ietf-dmm-srv6-mobile-uplane-24] (29 pages) - Mobility aware Transport Network Slicing for 5G [draft-ietf-dmm-tn-aware-mobility-10] (20 pages) - Architecture Discussion on SRv6 Mobile User plane [draft-kohno-dmm-srv6mob-arch-07] (8 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) - Mobile User Plane Evolution [draft-zzhang-dmm-mup-evolution-09] (23 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) RFC9433: Segment Routing over IPv6 for the Mobile User Plane (29 pages) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2024-06-05 Current Status: Active Chairs: Benno Overeinder Suzanne Woolf Tim Wicinski Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari 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) - DNSSEC Trust Anchor Publication for the Root Zone [draft-bash-rfc7958bis-01] (11 pages) - In the DNS, QDCOUNT is (usually) One [draft-bellis-dnsop-qdcount-is-one-01] (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) - Remove deprecated GOST algorithms from active use within DNSSEC [draft-hardaker-dnsop-must-not-ecc-gost-02] (5 pages) - Remove SHA-1 from active use within DNSSEC [draft-hardaker-dnsop-must-not-sha1-03] (5 pages) - DNSSEC Cryptographic Algorithm Recommendation Update Process [draft-hardaker-dnsop-rfc8624-bis-04] (12 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) - Greasing Protocol Extension Points in the DNS [draft-huque-dnsop-grease-02] (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] (7 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) - IP Fragmentation Avoidance in DNS over UDP [draft-ietf-dnsop-avoid-fragmentation-18] (14 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-08] (19 pages) - Consistency for CDS/CDNSKEY and CSYNC is Mandatory [draft-ietf-dnsop-cds-consistency-04] (13 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-04] (13 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] (16 pages) - DNS Error Reporting [draft-ietf-dnsop-dns-error-reporting-08] (12 pages) - DNSSEC automation [draft-ietf-dnsop-dnssec-automation-02] (11 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-11] (18 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) - 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 Control Validation using DNS [draft-ietf-dnsop-domain-verification-techniques-05] (25 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) - Generalized DNS Notifications [draft-ietf-dnsop-generalized-notify-02] (18 pages) - DNS Glue Requirements in Referral Responses [draft-ietf-dnsop-glue-is-not-optional-09] (9 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) - 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) - Remove deprecated GOST algorithms from active use within DNSSEC [draft-ietf-dnsop-must-not-ecc-gost-00] (5 pages) - Remove SHA-1 from active use within DNSSEC [draft-ietf-dnsop-must-not-sha1-00] (5 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-07] (13 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) - In the DNS, QDCOUNT is (usually) One [draft-ietf-dnsop-qdcount-is-one-04] (7 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-14] (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) - DNSSEC Trust Anchor Publication for the Root Zone [draft-ietf-dnsop-rfc7958bis-06] (14 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-rfc8109bis-07] (11 pages) - DNS Terminology [draft-ietf-dnsop-rfc8499bis-10] (57 pages) - DNSSEC Cryptographic Algorithm Recommendation Update Process [draft-ietf-dnsop-rfc8624-bis-00] (12 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-09] (23 pages) - Special-Use Domain Names Problem Statement [draft-ietf-dnsop-sutld-ps-08] (25 pages) - Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC [draft-ietf-dnsop-svcb-dane-04] (13 pages) - Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) [draft-ietf-dnsop-svcb-https-12] (47 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 DNS Zone Version (ZONEVERSION) Option [draft-ietf-dnsop-zoneversion-11] (14 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) - Consistency for CDS/CDNSKEY and CSYNC is Mandatory [draft-thomassen-dnsop-cds-consistency-03] (10 pages) - Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator [draft-thomassen-dnsop-dnssec-bootstrapping-03] (14 pages) - Generalized DNS Notifications [draft-thomassen-dnsop-generalized-dns-notify-02] (17 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: 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) * Updates RFC9520 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 * Updates RFC9615 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) * Updates RFC9615 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) * Obsoletes RFC9499 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) RFC9432: DNS Catalog Zones (16 pages) RFC9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (47 pages) RFC9471: DNS Glue Requirements in Referral Responses (9 pages) RFC9476: The .alt Special-Use Top-Level Domain (7 pages) RFC9499: DNS Terminology (45 pages) RFC9520: Negative Caching of DNS Resolution Failures (14 pages) RFC9567: DNS Error Reporting (11 pages) RFC9615: Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator (12 pages) RFC9619: In the DNS, QDCOUNT Is (Usually) One (7 pages) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- Charter Last Modified: 2023-09-25 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: - DNS Multiple QTYPEs [draft-bellis-dnsext-multi-qtypes-08] (7 pages) - 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-04] (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) - DNS Multiple QTYPEs [draft-ietf-dnssd-multi-qtypes-04] (8 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-25] (41 pages) - Automatic Replication of DNS-SD Service Registration Protocol Zones [draft-ietf-dnssd-srp-replication-02] (26 pages) - An EDNS(0) option to negotiate Leases on DNS Updates [draft-ietf-dnssd-update-lease-08] (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) DNS PRIVate Exchange (dprive) ----------------------------- Charter Last Modified: 2023-10-24 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-13] (34 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: 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) RFC9539: Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS (24 pages) Drone Remote ID Protocol (drip) ------------------------------- Charter Last Modified: 2023-11-09 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: Mar 2024 - Submit DRIP Registries to the IESG Done - Requirements and architecture drafts adopted by the WG Done - Solution space documents adopted by the WG Done - Requirements and architecture drafts in the WGLC Done - Submit Requirements Document to the IESG Done - Submit DRIP Architecture Document to the IESG Done - Submit DRIP UAS Remote ID to the IESG Done - Submit DRIP Authentication Formats to the IESG Done - Adopt a support document for operationalizing DRIP (Informational; not necessarily for publication as RFC) 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] (28 pages) - DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID [draft-ietf-drip-auth-49] (48 pages) - The DRIP DET public Key Infrastructure [draft-ietf-drip-dki-01] (44 pages) - DRIP Entity Tag (DET) Identity Management Architecture [draft-ietf-drip-registries-17] (46 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) - The DRIP DET public Key Infrastructure [draft-moskowitz-drip-dki-09] (44 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) RFC9434: Drone Remote Identification Protocol (DRIP) Architecture (28 pages) RFC9575: DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID) (43 pages) Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ Charter Last Modified: 2024-03-19 Current Status: Active Chairs: Edward J. Birrane Rick Taylor Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Secretary: Adam Wiethuechter Mailing Lists: General Discussion: dtn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: https://mailarchive.ietf.org/arch/browse/dtn/ Description of Working Group: The Delay/Disruption Tolerant Networking (DTN) Working Group specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The Working Group has published the Bundle Protocol v7 (BPv7), corresponding Bundle Protocol Security protocol (BPSec) and an interoperable Security Context, and the TCP Convergence Layer specifications as standards track RFCs. Multiple independent implementations exist for these technologies in both space and terrestrial environments, and the technology is now used in production by governments and commercial organizations world-wide. This Working Group now focuses on the further work relevant to the area of Delay/Disruption Tolerant Networking, dividing work items into 3 broad categories: * An architecture for Naming, Addressing and Forwarding The Bundle Protocol v7 defines an encoding of Names for use in DTN, but the detailed semantics have not been specified. The Working Group will define a common architecture for the delay/disruption tolerant assignment of names, and the late-binding of such names during bundle forwarding to end-points within a DTN. This architecture will define a model for the forwarding process of a Bundle Process Agent, providing an informational reference point for further specifications. The Working Group charter intentionally excludes topics related to Routing in DTNs. This does not preclude discussion of the subject, in coordination with the Routing Area, but no Working Group documents will be adopted under this charter. * The definition of an architecture and protocols in the areas of Operations, Administration, and Management (OAM), and Key Management Current DTN deployments rely on the use of pre-placed keys and configuration or bespoke tooling, and there is a growing demand for standards to improve the automation and reliability of DTN management. Existing IETF protocols for OAM and Key Management generally rely on a bi-directional end-to-end path between devices, and in Delay/Disruption Tolerant Networks (DTNs) such paths rarely exist. To enable OAM and Key Management in such cases, there may be a need to standardize an architecture supporting alternative methods and their supporting protocols and data models. The Working Group will liaise with relevant experts in the OPS Area to discover if there are existing standards that meet, or may be extended to meet, the DTN use-cases before standardizing new protocols. There is also believed to be cross-over between the use-cases for OAM and Key Management in DTNs and the use-cases in Mobile Ad-hoc Networks (MANETs); to this end the Working Group will coordinate with the MANET Working Group to explore potential synergies and avoid duplication of effort. * Extensions to and best practices for existing protocols Extensions to the Bundle Protocol to enable reliability signalling, tunnelling and Quality of Service indication are needed for the operational deployment of Delay/Disruption Tolerant Networks, and these capabilities will be standardized by the Working Group. Additional extensions to the Bundle Protocol, additional Security Context definitions for BPSec, and new Convergence Layer adapters will be considered on a case-by-case basis by the working group. The Working Group will also document best practices learned from existing deployments. The Working Group will coordinate with other IETF Working Groups, especially in the Security, Routing, Operation and Management Areas, to ensure the quality of peer review, the avoidance of duplication of effort, and alignment with specifications produced in other Working Groups. Goals and Milestones: Jul 2022 - Delay-Tolerant Management Architecture Mar 2023 - Naming and Addressing Architecture Document Mar 2023 - Bundle Progress Signalling Jul 2023 - Bundle-in-Bundle Encapsulation Jul 2023 - QoS/Flow Extension Block Nov 2023 - Neighbor/Peer Discovery Protocol Specification Mar 2024 - Delay-Tolerant Management Protocols Jul 2024 - Key Management Protocol Internet-Drafts: - DTNMA Application Management Model (AMM) and Data Models [draft-ietf-dtn-adm-00] (121 pages) - DTNMA Application Data Model (ADM) YANG Syntax [draft-ietf-dtn-adm-yang-01] (80 pages) - Asynchronous Management Architecture [draft-ietf-dtn-ama-03] (33 pages) - DTNMA Application Management Model (AMM) and Data Models [draft-ietf-dtn-amm-01] (71 pages) - DTNMA Application Resource Identifier (ARI) [draft-ietf-dtn-ari-02] (49 pages) - Bundle-in-Bundle Encapsulation [draft-ietf-dtn-bibect-04] (16 pages) - Bundle Protocol Version 7 [draft-ietf-dtn-bpbis-31] (53 pages) - Bundle Protocol Security (BPSec) [draft-ietf-dtn-bpsec-27] (35 pages) - DTN Bundle Protocol Security (BPSec) COSE Context [draft-ietf-dtn-bpsec-cose-04] (46 pages) - Default Security Contexts for Bundle Protocol Security (BPSec) [draft-ietf-dtn-bpsec-default-sc-11] (51 pages) - BPSec Default Security Contexts [draft-ietf-dtn-bpsec-interop-sc-02] (22 pages) - Bundle Protocol Version 7 Administrative Record Types Registry [draft-ietf-dtn-bpv7-admin-iana-03] (5 pages) - DTN Management Architecture [draft-ietf-dtn-dtnma-14] (59 pages) - Update to the ipn URI scheme [draft-ietf-dtn-ipn-update-13] (31 pages) - Minimal TCP Convergence-Layer Protocol [draft-ietf-dtn-mtcpcl-01] (8 pages) - Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 [draft-ietf-dtn-tcpclv4-28] (62 pages) Requests for Comments: RFC9171: Bundle Protocol Version 7 (53 pages) RFC9172: Bundle Protocol Security (BPSec) (35 pages) RFC9173: Default Security Contexts for Bundle Protocol Security (BPSec) (51 pages) RFC9174: Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 (62 pages) Detecting Unwanted Location Trackers (dult) ------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Erica Olsen Sean Turner Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: unwanted-trackers@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/unwanted-trackers Archive: https://mailarchive.ietf.org/arch/browse/unwanted-trackers/ Description of Working Group: ## Background Location-tracking accessories provide numerous benefits to users (e.g., such as being able to find where they left their keys), but can also have security and privacy implications if used for malicious purposes. These accessories can be misused to track another person’s location without their knowledge. Three major subsystems of an accessory tracking system, i) crowd-sourcing network, ii) unwanted tracker detection, and iii) alerting, providing information about the accessory, and enabling the non-owner to find it, have interfaces that are relevant to unwanted tracking. These interfaces include: enrolling in the network, broadcasting an accessory’s presence, non-owner interface for querying information from the accessory, performing non-owner actions such as play sound, querying assets and disablement instructions, querying limited owner information, disabling the accessory, and detection and exclusion of nonconformant accessories. To address the threat of unwanted tracking, accessory manufacturers have developed independent solutions for protecting users from unwanted tracking. However, this requires users to know about the threat of unwanted tracking, download multiple apps, and constantly be checking for the threat of unwanted tracking. In order to build a scalable solution for detecting unwanted tracking, trackers require a consistent protocol and set of behaviors that will enable protection from unwanted tracking using any tracker. ## Goals The goal of the DULT WG is to standardize an application protocol for information exchange between location-tracking accessories and nearby devices, along with actions that these accessories and devices should take once unwanted tracking is detected. This protocol is intended to protect people against being unknowingly tracked. The intent of this WG is to make it easier for arbitrary devices to detect unwanted tracking by these accessories. The protocols and interactions between devices may be limited to certain states or modes, such as the accessory being separated from a paired/owner device. The working group will define privacy and security properties of its solution, including privacy and security protections for accessory owners when accessories are used appropriately, and evaluate the tradeoffs. The mechanisms specified by the WG will be designed to not create new vectors for user tracking. The WG's specified mechanisms and protocol design will be guided by an intent to: * Minimize hardware changes needed in tracking accessories to implement this protocol; and * Not preclude adoption by manufacturers of larger devices whose primary purpose is not location tracking, but have location tracking capabilities (e.g., headphones, bicycle, smartphone) ## Program of Work The WG is expected to: 1. Document the current state of the tracker accessory platforms and how these technologies work (with informational document(s)) 2. Develop a standards-track protocol ("DULT protocol") between tracking accessories and nearby devices, which will: * Specify requirements and a baseline algorithm for determination of unwanted tracking * Specify complete message formats for accessories to advertise their presence to nearby devices, for one or more underlying transports (e.g., Bluetooth, Near Field Communication, etc.) * Allow nearby devices to trigger behavior on an unwanted tracking accessory to aid in determining its physical location * Allow nearby devices to fetch additional information about a tracker accessory, including such things as tracker image asset(s) and physical disablement instructions * Define privacy and security requirements for all messages used for advertisement, interactions with crowdsourcing networks, and owners of accessories 3. Develop standards-track guidance that accessory manufacturers can implement to deter malicious use of tracking accessories and support the implementation of the WG-specified protocol which will * Include physical security considerations, such as user impact when device has been physically modified to diminish detectability and/or findability * Include considerations for protecting people that don't have a device capable of running a platform-based unwanted tracking detection system 4. Develop standards-track guidance for non-owner device platforms necessary to support implementation of the DULT protocol. The standards-track guidance described above will include mechanisms to ensure that devices that do not correctly implement or adhere to the DULT protocol can be detected and excluded from being trackable via crowdsourced location networks. These mechanisms will include considerations for addressing legacy trackers that cannot update to the DULT protocol. The WG will work with gender-based violence experts throughout development of the protocol. Additionally, before publishing the protocol the WG will: * Carry out a threat analysis and security analysis * Gather implementation experience The WG will not define requirements for interactions between accessory manufacturers and law enforcement. The focus of the WG will be on solving the use case of detecting small and not easily-discoverable accessories, supporting any functionality that is necessary for identifying and recognizing such accessories. Since most of the existing tracking accessories use Bluetooth, the DULT WG will coordinate as needed with the Bluetooth SIG and IETF 6lo WG. ### Milestones * By July 2025 submit an informational document about the state of tracker accessory platforms and how they work for publication * By July 2025 submit a standards document defining the protocol to detect and interact with unwanted tracker accessories for publication Goals and Milestones: Jul 2025 - Submit an informational document about the state of tracker accessory platforms and how they work for publication Jul 2025 - Submit a standards document defining the protocol to detect and interact with unwanted tracker accessories for publication Internet-Drafts: - Draft DULT Threat Model [draft-delano-dult-threat-model-00] (14 pages) - Detecting Unwanted Location Trackers Accessory Protocol [draft-ledvina-dult-accessory-protocol-00] (37 pages) No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2023-09-08 Current Status: Active Chairs: Allison Mankin Randall Gellens Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele 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-09] (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: 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) Revision of core Email specifications (emailcore) ------------------------------------------------- Charter Last Modified: 2023-07-06 Current Status: Active Chairs: Alexey Melnikov Todd Herr Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele 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: May 2024 - Submit RFC5322bis to the IESG for publication at Internet Standard Jul 2024 - Submit RFC5321bis to the IESG for publication at Internet Standard Nov 2024 - Submit Applicability Statment to the IESG for publication at Proposed Standard Internet-Drafts: - Applicability Statement for IETF Core Email Protocols [draft-ietf-emailcore-as-11] (19 pages) - Simple Mail Transfer Protocol [draft-ietf-emailcore-rfc5321bis-31] (114 pages) - Internet Message Format [draft-ietf-emailcore-rfc5322bis-12] (59 pages) No Requests for Comments EAP Method Update (emu) ----------------------- Charter Last Modified: 2022-07-25 Current Status: Active Chairs: Joseph A. Salowey Peter E. Yee Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/browse/emu Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC3748] is a network access authentication framework used, for instance, in VPN and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Several EAP methods have been developed at the IETF and support for EAP exists in a broad set of devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol specification and the development of several standards track EAP methods. EAP methods are generally based on existing security technologies such as Transport Layer Security (TLS) and mobile network Authentication and Key Agreement (AKA). Our understanding of security threats is continuously evolving. This has driven the evolution of several of these underlying technologies. As an example, IETF has standardized a new and improved version of TLS in RFC 8446. The group will therefore provide guidance and update EAP method specifications where necessary to enable the use of new versions of these underlying technologies. Out-of-band (OOB) refers to a separate communication channel independent of the primary in-band channel over which the actual network communication takes place. OOB channels are now used for authentication in a variety of protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users are accustomed to tapping NFC or scanning QR codes. However, EAP currently does not have any standard methods that support authentication based on OOB channels. The group will therefore work on an EAP method where authentication is based on an out-of-band channel between the peer and the server. EAP authentication is based on credentials available on the peer and the server. However, some EAP methods use credentials that are time or domain limited (such as EAP-POTP), and there may be a need for creating long term credentials for re-authenticating the peer in a more general context. The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials. EDHOC (Ephemeral Diffie-Hellman Over COSE) is a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys that is suitable in constrained environments in which many of the existing EAP methods are not a good fit. EDHOC offers the useful properties of mutual authentication, forward secrecy, and identity protection. The group will accordingly produce a specification for an EAP method incorporating the EDHOC mechanism (RFC9628). While TLS-based EAP mechanisms provide strong channel protections, if the client does not authenticate and validate the server's credentials properly (possibly owing to a lack of provisioned information necessary to undertake that validation), an EAP mechanism running over TLS that relies on passwords is vulnerable to client credential theft, much the same as password authentication over plain TLS is. The FIDO Alliance and the W3C have developed a passwordless authentication scheme known as FIDO2, which combines elements of the W3C's WebAuthn and FIDO's CTAP standards. The group will devise an EAP method suitable for use with passwordless authentication schemes such as the CTAP2 version of FIDO2. In summary, the working group shall produce the following documents: * An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). This document will update the security considerations relating to EAP-TLS, document the implications of using new vs. old TLS versions. It will add any recently gained new knowledge on vulnerabilities and discuss the possible implications of pervasive surveillance. * Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. Provide guidance or update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on errata found in published specifications (such as EAP-TEAP). * Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently discovered shortcoming in the original RFCs. * Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance. * Gather experience regarding the use of large certificates and long certificate chains in the context of TLS based EAP methods, as some implementations and access networks may limit the number of EAP packet exchanges that can be handled. Document operational recommendations or other mitigation strategies to avoid issues. * Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself should be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light. * Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials. * Develop an EAP method for use in constrained environments that wish to leverage the EDHOC key exchange mechanism. * Devise a passwordless EAP method that can incorporate use of CTAP2 or other similar authentication mechanism. The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for work on TLS based EAP methods), the FIDO Alliance, and the 3GPP security architecture group (for EAP-AKA' work). Goals and Milestones: May 2024 - WG adopts initial draft on an EAP method for use of EDHOC May 2024 - WG adopts initial draft on an EAP method for using FIDO CTAP2 May 2024 - WG adopts an ancillary draft on use of the eap.arpa domain for use in other EAP methods Internet-Drafts: - Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS) [draft-arkko-eap-aka-pfs-04] (25 pages) - Nimble out-of-band authentication for EAP (EAP-NOOB) [draft-aura-eap-noob-08] (62 pages) - The eap.arpa domain and EAP provisioning [draft-dekok-emu-eap-arpa-01] (14 pages) - EAP Session-Id Derivation [draft-dekok-emu-eap-session-id-01] (9 pages) - TLS-based EAP types and TLS 1.3 [draft-dekok-emu-tls-eap-types-02] (10 pages) - Bootstrapped TLS Authentication [draft-friel-tls-eap-dpp-05] (10 pages) - Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) [draft-ietf-emu-aka-pfs-12] (34 pages) - Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) [draft-ietf-emu-bootstrapped-tls-06] (13 pages) - Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods [draft-ietf-emu-chbind-16] (31 pages) - Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding [draft-ietf-emu-crypto-bind-04] (19 pages) - The eap.arpa domain and EAP provisioning [draft-ietf-emu-eap-arpa-02] (18 pages) - Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC) [draft-ietf-emu-eap-edhoc-01] (23 pages) - EAP-FIDO [draft-ietf-emu-eap-fido-00] (38 pages) - Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method [draft-ietf-emu-eap-gpsk-17] (38 pages) - Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [draft-ietf-emu-eap-noob-06] (51 pages) - Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) [draft-ietf-emu-eap-session-id-07] (7 pages) - EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 [draft-ietf-emu-eap-tls13-21] (31 pages) - Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods [draft-ietf-emu-eaptlscert-08] (12 pages) - Tunnel Extensible Authentication Protocol (TEAP) Version 1 [draft-ietf-emu-eap-tunnel-method-10] (101 pages) - Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method [draft-ietf-emu-eaptunnel-req-09] (23 pages) - Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') [draft-ietf-emu-rfc5448bis-10] (40 pages) - Tunnel Extensible Authentication Protocol (TEAP) Version 1 [draft-ietf-emu-rfc7170bis-19] (110 pages) - TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 [draft-ietf-emu-tls-eap-types-13] (19 pages) - Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC) [draft-ingles-eap-edhoc-05] (22 pages) - EAP-FIDO [draft-janfred-eap-fido-02] (36 pages) - Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods [draft-ms-emu-eaptlscert-03] (10 pages) - The EAP-TLS Authentication Protocol [draft-simon-emu-rfc2716bis-13] (34 pages) Requests for Comments: RFC5216: The EAP-TLS Authentication Protocol (34 pages) * Updates RFC8996 * Updates RFC9190 RFC5433: Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method (38 pages) RFC6677: Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods (31 pages) RFC6678: Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method (23 pages) RFC7029: Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding (19 pages) RFC7170: Tunnel Extensible Authentication Protocol (TEAP) Version 1 (101 pages) * Updates RFC9427 RFC8940: Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) (7 pages) RFC9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') (40 pages) RFC9140: Nimble Out-of-Band Authentication for EAP (EAP-NOOB) (51 pages) RFC9190: EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 (31 pages) RFC9191: Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods (12 pages) RFC9427: TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 (19 pages) Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2024-07-09 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Secretary: Kenneth Murchison 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: Dec 2023 - Submit IMAP UIDONLY draft to IESG Apr 2024 - Submit process imip draft to IESG Apr 2024 - Adopt a document for EAI with Sieve Apr 2024 - Submit Sieve Calendar processing draft to IESG Apr 2024 - Adopt a document for RFC6855-bis Jun 2024 - Submit Sieve EAI to IESG 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 Done - Adopt a document for returning metadata in list responses Done - Submit MESSAGELIMIT draft Done - Submit IMAP INPROGRESS draft to IESG Done - Submit LIST-METADATA draft to IESG 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) - IMAP Support for UTF-8 [draft-ietf-extra-6855bis-03] (12 pages) - Snoozing Email with IMAP, JMAP, and Sieve [draft-ietf-extra-email-snooze-00] (21 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 Response Code for Command Progress Notifications. [draft-ietf-extra-imap-inprogress-06] (7 pages) - IMAP4 Extension for Returning Mailbox METADATA in Extended LIST [draft-ietf-extra-imap-list-metadata-05] (7 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-10] (12 pages) - IMAP Extension for Object Identifiers [draft-ietf-extra-imap-objectid-08] (16 pages) - IMAP PARTIAL Extension for Paged SEARCH and FETCH [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-08] (9 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-09] (7 pages) - Sieve Email Filtering: Extension for Processing Calendar Attachments [draft-ietf-extra-processimip-09] (15 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) RFC9122: IANA Registry for Sieve Actions (9 pages) RFC9208: IMAP QUOTA Extension (19 pages) RFC9394: IMAP PARTIAL Extension for Paged SEARCH and FETCH (10 pages) RFC9585: IMAP Response Code for Command Progress Notifications (6 pages) RFC9586: IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only (9 pages) RFC9590: IMAP Extension for Returning Mailbox METADATA in Extended LIS (6 pages) General Area Dispatch (gendispatch) ----------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Martin Vigoureux Shuping Peng General Area Directors: Roman Danyliw General Area Advisor: Roman Danyliw 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 Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Leif Johansson Yaron Sheffer Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: txauth@ietf.org To Subscribe: ​https://www.ietf.org/mailman/listinfo/txauth Archive: https://mailarchive.ietf.org/arch/browse/txauth/ Description of Working Group: This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the Authorization Server (AS) as part of its request. This protocol enables an authorizing party to delegate access to client software to use a Resource Server (RS) with this token. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0, which is initiated by the client redirecting the user’s browser). The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. The client and AS will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels. The group will define interoperability for this protocol between different parties, including - client and authorization server; - client and resource server; and - authorization server and resource server. The group will seek to minimize assumptions about the form of client applications, allowing for: - Fine-grained specification of access - Approval of AS attestation to identifiers and other identity claims - Approval of access to multiple resources and APIs in a single interaction - Multiple access tokens in a single request and response - AS-directed dispatch of access tokens to the appropriate RS - Separation between the party authorizing access and the party operating the client requesting access The group will define extension points for this protocol to allow for flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of possession - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information related to the identifiers and identity assertions about the client - Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process Additionally, the group will provide mechanisms for management of the protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Data model for granted access and mechanisms for the AS and RS to communicate the granted access model Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes. The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as CoAP when doing so does not conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures - Conveyance mechanisms for identifiers and assertions - Guidelines for use of protocol extension points - (if needed) Guidelines on migration paths, implementation, and operations Where possible, the group will seek to make use of tools to guide and inform the standardization process including formal analysis, architecture documents, and use case documents. These artifacts will not be considered as working group milestones or deliverables. The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with external organizations, such as the OpenID Foundation, as appropriate. Goals and Milestones: Dec 2023 - Resource Server protocol to Working Group Last Call Done - Core delegation protocol to Working Group Last Call Internet-Drafts: - Grant Negotiation and Authorization Protocol [draft-ietf-gnap-core-protocol-20] (234 pages) - Grant Negotiation and Authorization Protocol Resource Server Connections [draft-ietf-gnap-resource-servers-08] (44 pages) No Requests for Comments Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Chris Morrow Job Snijders Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari 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) - Updated BGP Operations and Security [draft-fiebig-grow-bgpopsecupd-00] (46 pages) - BMP Loc-RIB: Peer address [draft-francois-grow-bmp-loc-peer-04] (9 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-03] (6 pages) - AS Path Prepending [draft-ietf-grow-as-path-prepending-13] (13 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) - Updated BGP Operations and Security [draft-ietf-grow-bgpopsecupd-03] (8 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) - Definition For New BMP Statistics Type [draft-ietf-grow-bmp-bgp-rib-stats-03] (10 pages) - Support for Local RIB in the BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-local-rib-13] (14 pages) - BMP Extension for Path Status TLV [draft-ietf-grow-bmp-path-marking-tlv-01] (11 pages) - BMP Peer Up Message Namespace [draft-ietf-grow-bmp-peer-up-04] (8 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-ietf-grow-bmp-registries-change-04] (3 pages) - Logging of routing events in BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-rel-02] (9 pages) - TCP-AO Protection for BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-tcp-ao-00] (5 pages) - BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages [draft-ietf-grow-bmp-tlv-14] (12 pages) - Support for Enterprise-specific TLVs in the BGP Monitoring Protocol [draft-ietf-grow-bmp-tlv-ebit-05] (7 pages) - BMP YANG Module [draft-ietf-grow-bmp-yang-04] (72 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) - Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers [draft-ietf-grow-ixp-ext-comms-00] (5 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-04] (22 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-11] (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) - YANG Module for BGP Communities [draft-ietf-grow-yang-bgp-communities-02] (30 pages) - Logging of routing events in BGP Monitoring Protocol (BMP) [draft-lucente-grow-bmp-rel-03] (8 pages) - Definition For New BMP Statistics Type [draft-msri-grow-bmp-bgp-rib-stats-00] (5 pages) - YANG Module for BGP Communities [draft-pels-grow-yang-bgp-communities-00] (23 pages) - Peering API [draft-ramseyer-grow-peering-api-05] (26 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: 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 * Updates RFC9515 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) RFC9515: Revision to Registration Procedures for Multiple BMP Registries (3 pages) Building Blocks for HTTP APIs (httpapi) --------------------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Darrel Miller Rich Salz Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport 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: Jun 2024 - Send to IESG Jun 2024 - Send to IESG Mar 2025 - Enter WGLC Nov 2025 - Enter WGLC Internet-Drafts: - The Idempotency HTTP Header Field [draft-idempotency-header-01] (13 pages) - api-catalog: a well-known URI and link relation to help discovery of APIs [draft-ietf-httpapi-api-catalog-03] (13 pages) - Link relationship types for authentication [draft-ietf-httpapi-authentication-link-01] (5 pages) - The Deprecation HTTP Header Field [draft-ietf-httpapi-deprecation-header-08] (10 pages) - The Idempotency-Key HTTP Header Field [draft-ietf-httpapi-idempotency-key-header-05] (12 pages) - HTTP Link Hints [draft-ietf-httpapi-link-hint-01] (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-04] (6 pages) - Byte Range PATCH [draft-ietf-httpapi-patch-byterange-02] (19 pages) - RateLimit header fields for HTTP [draft-ietf-httpapi-ratelimit-headers-07] (33 pages) - REST API Media Types [draft-ietf-httpapi-rest-api-mediatypes-05] (8 pages) - Problem Details for HTTP APIs [draft-ietf-httpapi-rfc7807bis-07] (16 pages) - YAML Media Type [draft-ietf-httpapi-yaml-mediatypes-10] (17 pages) - HTTP Link Hints [draft-nottingham-link-hint-03] (12 pages) - REST API mediatypes [draft-polli-rest-api-mediatypes-00] (9 pages) - API Keys and Privacy [draft-rsalz-httpapi-privacy-00] (7 pages) - api-catalog: A well-known URI to help discovery of APIs [draft-smith-api-catalog-03] (7 pages) - Linkset: Media Types and a Link Relation Type for Link Sets [draft-wilde-linkset-07] (29 pages) - Byte Range PATCH [draft-wright-http-patch-byterange-04] (19 pages) Requests for Comments: RFC9264: Linkset: Media Types and a Link Relation Type for Link Sets (31 pages) RFC9457: Problem Details for HTTP APIs (16 pages) RFC9512: YAML Media Type (13 pages) HTTP (httpbis) -------------- Charter Last Modified: 2024-02-22 Current Status: Active Chairs: Mark Nottingham Tommy Pauly Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport 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 Retrofit Structured Fields - Submit The HTTP QUERY Method - Submit Client-Cert Header - Submit Cache Groups - Submit Unprompted Auth - Submit Compression Dictionaries - Submit Resumable Uploads - Submit Secondary Server Certs 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 Done - Submit ORIGIN in HTTP/3 Done - Submit HTTP Message Signatures Parked - Submit HTTP Representation Variants Parked - Submit HTTP Alternative Services 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) - Secondary Certificate Authentication of HTTP Servers [draft-egorbaty-httpbis-secondary-server-certs-01] (14 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-07] (8 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) - HTTP Cache Groups [draft-ietf-httpbis-cache-groups-02] (7 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] (14 pages) - HTTP Client Hints [draft-ietf-httpbis-client-hints-15] (10 pages) - Compression Dictionary Transport [draft-ietf-httpbis-compression-dictionary-19] (20 pages) - HTTP Conditional Requests [draft-ietf-httpbis-conditional-01] (4 pages) - Template-Driven HTTP CONNECT Proxying for TCP [draft-ietf-httpbis-connect-tcp-05] (14 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-13] (42 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-19] (118 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) - Security Considerations for Optimistic Use of HTTP Upgrade [draft-ietf-httpbis-optimistic-upgrade-00] (9 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-04] (30 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-15] (61 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-05] (11 pages) - Secondary Certificate Authentication of HTTP Servers [draft-ietf-httpbis-secondary-server-certs-00] (14 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-06] (43 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) - The Concealed HTTP Authentication Scheme [draft-ietf-httpbis-unprompted-auth-11] (17 pages) - HTTP Representation Variants [draft-ietf-httpbis-variants-06] (23 pages) - Window Sizing for Zstandard Content Encoding [draft-ietf-httpbis-zstd-window-size-03] (5 pages) - Window Sizing for Zstandard Content Encoding [draft-jaju-httpbis-zstd-window-size-01] (4 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) - Compression Dictionary Transport [draft-meenan-httpbis-compression-dictionary-05] (14 pages) - The ORIGIN HTTP/2 Frame [draft-nottingham-httpbis-origin-frame-01] (4 pages) - HTTP Cache Groups [draft-nottingham-http-cache-groups-00] (6 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) - Security Considerations for Optimistic Use of HTTP Upgrade [draft-schwartz-httpbis-optimistic-upgrade-00] (9 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) - No-Vary-Search [draft-wicg-http-no-vary-search-01] (13 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) RFC9412: The ORIGIN Extension in HTTP/3 (5 pages) RFC9421: HTTP Message Signatures (95 pages) RFC9440: Client-Cert HTTP Header Field (14 pages) RFC9530: Digest Fields (32 pages) RFC9532: HTTP Proxy-Status Parameter for Next-Hop Aliases (7 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Jeffrey Haas Keyur Patel Susan Hares Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder 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 revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit Extended Communities draft to IESG as a Proposed 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-18] (18 pages) - Deterministic Route Redistribution into BGP [draft-chen-bgp-redist-05] (9 pages) - SR Policies Extensions for Network Resource Partition in BGP-LS [draft-chen-idr-bgp-ls-sr-policy-nrp-09] (8 pages) - BGP for BIER-TE Path [draft-chen-idr-bier-te-path-05] (16 pages) - BGP for Mirror Binding [draft-chen-idr-mbinding-04] (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-04] (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) - IANA Registrations for the BGP Finite State Machine (FSM) [draft-hhp-idr-bgp-fsm-iana-01] (8 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-23] (34 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-13] (23 pages) - BGP Color-Aware Routing (CAR) [draft-ietf-idr-bgp-car-10] (92 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-33] (75 pages) - BGP CT - Adaptation to SRv6 dataplane [draft-ietf-idr-bgp-ct-srv6-05] (20 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) - IANA Registrations for the BGP Finite State Machine (FSM) [draft-ietf-idr-bgp-fsm-iana-00] (8 pages) - BGP Route Reflector with Next Hop Self [draft-ietf-idr-bgp-fwd-rr-02] (9 pages) - Accumulated Metric in NHC attribute [draft-ietf-idr-bgp-generic-metric-00] (22 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-05] (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-16] (12 pages) - BGP-LS Extensions for IS-IS Flood Reflection [draft-ietf-idr-bgp-ls-isis-flood-reflection-04] (6 pages) - Signaling Maximum Transmission Unit (MTU) using BGP-LS [draft-ietf-idr-bgp-ls-link-mtu-07] (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-05] (51 pages) - SR Policies Extensions for Network Resource Partition in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-nrp-00] (8 pages) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-path-segment-07] (12 pages) - BGP-LS Advertisement of Segment Routing Service Segments [draft-ietf-idr-bgp-ls-sr-service-segments-02] (12 pages) - Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) [draft-ietf-idr-bgpls-srv6-ext-14] (23 pages) - Applicability of BGP-LS with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRP) [draft-ietf-idr-bgpls-sr-vtn-mt-06] (10 pages) - Advertisement of Traffic Engineering Paths using BGP Link-State [draft-ietf-idr-bgp-ls-te-path-01] (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-17] (225 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-15] (10 pages) - BGP Extension for SR-MPLS Entropy Label Position [draft-ietf-idr-bgp-srmpls-elp-01] (10 pages) - Segment Routing Segment Types Extensions for BGP SR Policy [draft-ietf-idr-bgp-sr-segtypes-ext-04] (17 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-04] (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 Colored Prefix Routing (CPR) for SRv6 based Services [draft-ietf-idr-cpr-04] (15 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-16] (14 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 Next Hop Dependent Capabilities Attribute [draft-ietf-idr-entropy-label-14] (17 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-23] (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-02] (10 pages) - BGP Dissemination of Flow Specification Rules for Tunneled Traffic [draft-ietf-idr-flowspec-nvo3-20] (20 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-03] (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-05] (10 pages) - BGP Flow Specification Version 2 [draft-ietf-idr-flowspec-v2-04] (73 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) - BGP Flow Specification Version 2 - for Basic IP [draft-ietf-idr-fsv2-ip-basic-00] (57 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-08] (5 pages) - Long-Lived Graceful Restart for BGP [draft-ietf-idr-long-lived-gr-06] (20 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) - MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement [draft-ietf-idr-mpbgp-extension-4map6-02] (17 pages) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-04] (4 pages) - BGP MultiNexthop Attribute [draft-ietf-idr-multinexthop-attribute-01] (54 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-02] (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-04] (11 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-17] (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-19] (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-04] (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-02] (7 pages) - BGP UPDATE for SD-WAN Edge Discovery [draft-ietf-idr-sdwan-edge-discovery-16] (40 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-segment-routing-te-policy-26] (39 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) - Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members [draft-ietf-idr-sr-epe-over-l2bundle-00] (11 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-08] (16 pages) - BGP SR Policy Extensions for metric [draft-ietf-idr-sr-policy-metric-01] (8 pages) - BGP SR Policy Extensions for Network Resource Partition [draft-ietf-idr-sr-policy-nrp-01] (8 pages) - Segment Routing Path MTU in BGP [draft-ietf-idr-sr-policy-path-mtu-09] (11 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-ietf-idr-sr-policy-path-segment-12] (13 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-sr-policy-safi-06] (41 pages) - BGP SR Policy Extensions for Segment List Identifier [draft-ietf-idr-sr-policy-seglist-id-02] (8 pages) - Advertising SID Algorithm Information in BGP [draft-ietf-idr-sr-te-policy-attr-00] (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-04] (14 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-07] (26 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) - BGP MultiNexthop Attribute [draft-kaliraj-idr-multinexthop-attribute-11] (52 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) - Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members [draft-lin-idr-sr-epe-over-l2bundle-08] (11 pages) - BGP Extensions of SR Policy for Headend Behavior [draft-lin-idr-sr-policy-headend-behavior-04] (7 pages) - BGP SR Policy Extensions for Segment List Identifier [draft-lin-idr-sr-policy-seglist-id-05] (7 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) - Advertising SID Algorithm Information in BGP [draft-peng-idr-segment-routing-te-policy-attr-11] (12 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) - Generic Metric for the AIGP attribute [draft-ssangli-idr-bgp-generic-metric-aigp-08] (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) - BGP Colored Prefix Routing (CPR) for SRv6 based Services [draft-wang-idr-cpr-03] (13 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-14] (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) - MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement [draft-xie-idr-mpbgp-extension-4map6-09] (16 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-05] (8 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: 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 * Obsoletes RFC9552 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) * Obsoletes RFC9552 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) RFC9494: Long-Lived Graceful Restart for BGP (20 pages) RFC9514: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) (23 pages) RFC9552: Distribution of Link-State and Traffic Engineering Information Using BGP (60 pages) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2024-07-24 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) - Communicating Proxy Configurations in Provisioning Domains [draft-ietf-intarea-proxy-config-01] (14 pages) - IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters [draft-ietf-intarea-rfc7042bis-11] (37 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-02] (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: 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) RFC9542: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters (32 pages) IOT Operations (iotops) ----------------------- Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Alexey Melnikov Henk Birkholz Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari 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: - Terminology for Constrained-Node Networks [draft-bormann-iotops-ietf-lwig-7228bis-00] (28 pages) - Terminology for Constrained-Node Networks [draft-ietf-iotops-7228bis-00] (28 pages) - Comparison of CoAP Security Protocols [draft-ietf-iotops-security-protocol-comparison-06] (54 pages) - A summary of security-enabling technologies for IoT devices [draft-ietf-iotops-security-summary-02] (27 pages) - A summary of security-enabling technologies for IoT devices [draft-moran-iot-nets-03] (19 pages) No Requests for Comments IP Performance Measurement (ippm) --------------------------------- Charter Last Modified: 2024-06-24 Current Status: Active Chairs: Marcus Ihlar Tommy Pauly Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: https://mailarchive.ietf.org/arch/browse/ippm/ Description of Working Group: The IP Performance Measurement (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols (e.g. TCP, UDP) over IP. It also develops and maintains methodologies and protocols for the measurement of these metrics. These metrics, protocols, and methodologies are designed such that they can be used by network operators, end users, or independent testing groups. Metrics developed by the IPPM WG are intended to provide unbiased quantitative performance measurements. The IPPM WG works to foster commonality and comparability of metrics and measurements across IETF protocols at different layers. Its work is limited to metrics and methodologies which are applicable over transport-layer protocols over IP, and does not specify encapsulations required for measurements over non-IP layers. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The working group will continue advancing the most useful of these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics will be used as the basis for future work on metrics in the WG. The WG will seek to develop new metrics and models to accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths. The WG will balance the need for new metrics with the desire to minimize the introduction of new metrics, and will require that new metric definitions state how the definition improves on an existing metric definition, or assesses a property of network performance not previously covered by a defined metric. Metric definitions will follow the template given in RFC 6390. Additional methods will be defined for the composition and calibration of IPPM-defined metrics, as well as active, passive and hybrid measurement methods for these metrics. In addition, the WG encourages work which describes the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and hybrid methods. The WG may update its core framework RFC 2330 as necessary to accommodate these activities. The WG has produced protocols for communication among test equipment to enable the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively). These protocols will be advanced along the standards track. The work of the WG will take into account the suitability of measurements for automation, in order to support large-scale measurement efforts. This may result in further developments in protocols such as OWAMP and TWAMP. Agreement about the definitions of metrics and methods of measurement enables accurate, reproducible, and equivalent results across different implementations. To this end, the WG defines and maintains a registry of metric definitions. The WG encourages work which assesses the comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG also encourages work which improves the availability of information about the context in which measurements were taken, for example (but not limited to) measurement implementation information, estimates of confidence in these measurements, conditions on the network(s) on which measurements are taken, and/or information about the data-plane topology of these network(s). In the interest of measurement comparability, the WG may define data formats and information models for the storage and exchange of the results of measurements defined within IPPM. The IPPM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches and metrics. Within the IETF process, IPPM metric definitions and measurement protocols will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersects with the requirement of these specific metrics. The WG will, on request, provide input to other IETF working groups on the use and implementation of these metrics. Goals and Milestones: Done - submit a Standards Track document to the IESG for a YANG model for managing TWAMP clients and servers Done - Submit an Experimental draft on coloring-based hybrid measurement methodologies for loss and delay to the IESG Done - Submit a Standards Track draft defining well-known ports for OWAMP and TWAMP to the IESG Done - submit a Standards Track document to the IESG defining initial contents of performance metric registry Done - submit a Standards Track document to the IESG updating RFC2330 to cover IPv6 Done - Submit a Standards Track drafts defining a simple two-way active measurement protocol based on TWAMP-Test, and a YANG data model to control it, to the IESG Done - Submit draft on core registry for performance metrics to IESG as Proposed Standard Done - submit a Standards Track draft on inband OAM based measurement methodologies to the IESG Done - Submit a Standards Track draft defining a metric for unidirectional route assessment to the IESG Done - Submit a Standards Track document on Direct Export for IOAM Done - Submit a Standards Track document on Metrics and Methods for IP Capacity Measurement Internet-Drafts: - Integrity of In-situ OAM Data Fields [draft-brockners-ippm-ioam-data-integrity-03] (16 pages) - In-situ OAM Deployment [draft-brockners-opsawg-ioam-deployment-03] (23 pages) - Two-Way Active Measurement Protocol (TWAMP) Data Model [draft-cmzrjp-ippm-twamp-yang-02] (56 pages) - IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option [draft-elkins-ippm-encrypted-pdmv2-02] (17 pages) - Multipoint Alternate Marking method for passive and hybrid performance monitoring [draft-fioccola-ippm-multipoint-alt-mark-04] (20 pages) - Alternate-Marking Method [draft-fioccola-rfc8321bis-04] (27 pages) - Multipoint Alternate-Marking Method [draft-fioccola-rfc8889bis-04] (27 pages) - Alternate Marking Deployment Framework [draft-fz-ippm-alt-mark-deployment-01] (17 pages) - Simple TWAMP (STAMP) Extensions for Segment Routing Networks [draft-gandhi-ippm-stamp-srpm-03] (12 pages) - TWAMP Light Extensions for Segment Routing Networks [draft-gandhi-ippm-twamp-srpm-00] (13 pages) - A Connectivity Monitoring Metric for IPPM [draft-geib-ippm-connectivity-monitoring-03] (13 pages) - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP) [draft-hedin-ippm-type-p-monitor-04] (10 pages) - IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework [draft-ietf-ippm-2330-ipv6-06] (15 pages) - Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) [draft-ietf-ippm-2330-update-05] (17 pages) - A One-Way Delay Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-2679-bis-05] (27 pages) - A One-Way Loss Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-2680-bis-05] (22 pages) - IPv6 Performance and Diagnostic Metrics (PDM) Destination Option [draft-ietf-ippm-6man-pdm-option-13] (30 pages) - Active and Passive Metrics and Methods (with Hybrid Types In-Between) [draft-ietf-ippm-active-passive-06] (14 pages) - Alternate-Marking Method for Passive and Hybrid Performance Monitoring [draft-ietf-ippm-alt-mark-14] (33 pages) - Alternate Marking Deployment Framework [draft-ietf-ippm-alt-mark-deployment-01] (17 pages) - Performance Measurement with Asymmetrical Packets in STAMP [draft-ietf-ippm-asymmetrical-pkts-01] (11 pages) - A Framework for Defining Empirical Bulk Transfer Capacity Metrics [draft-ietf-ippm-btc-framework-05] (16 pages) - Defining Network Capacity [draft-ietf-ippm-bw-capacity-05] (14 pages) - Metrics and Methods for One-Way IP Capacity [draft-ietf-ippm-capacity-metric-method-12] (33 pages) - Test Protocol for One-way IP Capacity Measurement [draft-ietf-ippm-capacity-protocol-07] (56 pages) - UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-checksum-trailer-06] (15 pages) - IPPM Metrics for Measuring Connectivity [draft-ietf-ippm-connectivity-04] (10 pages) - A Connectivity Monitoring Metric for IPPM [draft-ietf-ippm-connectivity-monitoring-09] (29 pages) - A One-way Delay Metric for IPPM [draft-ietf-ippm-delay-07] (20 pages) - Packet Delay Variation Applicability Statement [draft-ietf-ippm-delay-var-as-02] (39 pages) - A One-Way Packet Duplication Metric [draft-ietf-ippm-duplicate-08] (14 pages) - IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option [draft-ietf-ippm-encrypted-pdmv2-08] (21 pages) - Explicit Host-to-Network Flow Measurements Techniques [draft-ietf-ippm-explicit-flow-measurements-07] (37 pages) - Framework for IP Performance Metrics [draft-ietf-ippm-framework-02] (40 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-09] (18 pages) - Hybrid Two-Step Performance Measurement Method [draft-ietf-ippm-hybrid-two-step-02] (20 pages) - Overview of Implementation reports relating to IETF work on IP Performance Measurements (IPPM, RFC 2678 - 2681) [draft-ietf-ippm-implement-02] (24 pages) - Initial Performance Metrics Registry Entries [draft-ietf-ippm-initial-registry-16] (71 pages) - Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities [draft-ietf-ippm-ioam-conf-state-10] (17 pages) - Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) [draft-ietf-ippm-ioam-data-17] (40 pages) - Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields [draft-ietf-ippm-ioam-data-integrity-12] (22 pages) - In Situ Operations, Administration, and Maintenance (IOAM) Deployment [draft-ietf-ippm-ioam-deployment-05] (20 pages) - In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting [draft-ietf-ippm-ioam-direct-export-11] (13 pages) - In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags [draft-ietf-ippm-ioam-flags-10] (13 pages) - IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) [draft-ietf-ippm-ioam-ipv6-options-12] (10 pages) - A YANG Data Model for In-Situ OAM [draft-ietf-ippm-ioam-yang-13] (31 pages) - IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-ipdv-09] (21 pages) - IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-ipsec-11] (15 pages) - A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance [draft-ietf-ippm-lmap-path-07] (17 pages) - A One-way Packet Loss Metric for IPPM [draft-ietf-ippm-loss-07] (15 pages) - Loss Episode Metrics for IP Performance Metrics (IPPM) [draft-ietf-ippm-loss-episode-metrics-04] (21 pages) - One-way Loss Pattern Sample Metrics [draft-ietf-ippm-loss-pattern-06] (15 pages) - Registry for Performance Metrics [draft-ietf-ippm-metric-registry-24] (35 pages) - IP Performance Metrics (IPPM) Metrics Registry [draft-ietf-ippm-metrics-registry-08] (14 pages) - IP Performance Metrics (IPPM) Standard Advancement Testing [draft-ietf-ippm-metrictest-05] (37 pages) - Model-Based Metrics for Bulk Transport Capacity [draft-ietf-ippm-model-based-metrics-13] (55 pages) - Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-more-twamp-02] (8 pages) - IP Performance Metrics (IPPM): Spatial and Multicast [draft-ietf-ippm-multimetrics-12] (57 pages) - Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring [draft-ietf-ippm-multipoint-alt-mark-09] (23 pages) - Network performance measurement with periodic streams [draft-ietf-ippm-npmps-07] (23 pages) - One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG [draft-ietf-ippm-otwamp-on-lag-08] (14 pages) - Registries for the One-Way Active Measurement Protocol (OWAMP) [draft-ietf-ippm-owamp-registry-03] (7 pages) - A One-way Active Measurement Protocol (OWAMP) [draft-ietf-ippm-owdp-16] (56 pages) - One-way Active Measurement Protocol (OWAMP) Requirements [draft-ietf-ippm-owdp-reqs-06] (11 pages) - Precision Availability Metrics for Services Governed by Service Level Objectives (SLOs) [draft-ietf-ippm-pam-09] (14 pages) - Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-port-twamp-test-04] (11 pages) - Quality of Outcome [draft-ietf-ippm-qoo-00] (27 pages) - Rate Measurement Test Protocol Problem Statement and Requirements [draft-ietf-ippm-rate-problem-10] (14 pages) - Active Performance Metric Sub-Registry [draft-ietf-ippm-registry-active-01] (27 pages) - Passive Performance Metrics Sub-Registry [draft-ietf-ippm-registry-passive-01] (23 pages) - Packet Reordering Metrics [draft-ietf-ippm-reordering-13] (45 pages) - Reporting IP Performance Metrics to Users [draft-ietf-ippm-reporting-06] (42 pages) - Reporting IP Network Performance Metrics: Different Points of View [draft-ietf-ippm-reporting-metrics-09] (27 pages) - IP Performance Metrics (IPPM) reporting Information Base (MIB) [draft-ietf-ippm-reporting-mib-06] (80 pages) - Responsiveness under Working Conditions [draft-ietf-ippm-responsiveness-04] (26 pages) - Alternate-Marking Method [draft-ietf-ippm-rfc8321bis-03] (22 pages) - Clustered Alternate-Marking Method [draft-ietf-ippm-rfc8889bis-04] (24 pages) - Advanced Unidirectional Route Assessment (AURA) [draft-ietf-ippm-route-10] (23 pages) - A Round-trip Delay Metric for IPPM [draft-ietf-ippm-rt-delay-01] (20 pages) - Round-Trip Packet Loss Metrics [draft-ietf-ippm-rt-loss-05] (14 pages) - Spatial Composition of Metrics [draft-ietf-ippm-spatial-composition-16] (29 pages) - Simple Two-Way Active Measurement Protocol [draft-ietf-ippm-stamp-10] (15 pages) - Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Extension Headers [draft-ietf-ippm-stamp-ext-hdr-00] (15 pages) - Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG [draft-ietf-ippm-stamp-on-lag-06] (9 pages) - Simple Two-Way Active Measurement Protocol Optional Extensions [draft-ietf-ippm-stamp-option-tlv-10] (29 pages) - Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks [draft-ietf-ippm-stamp-srpm-18] (16 pages) - Simple Two-way Active Measurement Protocol (STAMP) Data Model [draft-ietf-ippm-stamp-yang-12] (44 pages) - Information Model and XML Data Model for Traceroute Measurements [draft-ietf-ippm-storetraceroutes-12] (75 pages) - Framework for TCP Throughput Testing [draft-ietf-ippm-tcp-throughput-tm-13] (27 pages) - Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track [draft-ietf-ippm-testplan-rfc2679-03] (29 pages) - Test Plan and Results for Advancing RFC 2680 on the Standards Track [draft-ietf-ippm-testplan-rfc2680-05] (31 pages) - A Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-09] (26 pages) - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features [draft-ietf-ippm-twamp-reflect-octets-09] (18 pages) - Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-session-cntrl-07] (17 pages) - Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-time-format-06] (8 pages) - Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets [draft-ietf-ippm-twamp-value-added-octets-09] (15 pages) - Two-Way Active Measurement Protocol (TWAMP) YANG Data Model [draft-ietf-ippm-twamp-yang-13] (60 pages) - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-type-p-monitor-03] (11 pages) - In-situ OAM IPv6 Options [draft-ioametal-ippm-6man-ioam-ipv6-options-02] (9 pages) - In-situ OAM Direct Exporting [draft-ioamteam-ippm-ioam-direct-export-00] (11 pages) - Explicit Flow Measurements Techniques [draft-mdt-ippm-explicit-flow-measurements-02] (40 pages) - Precision Availability Metrics for SLO-Governed End-to-End Services [draft-mhmcsfh-ippm-pam-03] (13 pages) - Performance Measurement with Asymmetrical Packets in STAMP [draft-mirsky-ippm-asymmetrical-pkts-04] (11 pages) - Hybrid Two-Step Performance Measurement Method [draft-mirsky-ippm-hybrid-two-step-15] (19 pages) - Simple Two-way Active Measurement Protocol Optional Extensions [draft-mirsky-ippm-stamp-option-tlv-05] (16 pages) - UDP Checksum Trailer in OWAMP and TWAMP [draft-mizrahi-ippm-checksum-trailer-02] (11 pages) - In-situ OAM Flags [draft-mizrahi-ippm-ioam-flags-00] (10 pages) - A One-Way Delay Metric for IPPM [draft-morton-ippm-2679-bis-06] (24 pages) - A One-Way Loss Metric for IPPM [draft-morton-ippm-2680-bis-04] (20 pages) - Metrics and Methods for IP Capacity [draft-morton-ippm-capacity-metric-method-01] (20 pages) - Test Protocol for One-way IP Capacity Measurement [draft-morton-ippm-capacity-metric-protocol-02] (30 pages) - Initial Performance Metric Registry Entries [draft-morton-ippm-initial-registry-04] (62 pages) - RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete [draft-morton-ippm-rfc4148-obsolete-03] (6 pages) - Quality of Outcome [draft-olden-ippm-qoo-02] (16 pages) - Echo Request/Reply for Enabled In-situ OAM Capabilities [draft-xiao-ippm-ioam-conf-state-10] (18 pages) - A YANG Data Model for In-Situ OAM [draft-zhou-ippm-ioam-yang-08] (25 pages) Requests for Comments: RFC2330: Framework for IP Performance Metrics (40 pages) * Updates RFC7312 * Updates RFC8468 * Updates RFC9198 RFC2498: IPPM Metrics for Measuring Connectivity (10 pages) * Obsoletes RFC2678 RFC2679: A One-way Delay Metric for IPPM (20 pages) * Obsoletes RFC7679 RFC2680: A One-way Packet Loss Metric for IPPM (15 pages) * Obsoletes RFC7680 RFC2681: A Round-trip Delay Metric for IPPM (20 pages) RFC3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics (16 pages) RFC3357: One-way Loss Pattern Sample Metrics (15 pages) RFC3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) (21 pages) RFC3432: Network performance measurement with periodic streams (23 pages) RFC3763: One-way Active Measurement Protocol (OWAMP) Requirements (11 pages) RFC4148: IP Performance Metrics (IPPM) Metrics Registry (14 pages) * Obsoletes RFC6248 RFC4656: A One-way Active Measurement Protocol (OWAMP) (56 pages) * Updates RFC7717 * Updates RFC7718 * Updates RFC8545 RFC4737: Packet Reordering Metrics (45 pages) * Updates RFC6248 RFC5136: Defining Network Capacity (14 pages) RFC5357: A Two-Way Active Measurement Protocol (TWAMP) (26 pages) * Updates RFC5618 * Updates RFC5938 * Updates RFC6038 * Updates RFC7717 * Updates RFC7750 * Updates RFC8545 RFC5388: Information Model and XML Data Model for Traceroute Measurements (75 pages) RFC5481: Packet Delay Variation Applicability Statement (39 pages) RFC5560: A One-Way Packet Duplication Metric (14 pages) * Updates RFC6248 RFC5618: Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) (8 pages) RFC5644: IP Performance Metrics (IPPM): Spatial and Multicast (57 pages) * Updates RFC6248 RFC5835: Framework for Metric Composition (18 pages) RFC5938: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) (17 pages) RFC6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features (18 pages) RFC6049: Spatial Composition of Metrics (29 pages) * Updates RFC6248 RFC6248: RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete (6 pages) RFC6349: Framework for TCP Throughput Testing (27 pages) RFC6534: Loss Episode Metrics for IP Performance Metrics (IPPM) (21 pages) RFC6576: IP Performance Metrics (IPPM) Standard Advancement Testing (37 pages) RFC6673: Round-Trip Packet Loss Metrics (14 pages) RFC6703: Reporting IP Network Performance Metrics: Different Points of View (27 pages) RFC6802: Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets (15 pages) RFC6808: Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track (29 pages) RFC7290: Test Plan and Results for Advancing RFC 2680 on the Standards Track (31 pages) RFC7312: Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) (17 pages) RFC7398: A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance (17 pages) RFC7497: Rate Measurement Test Protocol Problem Statement and Requirements (14 pages) RFC7679: A One-Way Delay Metric for IP Performance Metrics (IPPM) (27 pages) RFC7680: A One-Way Loss Metric for IP Performance Metrics (IPPM) (22 pages) RFC7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) (15 pages) RFC7718: Registries for the One-Way Active Measurement Protocol (OWAMP) (7 pages) RFC7750: Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) (11 pages) RFC7799: Active and Passive Metrics and Methods (with Hybrid Types In-Between) (14 pages) RFC7820: UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) (15 pages) RFC8186: Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) (8 pages) RFC8250: IPv6 Performance and Diagnostic Metrics (PDM) Destination Option (30 pages) RFC8321: Alternate-Marking Method for Passive and Hybrid Performance Monitoring (33 pages) * Obsoletes RFC9341 RFC8337: Model-Based Metrics for Bulk Transport Capacity (55 pages) RFC8468: IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework (15 pages) RFC8545: Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) (11 pages) RFC8762: Simple Two-Way Active Measurement Protocol (15 pages) * Updates RFC8972 RFC8889: Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring (23 pages) * Obsoletes RFC9342 RFC8911: Registry for Performance Metrics (35 pages) RFC8912: Initial Performance Metrics Registry Entries (71 pages) RFC8913: Two-Way Active Measurement Protocol (TWAMP) YANG Data Model (60 pages) RFC8972: Simple Two-Way Active Measurement Protocol Optional Extensions (29 pages) RFC9097: Metrics and Methods for One-Way IP Capacity (33 pages) RFC9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) (40 pages) RFC9198: Advanced Unidirectional Route Assessment (AURA) (23 pages) RFC9322: In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags (13 pages) RFC9326: In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting (13 pages) RFC9341: Alternate-Marking Method (22 pages) RFC9342: Clustered Alternate-Marking Method (24 pages) RFC9359: Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities (17 pages) RFC9378: In Situ Operations, Administration, and Maintenance (IOAM) Deployment (20 pages) RFC9486: IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) (10 pages) RFC9503: Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks (16 pages) RFC9506: Explicit Host-to-Network Flow Measurements Techniques (37 pages) RFC9533: One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group (13 pages) RFC9534: Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group (8 pages) RFC9544: Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs) (12 pages) RFC9617: A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) (28 pages) IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Tero Kivinen Yoav Nir Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. Goals and Milestones: Jun 2021 - The ESP on contrained network to IESG Jul 2022 - G-DOI for IKEv2 to IESG Done - The internal address failure indication in IKEv2 to IESG Done - Traffic Flow Confidentiality document to IESG Done - Signature algorithm negotiation for IKEv2 to IESG Done - Postquantum cryptography document for IKEv2 to IESG Done - TCP-encapsulation guidelines document to IESG Done - The security labels support for IKEv2 to IESG Internet-Drafts: - IKEv2 Notification Codes for IPv4/IPv6 Coexistence [draft-boucadair-ipsecme-ipv6-ipv4-codes-03] (6 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS [draft-btw-add-ipsecme-ike-04] (13 pages) - Definitions of Managed Objects for IP Traffic Flow Security [draft-fedyk-ipsecme-mib-iptfs-00] (19 pages) - IP Traffic Flow Security YANG Module [draft-fedyk-ipsecme-yang-iptfs-02] (27 pages) - Postquantum Preshared Keys for IKEv2 [draft-fluhrer-qr-ikev2-04] (11 pages) - IP Traffic Flow Security [draft-hopps-ipsecme-iptfs-01] (25 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS [draft-ietf-ipsecme-add-ike-14] (16 pages) - Auto-Discovery VPN Problem Statement and Requirements [draft-ietf-ipsecme-ad-vpn-problem-09] (12 pages) - Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol [draft-ietf-ipsecme-aes-ctr-ikev2-07] (6 pages) - ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec [draft-ietf-ipsecme-chacha20-poly1305-12] (13 pages) - Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks [draft-ietf-ipsecme-ddos-protection-10] (32 pages) - Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-dh-checks-05] (10 pages) - ESP Header Compression Profile [draft-ietf-ipsecme-diet-esp-01] (35 pages) - An Extension for EAP-Only Authentication in IKEv2 [draft-ietf-ipsecme-eap-mutual-05] (16 pages) - Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-eddsa-04] (5 pages) - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [draft-ietf-ipsecme-esp-ah-reqts-10] (11 pages) - Heuristics for Detecting ESP-NULL Packets [draft-ietf-ipsecme-esp-null-heuristics-07] (32 pages) - A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) [draft-ietf-ipsecme-failure-detection-08] (22 pages) - Group Key Management using IKEv2 [draft-ietf-ipsecme-g-ikev2-14] (74 pages) - Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms [draft-ietf-ipsecme-ikev1-algo-to-historic-09] (7 pages) - Announcing Supported Authentication Methods in IKEv2 [draft-ietf-ipsecme-ikev2-auth-announce-10] (14 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2bis-11] (138 pages) - Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) [draft-ietf-ipsecme-ikev2-diet-esp-extension-00] (8 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation [draft-ietf-ipsecme-ikev2-fragmentation-10] (20 pages) - Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-intermediate-10] (14 pages) - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-ipv6-config-03] (32 pages) - Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-multiple-ke-12] (29 pages) - The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-null-auth-07] (12 pages) - Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security [draft-ietf-ipsecme-ikev2-qr-alt-04] (12 pages) - Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-redirect-13] (15 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption [draft-ietf-ipsecme-ikev2-resumption-09] (26 pages) - IKEv2 Optional SA&TS Payloads in Child Exchange [draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-03] (9 pages) - Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) [draft-ietf-ipsecme-implicit-iv-11] (8 pages) - IPsec Cluster Problem Statement [draft-ietf-ipsecme-ipsec-ha-09] (12 pages) - Protocol Support for High Availability of IKEv2/IPsec [draft-ietf-ipsecme-ipsecha-protocol-06] (26 pages) - Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) [draft-ietf-ipsecme-iptfs-19] (31 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence [draft-ietf-ipsecme-ipv6-ipv4-codes-06] (7 pages) - Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-labeled-ipsec-12] (7 pages) - Definitions of Managed Objects for IP Traffic Flow Security [draft-ietf-ipsecme-mib-iptfs-11] (19 pages) - IKEv2 support for per-resource Child SAs [draft-ietf-ipsecme-multi-sa-performance-09] (13 pages) - More Raw Public Keys for IKEv2 [draft-ietf-ipsecme-oob-pubkey-00] (8 pages) - Auto Discovery VPN Problem Statement and Requirements [draft-ietf-ipsecme-p2p-vpn-problem-02] (14 pages) - Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security [draft-ietf-ipsecme-qr-ikev2-11] (16 pages) - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-rfc4307bis-18] (19 pages) - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [draft-ietf-ipsecme-rfc7321bis-06] (15 pages) - TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets [draft-ietf-ipsecme-rfc8229bis-09] (30 pages) - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap [draft-ietf-ipsecme-roadmap-10] (63 pages) - Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement [draft-ietf-ipsecme-safecurves-05] (8 pages) - Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-split-dns-17] (16 pages) - TCP Encapsulation of IKE and IPsec Packets [draft-ietf-ipsecme-tcp-encaps-10] (25 pages) - Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility [draft-ietf-ipsecme-traffic-visibility-12] (15 pages) - A YANG Data Model for IP Traffic Flow Security [draft-ietf-ipsecme-yang-iptfs-11] (25 pages) - IKEv2 Optional SA&TS Payloads in Child Exchange [draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-10] (9 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-kivinen-ipsecme-ikev2-rfc5996bis-04] (142 pages) - Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) [draft-kivinen-ipsecme-signature-auth-07] (18 pages) - ESP Header Compression Profile [draft-mglt-ipsecme-diet-esp-12] (27 pages) - Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) [draft-mglt-ipsecme-ikev2-diet-esp-extension-04] (8 pages) - Implicit IV for Counter-based Ciphers in IPsec [draft-mglt-ipsecme-implicit-iv-04] (7 pages) - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [draft-mglt-ipsecme-rfc7321bis-04] (13 pages) - Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) [draft-nir-ipsecme-eddsa-01] (5 pages) - Split DNS Configuration for IKEv2 [draft-pauly-ipsecme-split-dns-02] (12 pages) - TCP Encapsulation of IKEv2 and IPSec Packets [draft-pauly-ipsecme-tcp-encaps-04] (18 pages) - Deprecation of IKEv1 and obsoleted algorithms [draft-pwouters-ikev1-ipsec-graveyard-06] (6 pages) - IKEv2 support for per-queue Child SAs [draft-pwouters-ipsecme-multi-sa-performance-05] (12 pages) - Announcing Supported Authentication Methods in IKEv2 [draft-smyslov-ipsecme-ikev2-auth-announce-04] (9 pages) - Intermediate Exchange in the IKEv2 Protocol [draft-smyslov-ipsecme-ikev2-aux-02] (10 pages) - Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security [draft-smyslov-ipsecme-ikev2-qr-alt-09] (11 pages) - TCP Encapsulation of IKE and IPsec Packets [draft-smyslov-ipsecme-rfc8229bis-02] (29 pages) - Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) [draft-tjhai-ipsecme-hybrid-qske-ikev2-04] (21 pages) - Group Key Management using IKEv2 [draft-yeung-g-ikev2-16] (52 pages) Requests for Comments: RFC5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (15 pages) RFC5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (26 pages) RFC5739: IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (32 pages) RFC5840: Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (15 pages) RFC5879: Heuristics for Detecting ESP-NULL Packets (32 pages) RFC5930: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (6 pages) RFC5996: Internet Key Exchange Protocol Version 2 (IKEv2) (138 pages) * Updates RFC5998 * Updates RFC6989 * Updates RFC6989 * Obsoletes RFC7296 RFC5998: An Extension for EAP-Only Authentication in IKEv2 (16 pages) RFC6027: IPsec Cluster Problem Statement (12 pages) RFC6071: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (63 pages) RFC6290: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) (22 pages) RFC6311: Protocol Support for High Availability of IKEv2/IPsec (26 pages) RFC6989: Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) (10 pages) RFC7018: Auto-Discovery VPN Problem Statement and Requirements (12 pages) RFC7296: Internet Key Exchange Protocol Version 2 (IKEv2) (142 pages) * Updates RFC7427 * Updates RFC7670 * Updates RFC8247 * Updates RFC8983 * Updates RFC9370 RFC7321: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) (11 pages) * Obsoletes RFC8221 RFC7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation (20 pages) RFC7427: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) (18 pages) RFC7619: The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) (12 pages) RFC7634: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec (13 pages) RFC8019: Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks (32 pages) RFC8031: Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement (8 pages) RFC8221: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) (15 pages) * Updates RFC9395 RFC8229: TCP Encapsulation of IKE and IPsec Packets (25 pages) * Obsoletes RFC9329 RFC8247: Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) (19 pages) * Updates RFC9395 RFC8420: Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) (5 pages) RFC8598: Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) (16 pages) RFC8750: Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) (8 pages) RFC8784: Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security (16 pages) RFC8983: Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence (7 pages) RFC9242: Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) (14 pages) RFC9329: TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets (30 pages) RFC9347: Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) (31 pages) RFC9348: A YANG Data Model for IP Traffic Flow Security (25 pages) RFC9349: Definitions of Managed Objects for IP Traffic Flow Security (19 pages) RFC9370: Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) (29 pages) RFC9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms (7 pages) RFC9464: Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS (16 pages) RFC9478: Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2) (7 pages) RFC9593: Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2) (13 pages) RFC9611: Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per-Resource Child Security Associations (SAs) (9 pages) Network Inventory YANG (ivy) ---------------------------- Charter Last Modified: 2024-07-23 Current Status: Active Chairs: Daniele Ceccarelli Qiufang Ma Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Editors: Adrian Farrel Daniele Ceccarelli Robert Wilton Mailing Lists: General Discussion: inventory-yang@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/inventory-yang Archive: https://mailarchive.ietf.org/arch/browse/inventory-yang/ Description of Working Group: Network inventory is a foundation for network management in all types of networks: Network operators need to keep a record of what equipment is planned and installed in their networks (including a variety of information such as product name, vendor, product series, embedded software, and hardware/software versions). Network inventories may be constructed from management system data to represent the expected devices present in the network, and also be used to audit and catalog what devices are discovered in the network, and to expose that information in a consistent way. The purpose of the IVY WG is to provide a venue for discussion of inventory YANG models from across IETF Areas under a common umbrella to facilitate distribution of the work, clarify the scope of each model, and minimize overlap between them. The Working Group may also dispatch some inventory work towards Working Groups in the Operations and Management Area as well as other Areas, if appropriate. An objective of this effort is to derive common building-blocks for inventory modeling that can be augmented, imported, or reused by other IETF models. The WG will also identify a set of requirements and guidelines to ensure consistency across models related to inventory. The scope of the work extends to the inventory of network elements, with a primary focus on those that operate at layers 0-3, and includes both hardware and software inventory. Mapping the inventory models that will be produced by the WG into existing IETF models (e.g., ietf-network-topology) is also in scope. The Working Group will consider existing IETF work, including RFC 8348 and RFC 8345. Work specifying the use of inventory content is outside the scope of the Working Group, but informative examples describing how the inventory data may be used is within scope. The IVY WG will initially focus on developing a core network inventory model that can be used as a foundation by other models to establish inventory models that are specific to different hardware technologies. The following activities will be used to help achieve this goal. It is expected that many of these items will not lead to the publication of RFCs, although Internet-Drafts may be used to track discussions and establish consensus: A. Terminology and Scope: Definition of the scope of inventory as well as a common architecture and terminology. An effort will be made to keep terminology aligned with, or mapped to, industry-wide activities including initiatives in the IEEE, ITU-T, TMF, MEF, Openconfig, ONF, and 3GPP. B. Hardware/Software components including licenses: Hardware and Software component management to allow network operators to keep track of which physical/virtual devices are deployed in the network, including software and hardware versions as well as licenses/entitlement. C. Physical locations: Indicate the physical position of the network elements (such as, site, room, rack, shelf, slot) to provide precise location information. D. Multi-domain and multi-layer: Consistent representation and reporting of network inventory to maintain a centralized view of all network element component types across multiple network segments and layers of the underlying network under the same management and ownership. E. Mapping and correlation semantics: Correlating the inventory with existing IETF models e.g., topology, service attachment points (SAP), etc. F. Security and privacy issues: The information in a network inventory is highly sensitive as it potentially exposes critical information about the internal topology, characterization of the components that are used to build that topology, and precise device location information that could indirectly identify user locations. Standard protocol mechanisms, e.g., the use of NACM [RFC 8341], are expected to be used to prevent unauthorized access. However, the Working Group must consider whether additional security mechanisms (such as specific operational guidance, or data minimization of precise location data) are needed to protect this information from unauthorized access, manipulation, or the indirect exposition of private user identifying data. Goals and Milestones: Oct 2023 - Adopt an Internet-Draft describing a core network inventory YANG data model that can be used as a foundation by other YANG models to establish technology-specific inventory models. Jul 2024 - Request publication of the below YANG data model. Internet-Drafts: - A Network Inventory Topology Model [draft-ietf-ivy-network-inventory-topology-00] (18 pages) - A YANG Data Model for Network Inventory [draft-ietf-ivy-network-inventory-yang-03] (33 pages) - A YANG Data Model for Network Inventory Location [draft-wbbpb-ivy-network-inventory-location-02] (18 pages) - A YANG Data Model for Network Inventory [draft-y3bp-ivy-network-inventory-yang-00] (30 pages) No Requests for Comments 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 Orie Steele 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/browse/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: Sep 2024 - Submit Webpush Vapid document to IESG Oct 2024 - Adopt a document for JMAP Archive format Nov 2024 - Submit Portability Guide (Minimal Profile) to IESG Nov 2024 - Submit Portability Extensions to IESG Feb 2025 - Submit REST Mapping document to IESG Feb 2025 - Submit JMAP Tasks document to IESG Feb 2025 - Submit SMIME Sender Extensions document to the IESG Done - Adopt a document for a JSON Contact format (after recharter) Done - Adopt a document defining mappings between VCARD and JSContact Done - Submit Message Disposition Notification document to the IESG 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 document for Blobs via JMAP to the IESG Done - Submit JMAP Quotas document to the IESG Done - Adopt a document defining JMAP access to addressbooks Done - Coordinate with extra wg and potentially adopt document for snooze Done - Submit Sieve document to the IESG Done - Adopt a document for JMAP REST mapping Done - Adopt a document for Server info and debug Done - Adopt a draft for a basic migration simplified endpoint Done - Submit JMAP Sharing document to IESG Done - Submit Contacts document to the IESG Done - Submit JMAP Calendars document to the IESG Internet-Drafts: - JMAP Migration and Portability Extensions [draft-baum-jmap-portability-extensions-00] (8 pages) - JMAP Guide for Migration and Data Portability [draft-baum-jmap-portability-guide-00] (19 pages) - JMAP REST Mapping [draft-baum-jmap-rest-01] (7 pages) - JMAP for Tasks [draft-baum-jmap-tasks-00] (16 pages) - JMAP Blob management extension [draft-gondwana-jmap-blob-02] (10 pages) - Use of VAPID in JMAP WebPush [draft-gultsch-jmap-webpush-vapid-02] (4 pages) - JSON Meta Application Protocol (JMAP) Blob Management Extension [draft-ietf-jmap-blob-18] (24 pages) - JMAP for Calendars [draft-ietf-jmap-calendars-20] (64 pages) - JMAP for Contacts [draft-ietf-jmap-contacts-10] (18 pages) - The JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-core-17] (90 pages) - JMAP Essential Profile [draft-ietf-jmap-essential-01] (20 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 Migration and Portability Extensions [draft-ietf-jmap-portability-extensions-01] (9 pages) - JMAP Guide for Migration and Data Portability [draft-ietf-jmap-portability-guide-00] (19 pages) - JSON Meta Application Protocol (JMAP) for Quotas [draft-ietf-jmap-quotas-12] (11 pages) - JMAP REST Mapping [draft-ietf-jmap-rest-00] (7 pages) - JMAP Sharing [draft-ietf-jmap-sharing-09] (18 pages) - JMAP for Sieve Scripts [draft-ietf-jmap-sieve-22] (27 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-04] (9 pages) - JMAP for Tasks [draft-ietf-jmap-tasks-06] (26 pages) - Use of VAPID in JMAP WebPush [draft-ietf-jmap-webpush-vapid-03] (5 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) * Updates RFC9404 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) RFC9404: JSON Meta Application Protocol (JMAP) Blob Management Extension (24 pages) RFC9425: JSON Meta Application Protocol (JMAP) for Quotas (11 pages) Javascript Object Signing and Encryption (jose) ----------------------------------------------- Charter Last Modified: 2024-08-22 Current Status: Active Chairs: John Bradley John Preuß Mattsson Karen O'Donoghue Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: jose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: https://mailarchive.ietf.org/arch/browse/jose/ Description of Working Group: The original [JSON Object Signing and Encryption (JOSE) working group][1] standardized JSON-based representations for: Integrity-protected objects (JSON Web Signatures/JWS, RFC 7515), Encrypted objects (JSON Web Encryption/JWE, RFC7516), Key representations (JSON Web Key/JWK, RFC 7517), Algorithm definitions (JSON Web Algorithms/JWA, RFC 7518), and Test vectors for the above (Examples of Protecting Content Using JSON Object Signing and Encryption, RFC 7520). These were used to define the JSON Web Token (JWT) (RFC 7519), which in turn, has seen widespread deployment in areas as diverse as [digital identity][2] and [secure telephony][3]. As adoption of these standards to express and communicate sensitive data has grown, so too has an increasing societal focus on privacy. User consent, minimal disclosure, and unlinkability are common privacy themes in identity solutions. A multi-decade research activity for a sizeable academic and applied cryptography community has focused on these privacy and knowledge mechanisms (often referred to as anonymous credentials). Certain cryptographic techniques developed in this space involve pairing-friendly curves and zero-knowledge proofs (ZKPs) (to name just a few). Some of the benefits of ZKP algorithms include unlinkability, selective disclosure, and the ability to use predicate proofs. The current container formats defined by JOSE and JWT are not able to represent data using ZKP algorithms. Among the reasons are that most require an additional transform or finalize step, many are designed to operate on sets and not single messages, and the interface to ZKP algorithms has more inputs than conventional signing algorithms. The reconstituted JOSE working group will address these new needs, while reusing aspects of JOSE and JWT, where applicable. This group is chartered to work on the following goals: - An Informational document detailing Use Cases and Requirements for new specifications enabling JSON-based selective disclosure and zero-knowledge proofs. - Standards Track document(s) specifying representation(s) of independently-disclosable integrity-protected sets of data and/or proofs using JSON-based data structures, which also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying representation(s) of JSON-based claims and/or proofs enabling selective disclosure of these claims and/or proofs, and that also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying how to use existing cryptographic algorithms and defining their algorithm identifiers. The working group will not invent new cryptographic algorithms. - Standards Track document(s) specifying how to represent keys for these new algorithms as JSON Web Keys (JWKs). - Informational document(s) defining test vectors for these new specifications. - Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). The JOSE working group will also maintain the JOSE standard and facilitate discussion of clarifications, improvements, and extensions to JWS, JWE, JWA, and JWK. The WG will evaluate, and potentially adopt, proposed standard documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms. Potential candidates would include those algorithms that have been evaluated by the CFRG and algorithms which have gone through a public review and evaluation process such as was done for the NIST SHA-3 algorithms. Potential candidates would not include national-standards-based algorithms that have not gone through a similar public review process. The WG may also publish informational and BCP documents describing the proper use of these algorithms in JOSE. An informal goal of the working group is close coordination with the [rechartered W3C Verifiable Credentials WG][4], which has taken a dependency on this work for the second version of its Verifiable Credentials specification. The working group will also coordinate with the [Selective Disclosure JWT][5] work in the [OAuth][6] working group, the [Privacy Pass][7] working group, the [CBOR][8] working group, the [COSE][10] working group, and the [CFRG][9]. [1]: https://datatracker.ietf.org/doc/charter-ietf-jose/02/ [2]: https://openid.net/connect/ [3]: https://www.ietf.org/blog/stir-action/ [4]: https://www.w3.org/2022/05/proposed-vc-wg-charter.html [5]: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ [6]: https://datatracker.ietf.org/wg/oauth/about/ [7]: https://datatracker.ietf.org/wg/privacypass/about/ [8]: https://datatracker.ietf.org/wg/cbor/about/ [9]: https://datatracker.ietf.org/rg/cfrg/about/ [10]: https://datatracker.ietf.org/wg/cose/about/ Goals and Milestones: Jan 2024 - Adopt document registering cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed (as proposed standard) Apr 2024 - Adopt document describing the use of the NIST algorithm ML-KEM in JOSE (as proposed standard) Apr 2024 - Adopt document describing the use of the NIST algorithm ML-DSA in JOSE (as proposed standard) Apr 2024 - Adopt document describing the use of the NIST algorithm SLH-DSA in JOSE (as proposed standard) Apr 2025 - Adopt document describing the use of the NIST algorithm FN-DSA in JOSE (as proposed standard) Internet-Drafts: - CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-cfrg-curves-06] (14 pages) - Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-cookbook-08] (120 pages) - Fully-Specified Algorithms for JOSE and COSE [draft-ietf-jose-fully-specified-algorithms-05] (28 pages) - Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-hpke-encrypt-01] (21 pages) - JSON Proof Algorithms [draft-ietf-jose-json-proof-algorithms-05] (43 pages) - JSON Proof Token [draft-ietf-jose-json-proof-token-05] (9 pages) - JSON Web Algorithms (JWA) [draft-ietf-jose-json-web-algorithms-40] (69 pages) - JSON Web Encryption (JWE) [draft-ietf-jose-json-web-encryption-40] (51 pages) - JSON Web Key (JWK) [draft-ietf-jose-json-web-key-41] (40 pages) - JSON Web Proof [draft-ietf-jose-json-web-proof-05] (24 pages) - JSON Web Signature (JWS) [draft-ietf-jose-json-web-signature-41] (59 pages) - JSON Web Key (JWK) Thumbprint [draft-ietf-jose-jwk-thumbprint-08] (13 pages) - JSON Web Signature (JWS) Unencoded Payload Option [draft-ietf-jose-jws-signing-input-options-09] (11 pages) - Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) [draft-ietf-jose-use-cases-06] (25 pages) - JSON Proof Algorithms [draft-jmiller-jose-json-proof-algorithms-01] (28 pages) - JSON Proof Token [draft-jmiller-jose-json-proof-token-01] (7 pages) - JSON Web Proof [draft-jmiller-jose-json-web-proof-01] (21 pages) - Fully-Specified Algorithms for JOSE and COSE [draft-jones-jose-fully-specified-algorithms-02] (11 pages) - JWS Signing Input Options [draft-jones-jose-jws-signing-input-options-00] (11 pages) - Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE [draft-reddy-cose-jose-pqc-kem-03] (19 pages) - Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) [draft-rha-jose-hpke-encrypt-07] (19 pages) - Guidance for COSE and JOSE Protocol Designers and Implementers [draft-tschofenig-jose-cose-guidance-01] (6 pages) Requests for Comments: RFC7165: Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) (25 pages) RFC7515: JSON Web Signature (JWS) (59 pages) RFC7516: JSON Web Encryption (JWE) (51 pages) RFC7517: JSON Web Key (JWK) (40 pages) RFC7518: JSON Web Algorithms (JWA) (69 pages) RFC7520: Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) (120 pages) RFC7638: JSON Web Key (JWK) Thumbprint (13 pages) RFC7797: JSON Web Signature (JWS) Unencoded Payload Option (11 pages) RFC8037: CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) (14 pages) Key Transparency (keytrans) --------------------------- Charter Last Modified: 2024-07-22 Current Status: Active Chairs: Prachi Jain Shivan Kaul Sahib Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: keytrans@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/keytrans Archive: https://mailarchive.ietf.org/arch/browse/keytrans/ Description of Working Group: ## Background Public keys used to provide end-to-end encrypted communication services are often authenticated solely by the assertion of the communications service provider (e.g., a video conferencing or instant messaging service providers). As a result, the underlying encryption protocols are left vulnerable to eavesdropping and impersonation by a service provider which distributes malicious public keys. To provide confidence to their users and to mitigate this attack, end-to-end encrypted communication service providers are increasingly looking to an authentication service to provide verifiability for identity-to-public-key bindings in the context of their service. A scheme for providing this verifiability of key bindings must be: * Transparent: All end users (applications or devices) receive a globally consistent view of the data associated with each identity. * User-friendly: Little (ideally zero) user action, or even awareness of the system, is required to verify a user’s key bindings. * Private: The authentication service used by the service provider only reveals information about specific users, such as what keys are associated with an identity, or even whether or not a specific identity is registered by the service provider, to clients authorized to ask about that user * Efficient: The computational requirements for the end user and the service provider should be practical to deploy for internet scale numbers of keys and for typical end-user devices. ## Goals The KEYTRANS working group will develop a standard for providing verifiability for identity-to-public-key bindings in an authentication service for an end-to-end encrypted communication service. This standard will: * Allow an end-user to search and download the public keys of themselves or for other end-users; and enable a process for updating their public key with the authentication service of the communication service provider * Allow end-users to verify on an ongoing basis that they have a globally consistent view of which public keys have been associated with which accounts, including their own. * Allow end-users to perform this verification of a globally consistent view via an out-of-band mechanism for small groups, or use an anonymous check with the communication service provider in-band for larger groups. This standardized approach is not stand-alone and will need to be integrated into other, more complete end-to-end protocols and services. It is not the goal of this WG to enable interoperability between end-to-end encrypted services as full interoperability of an application would require alignment at many different layers beyond security. ## Program of Work The WG is expected to: * Specify an architecture for this public verifiability mechanism (as an informational status document(s)) * Standardize the core scheme for providing verifiability for identity-to-public-key bindings in an authentication service for an end-to-end encrypted communication service (as a proposed standard document(s)) The WG may standardize integrations of this verifiability mechanism with other protocols (where the exact security guarantees provided will depend on the underlying encryption) The WG will work collaboratively with the MIMI, MLS and SCITT WGs as appropriate. Goals and Milestones: Dec 2023 - Initial WG adoption of an architecture document Mar 2024 - Initial WG adoption of core transparent verifiability mechanism document Jul 2024 - Initial WG adoption of MLS integration document Mar 2025 - Submit architecture document to the IESG as Informational Nov 2025 - Submit core transparent verifiability mechanism document to IESG as Proposed Standard Nov 2025 - Submit MLS integration document to IESG as Proposed Standard Internet-Drafts: - Key Transparency Architecture [draft-ietf-keytrans-architecture-02] (23 pages) - Key Transparency Architecture [draft-mcmillion-keytrans-architecture-01] (13 pages) No Requests for Comments Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2023-05-02 Current Status: Active Chairs: Alexey Melnikov Benjamin Kaduk Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: https://mailarchive.ietf.org/arch/browse/kitten/ Description of Working Group: The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API and to the Kerberos authentication system, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This charter combines the work of the Kerberos WG and the kitten WG (under the aegis of the kitten WG). In places, it identifies which WG was previously home for that work. The working group will develop extensions and/or updates to the GSS-API, working on specific items regarding credential management, replay cache avoidance, error reporting, and supporting stateless and/or distributed acceptors. The working group will also maintain and improve upon the Kerberos protocol, working on items regarding internationalization considering alignment with the precis work, new initial authentication types, authorization framework/data, replay cache avoidance, cryptography advances, interop with 3rd party authentication, and identity management. In detail, both existing and new work items include: Existing Working Group Items --------------------------- SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) KDC Model (draft-ietf-krb-wg-kdc-model) PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) GSS-API Related --------------- Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials Negotiable replay cache avoidance Define interfaces for better error message reporting. Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. Specify one-time password / two-factor authentication needs for SASL applications. This could be achieved through an explicit new GSS-API/SASL mechanism (e.g., http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if the consensus is that due to usability reasons, it is preferable to do OTP/2FA through an higher level protocol (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining the usability problem and provide pointers for implementers. Kerberos Related ---------------- Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-ietf-krb-wg-pad may be standardized. Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in the Kerberos protocol using the RFC3961 framework, on an ongoing basis. Cryptographic algorithms intended for standards track status must be of good quality, have broad international support, and fill a definite need. Prepare, review, and advance standards-track and informational specifications of new pre-authentication types for the Kerberos protocol, on an ongoing basis. Prepare, review, and advance standards track updates and extensions to RFC4121, as needed and on an ongoing basis. Goals and Milestones: May 2013 - draft-ietf-kitten-gssapi-extensions-iana to IESG Jun 2013 - draft-ietf-kitten-kerberos-iana-registries to IESG Jun 2013 - draft-ietf-krb-wg-pad to IESG Jul 2013 - Adopt work on better error reporting in the GSS-API Jul 2013 - Adopt work on one or more items for GSS-API cred management Aug 2013 - Adopt work on exporting partially-established GSS-API contexts Aug 2013 - draft-ietf-krb-wg-ticket-extensions to IESG Sep 2013 - Adopt work on the GSS-API for replay cache avoidance Mar 2022 - Submit "SPAKE Pre-Authentication" document to IESG Apr 2022 - Decide on preferred solution(s) for 2-Factor Authentication in SASL Oct 2022 - Submit document on 2-Factor Authentication in SASL to IESG Nov 2022 - Submit "Best practices for password hashing and storage" to IESG Dec 2022 - draft-ietf-kitten-sasl-saml-ec to IESG Done - draft-ietf-kitten-sasl-oauth to IESG Done - draft-ietf-krb-wg-cammac to IESG Done - draft-ietf-krb-wg-pkinit-alg-agility to IESG Done - Submit "Channel Bindings for TLS 1.3" to IESG Internet-Drafts: - The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism [draft-ietf-kitten-2478bis-05] (22 pages) - AES Encryption with HMAC-SHA2 for Kerberos 5 [draft-ietf-kitten-aes-cbc-hmac-sha2-00] (15 pages) - AES Encryption with HMAC-SHA2 for Kerberos 5 [draft-ietf-kitten-aes-cts-hmac-sha2-11] (19 pages) - Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) [draft-ietf-kitten-cammac-04] (10 pages) - Channel Binding Signalling for the Generic Security Services Application Programming Interface [draft-ietf-kitten-channel-bound-flag-04] (9 pages) - Moving DIGEST-MD5 to Historic [draft-ietf-kitten-digest-to-historic-04] (6 pages) - Extended Generic Security Service Mechanism Inquiry APIs [draft-ietf-kitten-extended-mech-inquiry-06] (16 pages) - Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings [draft-ietf-kitten-gssapi-channel-bindings-07] (4 pages) - GSS_API V2: C# Bindings [draft-ietf-kitten-gssapi-csharp-bindings-00] (95 pages) - Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type [draft-ietf-kitten-gssapi-domain-based-names-06] (9 pages) - Namespace Considerations and Registries for GSS-API Extensions [draft-ietf-kitten-gssapi-extensions-iana-11] (13 pages) - Generic Security Service Application Programming Interface (GSS-API) Naming Extensions [draft-ietf-kitten-gssapi-naming-exts-15] (18 pages) - A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) [draft-ietf-kitten-gssapi-prf-07] (8 pages) - GSS-API V2: Java & C# Bindings [draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00] (10 pages) - Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials [draft-ietf-kitten-gssapi-store-cred-04] (7 pages) - Guide to the GSS-APIv3 [draft-ietf-kitten-gssapi-v3-guide-to-01] (22 pages) - Structure of the Generic Security Service (GSS) Negotiation Loop [draft-ietf-kitten-gss-loop-05] (21 pages) - Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming [draft-ietf-kitten-gss-naming-05] (12 pages) - A Simple Anonymous GSS-API Mechanism [draft-ietf-kitten-gss-sanon-01] (11 pages) - Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) [draft-ietf-kitten-iakerb-03] (13 pages) - Move Kerberos protocol parameter registries to IANA [draft-ietf-kitten-kerberos-iana-registries-04] (9 pages) - Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [draft-ietf-kitten-krb5-gssapi-domain-based-names-05] (5 pages) - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism [draft-ietf-kitten-krb5-gssapi-prf-04] (5 pages) - Authentication Indicator in Kerberos Tickets [draft-ietf-kitten-krb-auth-indicator-07] (6 pages) - Kerberos Service Discovery using DNS [draft-ietf-kitten-krb-service-discovery-00] (9 pages) - Kerberos SPAKE Pre-Authentication [draft-ietf-kitten-krb-spake-preauth-13] (37 pages) - Best practices for password hashing and storage [draft-ietf-kitten-password-storage-07] (13 pages) - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility [draft-ietf-kitten-pkinit-alg-agility-08] (21 pages) - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension [draft-ietf-kitten-pkinit-freshness-07] (9 pages) - Generic Security Service API Version 2: Java Bindings Update [draft-ietf-kitten-rfc2853bis-05] (99 pages) - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism [draft-ietf-kitten-rfc4402bis-02] (8 pages) - Generic Security Service API Version 2: Java Bindings Update [draft-ietf-kitten-rfc5653bis-07] (96 pages) - Anonymity Support for Kerberos [draft-ietf-kitten-rfc6112bis-03] (18 pages) - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth [draft-ietf-kitten-sasl-oauth-23] (21 pages) - A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID [draft-ietf-kitten-sasl-openid-08] (18 pages) - A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) [draft-ietf-kitten-sasl-saml-09] (22 pages) - SAML Enhanced Client SASL and GSS-API Mechanisms [draft-ietf-kitten-sasl-saml-ec-20] (34 pages) - Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication [draft-ietf-kitten-scram-2fa-04] (12 pages) - Stackable Generic Security Service Pseudo-Mechanisms [draft-ietf-kitten-stackable-pseudo-mechs-02] (17 pages) - Channel Bindings for TLS 1.3 [draft-ietf-kitten-tls-channel-bindings-for-tls13-16] (7 pages) - Kerberos Authorization Data Container Authenticated by Multiple MACs [draft-ietf-krb-wg-cammac-11] (9 pages) - PKINIT Algorithm Agility [draft-ietf-krb-wg-pkinit-alg-agility-07] (18 pages) - Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication [draft-melnikov-scram-2fa-03] (7 pages) - Best practices for password hashing and storage [draft-whited-kitten-password-storage-04] (13 pages) - Channel Bindings for SCRAM over TLS 1.3 [draft-whited-tls-channel-bindings-for-tls13-02] (5 pages) Requests for Comments: RFC4178: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (22 pages) RFC4401: A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) (8 pages) RFC4402: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (5 pages) * Obsoletes RFC7802 RFC4768: Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming (12 pages) RFC5178: Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type (9 pages) RFC5179: Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (5 pages) RFC5554: Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings (4 pages) RFC5587: Extended Generic Security Service Mechanism Inquiry APIs (16 pages) RFC5588: Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials (7 pages) RFC5653: Generic Security Service API Version 2: Java Bindings Update (99 pages) * Obsoletes RFC8353 RFC6331: Moving DIGEST-MD5 to Historic (6 pages) RFC6595: A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) (22 pages) RFC6616: A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID (18 pages) RFC6680: Generic Security Service Application Programming Interface (GSS-API) Naming Extensions (18 pages) RFC7546: Structure of the Generic Security Service (GSS) Negotiation Loop (21 pages) RFC7628: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth (21 pages) RFC7751: Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) (10 pages) RFC7802: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (8 pages) RFC8009: AES Encryption with HMAC-SHA2 for Kerberos 5 (19 pages) RFC8062: Anonymity Support for Kerberos (18 pages) RFC8070: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension (9 pages) RFC8129: Authentication Indicator in Kerberos Tickets (6 pages) RFC8353: Generic Security Service API Version 2: Java Bindings Update (96 pages) RFC8636: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility (21 pages) RFC9266: Channel Bindings for TLS 1.3 (7 pages) RFC9588: Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre-authentication (33 pages) Lightweight Authenticated Key Exchange (lake) --------------------------------------------- Charter Last Modified: 2024-08-01 Current Status: Active Chairs: Mališa Vučinić Stephen Farrell Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: lake@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lake Archive: https://mailarchive.ietf.org/arch/browse/lake/ Description of Working Group: EDHOC (draft-ietf-lake-edhoc), an output of the LAKE working group, defines a lightweight authenticated key exchange protocol between two peers. EDHOC is intended to be used in constrained network environments such as NB-IoT, 6TiSCH and LoRaWAN. By publishing EDHOC, the base protocol specification, and the lake-traces document, the LAKE working group has completed its initial goals. The working group will continue to work on maintaining and extending the base protocol specification as appropriate. The initial design scope of EDHOC ruled out authentication based on pre-shared symmetric keys and focused on asymmetric authentication credentials (e.g., raw public keys and public key certificates) in order to streamline the working group activities. Similarly, the base protocol specification does not define a protocol for rekeying but rather a rekeying function to use as an inner building block for key update. The working group now will define a Standards Track EDHOC rekeying protocol reusing the protocol elements from the base specification that uses symmetric keys for authentication, to make those usable both during a key update and a first-time key exchange. Within each protocol message, EDHOC provides External Authorization Data (EAD) fields. These fields may be used by external security applications to reduce the number of messages and round trips, or to simplify processing. The working group will specify Standards Track documents with the following uses of EAD fields to augment the EDHOC key exchange: - 3rd party-assisted authorization of EDHOC peers. Draft-selander-lake-authz is a candidate starting point for this work. - Remote attestation of EDHOC peers, reusing as much as possible available work from the RATS and TLS working groups. - Status verification of EDHOC peer authentication credentials transported during an EDHOC key exchange (e.g. OCSP stapling). The working group will also work on a Standard Track means for coordinating the use and discovery of EDHOC application profiles, the definition of a well-known application profile and processing extensions through EDHOC’s defined extension points, such as registering new schemes and new EAD registrations. In addition, the working group will work on an Informational document gathering implementation considerations and guidance for the base protocol specification. Goals and Milestones: Jun 2024 - Implementation considerations and guidance submitted to IESG as Informational RFC Jun 2024 - 3rd party-assisted authorization of EDHOC submitted to IESG as Proposed Standard Nov 2024 - EDHOC rekeying protocol submitted to IESG as Proposed Standard Nov 2024 - Remote attestation of EDHOC peers submitted to IESG as Proposed Standard Mar 2025 - Verification of EDHOC authentication credentials submitted to IESG as Proposed Standard Internet-Drafts: - Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE [draft-ietf-lake-authz-02] (36 pages) - Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-ietf-lake-edhoc-23] (113 pages) - Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-ietf-lake-edhoc-impl-cons-01] (32 pages) - Requirements for a Lightweight AKE for OSCORE [draft-ietf-lake-reqs-04] (25 pages) - Traces of EDHOC [draft-ietf-lake-traces-09] (61 pages) - Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE [draft-selander-lake-authz-03] (28 pages) - Requirements for a Lightweight AKE for OSCORE [draft-selander-lake-reqs-04] (19 pages) - Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-tiloca-lake-edhoc-implem-cons-01] (25 pages) Requests for Comments: RFC9528: Ephemeral Diffie-Hellman Over COSE (EDHOC) (82 pages) RFC9529: Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) (62 pages) Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Russ Housley Tim Hollebeek Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: spasm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Description of Working Group: The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of such machine-to-machine scenarios and communication among PKI management entities. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. This work will be coordinated with the LWIG WG. 4. Provide concrete guidance for implementers of email user agents to promote interoperability of end-to-end cryptographic protection of email messages. This may include guidance about the generation, interpretation, and handling of protected messages; management of the relevant certificates; documentation of how to avoid common failure modes; strategies for deployment in a mixed environment; as well as test vectors and examples that can be used by implementers and interoperability testing. The resulting robust consensus among email user agent implementers is expected to provide more usable and useful cryptographic security for email users. 5. Recent progress in the development of quantum computers pose a threat to widely deployed public key algorithms. As a result, there is a need to prepare for a day when cryptosystems such as RSA, Diffie-Hellman, ECDSA, ECDH, and EdDSA cannot be depended upon in the PKIX and S/MIME protocols. 5.a. The US National Institute of Standards and Technology (NIST) has a Post-Quantum Cryptography (PQC) effort to produce one or more quantum-resistant public-key cryptographic algorithm standards. The LAMPS WG will specify the use of these new PQC public key algorithms with the PKIX certificates and the Cryptographic Message Syntax (CMS). These specifications will use object identifiers for the new algorithms that are assigned by NIST. 5.b. A lengthy transition from today's public key algorithms to PQC public key algorithms is expected. Time will be needed to gain full confidence in the new PQC public key algorithms. 5.b.i. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "hybrid key establishment" that combines the shared secret values one or more traditional key-establishment algorithm and one or more NIST PQC key-establishment algorithm or a PQC key-establishment algorithm vetted by the CFRG. The shared secret values will be combined using HKDF (see RFC 5869), one of the key derivation functions in NIST SP 800-56C, or a key derivation function vetted by the CFRG. 5.b.ii. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "dual signature" that combine one or more traditional signature algorithm with one or more NIST PQC signature algorithm or a PQC algorithm vetted by the CFRG. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. Goals and Milestones: Jul 2021 - Adopt a draft for short-lived certificate conventions Oct 2021 - Adopt draft for PQC KEM public keys in PKIX certificates Oct 2021 - Adopt draft for PQC KEM algorithms in CMS Nov 2021 - Header protection conventions sent to IESG for standards track publication Dec 2021 - Adopt draft for PQC signatures in CMS Dec 2021 - CMP updates sent to IESG for standards track publication Dec 2021 - Lightweight CMP profile sent to IESG for informational publication Dec 2021 - Adopt draft for PQC signatures in PKIX certificates Dec 2021 - Adopt draft for public keys for hybrid key establishment in PKIX certificates Dec 2021 - Adopt draft for hybrid key establishment in CMS Dec 2021 - Adopt draft for dual signatures in PKIX certificates Dec 2021 - Adopt draft for dual signature in CMS Dec 2021 - CMP algorithms sent to IESG for standards track publication Mar 2022 - Short-lived certificate conventions sent to IESG for BCP publication Jul 2022 - End-to-end email user agent guidance sent to IESG for informational publication Dec 2022 - Send draft for rfc6712bis to IESG for standards track publication Dec 2022 - Send draft for rfc4210bis to IESG for standards track publication Done - Adopt a draft for end-to-end email user agent guidance Done - Adopt draft for rfc6712bis Done - Adopt draft for rfc4210bis Internet-Drafts: - Related Certificates for Use in Multiple Authentications within a Protocol [draft-becker-guthrie-cert-binding-for-multi-auth-02] (14 pages) - Certification Authority Authorization (CAA) Processing for Email Addresses [draft-bonnell-caa-issuemail-01] (7 pages) - Updates to Lightweight OCSP Profile for High Volume Environments [draft-bonnell-rfc5019bis-03] (18 pages) - Guidance on End-to-End E-mail Security [draft-dkg-lamps-e2e-mail-guidance-01] (25 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS [draft-gazdag-x509-shbs-00] (15 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA [draft-gazdag-x509-slhdsa-00] (16 pages) - DNS Certification Authority Authorization (CAA) Resource Record [draft-hoffman-andrews-caa-simplification-03] (19 pages) - Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) [draft-housley-lamps-cms-aes-mac-alg-00] (7 pages) - Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256 [draft-housley-lamps-cms-cek-hkdf-sha256-01] (14 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-housley-lamps-cms-update-alg-id-protect-00] (8 pages) - Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [draft-housley-lamps-crmf-update-algs-01] (4 pages) - Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) [draft-housley-lamps-rfc5990bis-00] (23 pages) - Online Certificate Status Protocol (OCSP) Nonce Extension [draft-hsharma-lamps-ocsp-nonce-update-06] (5 pages) - Clarifications for Elliptic Curve Cryptography Subject Public Key Information [draft-ietf-lamps-5480-ku-clarifications-03] (3 pages) - X.509 Certificate Extension for 5G Network Function Types [draft-ietf-lamps-5g-nftypes-08] (11 pages) - Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers [draft-ietf-lamps-8410-ku-clarifications-02] (5 pages) - Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) [draft-ietf-lamps-attestation-freshness-01] (14 pages) - Certification Authority Authorization (CAA) Processing for Email Addresses [draft-ietf-lamps-caa-issuemail-07] (8 pages) - Related Certificates for Use in Multiple Authentications within a Protocol [draft-ietf-lamps-cert-binding-for-multi-auth-05] (15 pages) - Certificate Management Protocol (CMP) Algorithms [draft-ietf-lamps-cmp-algorithms-15] (28 pages) - Certificate Management Protocol (CMP) Updates [draft-ietf-lamps-cmp-updates-23] (55 pages) - Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-aes-gmac-alg-05] (9 pages) - Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256 [draft-ietf-lamps-cms-cek-hkdf-sha256-04] (14 pages) - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-hash-sig-10] (14 pages) - Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-kemri-08] (17 pages) - Use of ML-KEM in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-kyber-04] (17 pages) - Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-mix-with-psk-07] (31 pages) - Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-sha3-hash-04] (20 pages) - Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-shakes-18] (16 pages) - Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-sphincs-plus-09] (18 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-ietf-lamps-cms-update-alg-id-protect-05] (8 pages) - Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [draft-ietf-lamps-crmf-update-algs-07] (9 pages) - Use of Remote Attestation with Certification Signing Requests [draft-ietf-lamps-csr-attestation-10] (41 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA [draft-ietf-lamps-dilithium-certificates-04] (16 pages) - X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing [draft-ietf-lamps-documentsigning-eku-06] (8 pages) - Guidance on End-to-End E-mail Security [draft-ietf-lamps-e2e-mail-guidance-16] (67 pages) - Internationalized Email Addresses in X.509 Certificates [draft-ietf-lamps-eai-addresses-18] (12 pages) - Hash Of Root Key Certificate Extension [draft-ietf-lamps-hash-of-root-key-cert-extn-07] (10 pages) - Header Protection for Cryptographically Protected E-mail [draft-ietf-lamps-header-protection-24] (269 pages) - Problem Statement and Requirements for Header Protection [draft-ietf-lamps-header-protection-requirements-01] (24 pages) - X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs [draft-ietf-lamps-im-keyusage-00] (5 pages) - Key Attestation Extension for Certificate Management Protocols [draft-ietf-lamps-key-attestation-ext-00] (14 pages) - Use of KYBER in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-kyber-00] (16 pages) - Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) [draft-ietf-lamps-kyber-certificates-03] (10 pages) - Lightweight Certificate Management Protocol (CMP) Profile [draft-ietf-lamps-lightweight-cmp-profile-21] (83 pages) - X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions [draft-ietf-lamps-nf-eku-05] (11 pages) - No Revocation Available for X.509 Public Key Certificates [draft-ietf-lamps-norevavail-04] (10 pages) - Online Certificate Status Protocol (OCSP) Nonce Extension [draft-ietf-lamps-ocsp-nonce-05] (6 pages) - Online Certificate Status Protocol (OCSP) Nonce Extension [draft-ietf-lamps-ocsp-nonce-update-11] (14 pages) - Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax [draft-ietf-lamps-pkcs12-pbmac1-09] (17 pages) - Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs [draft-ietf-lamps-pkix-shake-15] (14 pages) - Composite ML-KEM for Use in the Internet X.509 Public Key Infrastructure and CMS [draft-ietf-lamps-pq-composite-kem-04] (42 pages) - Composite ML-DSA for use in Internet PKI [draft-ietf-lamps-pq-composite-sigs-02] (51 pages) - Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates [draft-ietf-lamps-rfc3709bis-10] (39 pages) - Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) [draft-ietf-lamps-rfc4210bis-13] (140 pages) - Updates to Lightweight OCSP Profile for High Volume Environments [draft-ietf-lamps-rfc5019bis-12] (36 pages) - Certificate Management over CMS (CMC) [draft-ietf-lamps-rfc5272bis-00] (100 pages) - Certificate Management over CMS (CMC): Transport Protocols [draft-ietf-lamps-rfc5273bis-00] (9 pages) - Certificate Management Messages over CMS (CMC): Compliance Requirements [draft-ietf-lamps-rfc5274bis-00] (14 pages) - Internationalization Updates to RFC 5280 [draft-ietf-lamps-rfc5280-i18n-update-04] (9 pages) - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling [draft-ietf-lamps-rfc5750-bis-08] (29 pages) - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification [draft-ietf-lamps-rfc5751-bis-12] (63 pages) - Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-rfc5990bis-10] (33 pages) - Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) [draft-ietf-lamps-rfc6712bis-06] (13 pages) - DNS Certification Authority Authorization (CAA) Resource Record [draft-ietf-lamps-rfc6844bis-07] (17 pages) - Clarification and enhancement of RFC7030 CSR Attributes definition [draft-ietf-lamps-rfc7030-csrattrs-12] (23 pages) - Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 [draft-ietf-lamps-rfc7030est-clarify-10] (13 pages) - Update to the Object Identifier Registry for the PKIX Working Group [draft-ietf-lamps-rfc7299-update-02] (4 pages) - Internationalized Email Addresses in X.509 Certificates [draft-ietf-lamps-rfc8398bis-05] (14 pages) - Internationalization Updates to RFC 5280 [draft-ietf-lamps-rfc8399bis-05] (11 pages) - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-rfc8708bis-02] (16 pages) - Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax [draft-ietf-lamps-rfc9579bis-00] (17 pages) - S/MIME Example Keys and Certificates [draft-ietf-lamps-samples-08] (32 pages) - Updates to X.509 Policy Validation [draft-ietf-lamps-x509-policy-graph-05] (22 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS [draft-ietf-lamps-x509-shbs-04] (33 pages) - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA [draft-ietf-lamps-x509-slhdsa-01] (15 pages) - General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates [draft-ito-documentsigning-eku-02] (8 pages) - X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs [draft-mahy-lamps-im-keyusage-01] (5 pages) - Certificate Management over CMS (CMC) [draft-mandel-lamps-rfc5272bis-02] (99 pages) - Certificate Management over CMS (CMC): Transport Protocols [draft-mandel-lamps-rfc5273bis-02] (9 pages) - Certificate Management Messages over CMS (CMC): Compliance Requirements [draft-mandel-lamps-rfc5274bis-02] (14 pages) - Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers [draft-mtis-lamps-8410-ku-clarifications-01] (5 pages) - Use of Attestation with Certification Signing Requests [draft-ounsworth-csr-attestation-00] (15 pages) - Composite KEM For Use In Internet PKI [draft-ounsworth-pq-composite-kem-02] (22 pages) - Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS) [draft-perret-prat-lamps-cms-pq-kem-01] (15 pages) - X.509 Certificate Extended Key Usage (EKU) for (JOSE) and CBOR Object Signing and Encryption (COSE) [draft-reddy-lamps-jose-eku-02] (11 pages) - Clarification of RFC7030 CSR Attributes definition [draft-richardson-lamps-rfc7030-csrattrs-04] (7 pages) - Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 [draft-richardson-lamps-rfc7030est-clarify-05] (10 pages) - Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) [draft-tschofenig-lamps-nonce-cmp-est-01] (12 pages) - Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information [draft-turner-5480-ku-clarifications-01] (3 pages) - Key Attestation Extension for Certificate Management Protocols [draft-wallace-lamps-key-attestation-ext-01] (14 pages) Requests for Comments: RFC8398: Internationalized Email Addresses in X.509 Certificates (12 pages) * Obsoletes RFC9598 RFC8399: Internationalization Updates to RFC 5280 (9 pages) * Obsoletes RFC9549 RFC8550: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling (29 pages) RFC8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification (63 pages) RFC8649: Hash Of Root Key Certificate Extension (10 pages) RFC8659: DNS Certification Authority Authorization (CAA) Resource Record (17 pages) RFC8692: Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs (14 pages) RFC8696: Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) (31 pages) RFC8702: Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) (16 pages) RFC8708: Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) (14 pages) RFC8813: Clarifications for Elliptic Curve Cryptography Subject Public Key Information (3 pages) RFC8933: Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection (8 pages) RFC8951: Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 (13 pages) RFC8954: Online Certificate Status Protocol (OCSP) Nonce Extension (6 pages) * Obsoletes RFC9654 RFC9044: Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) (9 pages) RFC9045: Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) (9 pages) RFC9158: Update to the Object Identifier Registry for the PKIX Working Group (4 pages) RFC9216: S/MIME Example Keys and Certificates (32 pages) RFC9295: Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers (5 pages) RFC9310: X.509 Certificate Extension for 5G Network Function Types (11 pages) RFC9336: X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing (8 pages) RFC9399: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates (39 pages) RFC9480: Certificate Management Protocol (CMP) Updates (55 pages) RFC9481: Certificate Management Protocol (CMP) Algorithms (28 pages) RFC9483: Lightweight Certificate Management Protocol (CMP) Profile (83 pages) RFC9495: Certification Authority Authorization (CAA) Processing for Email Addresses (8 pages) RFC9509: X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions (9 pages) RFC9549: Internationalization Updates to RFC 5280 (10 pages) RFC9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax (15 pages) RFC9598: Internationalized Email Addresses in X.509 Certificates (12 pages) RFC9608: No Revocation Available for X.509 Public Key Certificates (10 pages) RFC9618: Updates to X.509 Policy Validation (19 pages) RFC9629: Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) (15 pages) RFC9654: Online Certificate Status Protocol (OCSP) Nonce Extension (13 pages) Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2023-03-29 Current Status: Active Chairs: Luigi Iannone Padma Pillay-Esnault Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde 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: LISP supports an overlay routing architecture that decouples the routing locators and endpoint identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the endpoint space. LISP requires no changes to endpoints or routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol, so new features and services can be added easily and quickly to the network using overlays. The LISP WG is chartered to continue work on the LISP protocol, including minor extensions for which the working group has consensus on deeming them necessary for the use cases identified by the working group as main LISP applications. Such use cases have to be documented in an applicability document providing rationale for the work done. The working group will work on the following items: - Moving to Standard Track: The core specifications of LISP have been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of moving select specifications to “Standard Track” (e.g., LISP Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc). - Map Server Reliable Transport: LISP control plane messages are transported over UDP, however, in some cases, the use of a reliable transport protocol (such as TCP) is a better fit, since it actually helps reduce periodic signaling. - YANG Models: The management of LISP protocol and deployments including data models, OAM, as well as allowing for programmable management interfaces. - LISP for Traffic Engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers (RTRs) used to specify a path. - NAT-Traversal: LISP protocol extensions to support a NAT-traversal solution in deployments where LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). The LISP WG will collaborate with the TSVWG working on NAT-Traversal. - Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized. - LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced interworking, for instance by defining mechanisms to discover such external connectivity. - Mobility: Some LISP deployment scenarios include endpoints that move across different LISP xTRs and/or LISP xTRs that are themselves mobile. Support needs to be provided to achieve seamless connectivity. - LISP Applicability: LISP has proved to be a very flexible protocol that can be used in various use cases not considered during its design phase. [RFC7215], while remaining a good source of information, covers one single use case, which is no longer the main LISP application scenario. The LISP WG will document LISP deployments for the most recent and relevant use cases, so as to update and complement [RFC7215] as needed. Goals and Milestones: Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport) [STANDARDS TRACK] Mar 2024 - Submit LISP YANG model document to the IESG for consideration (YANG Models) [EXPERIMENTAL] Mar 2024 - Submit LISP Traffic Engineering document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal) [STANDARDS TRACK] Nov 2024 - Submit LISP DDT bis document to the IESG for consideration [STANDARDS TRACK] Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration [STANDARDS TRACK] Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG for consideration (Privacy and Security) [EXPERIMENTAL] Mar 2025 - Submit LISP External Connectivity document(s) to the IESG for consideration (LISP External Connectivity) [EXPERIMENTAL] Jul 2025 - Submit LISP Mobility document(s) to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2025 - Submit LISP Multicast document(s) to the IESG for consideration [STANDARDS TRACK] Mar 2026 - Submit LISP Applicability document(s) to the IESG for consideration (LISP Applicability) [INFORMATIONAL] Nov 2026 - Wrap-Up or recharter 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) - The Locator/ID Separation Protocol (LISP) for Multicast Environments [draft-farinacci-lisp-rfc6831bis-02] (31 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-farinacci-lisp-rfc8378bis-00] (22 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-13] (18 pages) - LISP EID Anonymity [draft-ietf-lisp-eid-anonymity-16] (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-14] (30 pages) - LISP Geo-Coordinate Use-Cases [draft-ietf-lisp-geo-08] (17 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-04] (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-15] (26 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-14] (14 pages) - Network-Hexagons:Geolocation Mapping Network Based On H3 and LISP [draft-ietf-lisp-nexagon-53] (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-14] (16 pages) - Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-pubsub-15] (18 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-rfc6830bis-38] (33 pages) - The Locator/ID Separation Protocol (LISP) for Multicast Environments [draft-ietf-lisp-rfc6831bis-00] (31 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) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-ietf-lisp-rfc8378bis-00] (22 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 Site External Connectivity [draft-ietf-lisp-site-external-connectivity-00] (7 pages) - LISP Traffic Engineering [draft-ietf-lisp-te-19] (20 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-12] (17 pages) - LISP YANG Model [draft-ietf-lisp-yang-21] (82 pages) - LISP Site External Connectivity [draft-jain-lisp-site-external-connectivity-09] (7 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) - LISP Multicast Overlay Group to Underlay RLOC Mappings [draft-vdas-lisp-group-mapping-03] (10 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) RFC9437: Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) (18 pages) Link State Routing (lsr) ------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Acee Lindem Christian Hopps Yingzhen Qu Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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: Sep 2023 - SUBMITTED: IS-IS Fast Flooding Dec 2023 - SUBMITTED: Dynamic Flooding on Dense Graphs Dec 2023 - SUBMITTED: Area Proxy for IS-IS Jan 2024 - SUBMITTED: YANG Model for OSPFv3 Extended LSAs Feb 2024 - WGLC: Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints Jan 2025 - UPNEXT: Extensions to OSPF for Advertising Prefix Administrative Tags Jan 2025 - UPNEXT: Multi-part TLVs in IS-IS Jan 2025 - IS-IS Segment Routing SR YANG Model Jan 2025 - OSPF Segment Routing YANG Model 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) - A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane [draft-ietf-isis-sr-yang-22] (33 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-07] (16 pages) - Updates to Anycast Property advertisement for OSPFv2 [draft-ietf-lsr-anycast-flag-00] (6 pages) - IS-IS Distributed Flooding Reduction [draft-ietf-lsr-distoptflood-06] (15 pages) - Dynamic Flooding on Dense Graphs [draft-ietf-lsr-dynamic-flooding-18] (48 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-14] (33 pages) - Flooding Topology Minimum Degree Algorithm [draft-ietf-lsr-flooding-topo-min-degree-09] (12 pages) - IGP Flexible Algorithms Reverse Affinity Constraint [draft-ietf-lsr-igp-flex-algo-reverse-affinity-03] (9 pages) - IGP Unreachable Prefix Announcement [draft-ietf-lsr-igp-ureach-prefix-announce-02] (14 pages) - IGP Flexible Algorithm in IP Networks [draft-ietf-lsr-ip-flexalgo-17] (21 pages) - Area Proxy for IS-IS [draft-ietf-lsr-isis-area-proxy-12] (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-11] (27 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-06] (25 pages) - Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) [draft-ietf-lsr-isis-sr-vtn-mt-08] (9 pages) - IS-IS Topology-Transparent Zone [draft-ietf-lsr-isis-ttz-09] (25 pages) - IS-IS YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-isis-yang-augmentation-v1-08] (36 pages) - Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values [draft-ietf-lsr-labv-registration-03] (3 pages) - Multi-part TLVs in IS-IS [draft-ietf-lsr-multi-tlv-05] (27 pages) - Extensions to OSPF for Advertising Prefix Administrative Tags [draft-ietf-lsr-ospf-admin-tags-21] (20 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) - Advertising Infinity Links in OSPF [draft-ietf-lsr-ospf-ls-link-infinity-00] (9 pages) - Prefix Flag Extension for OSPFv2 and OSPFv3 [draft-ietf-lsr-ospf-prefix-extended-flags-02] (10 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-06] (25 pages) - Update to OSPF Terminology [draft-ietf-lsr-ospf-terminology-09] (6 pages) - OSPF-GT (Generalized Transport) [draft-ietf-lsr-ospf-transport-instance-07] (15 pages) - YANG Model for OSPFv3 Extended LSAs [draft-ietf-lsr-ospfv3-extended-lsa-yang-29] (29 pages) - OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) [draft-ietf-lsr-ospfv3-srv6-extensions-15] (26 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-ospf-yang-augmentation-v1-13] (58 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] (21 pages) - OSPF Application-Specific Link Attributes [draft-ietf-lsr-rfc8920bis-06] (20 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) - A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane [draft-ietf-ospf-sr-yang-31] (49 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) - Multi-part TLVs in IS-IS [draft-pkaneria-lsr-multi-tlv-04] (25 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-08] (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) * Obsoletes RFC9479 RFC8920: OSPF Application-Specific Link Attributes (19 pages) * Obsoletes RFC9492 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) RFC9454: Update to OSPF Terminology (6 pages) RFC9479: IS-IS Application-Specific Link Attributes (21 pages) RFC9492: OSPF Application-Specific Link Attributes (20 pages) RFC9502: IGP Flexible Algorithm in IP Networks (21 pages) RFC9513: OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) (26 pages) RFC9587: YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs) (25 pages) RFC9650: Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values (3 pages) Link State Vector Routing (lsvr) -------------------------------- Charter Last Modified: 2024-05-01 Current Status: Active Chairs: Jie Dong Ketan Talaulikar Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde 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-12] (15 pages) - A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF [draft-ietf-lsvr-bgp-ls-yang-02] (51 pages) - BGP Link-State Shortest Path First (SPF) Routing [draft-ietf-lsvr-bgp-spf-33] (39 pages) - Layer-3 Discovery and Liveness [draft-ietf-lsvr-l3dl-12] (48 pages) - Layer-3 Discovery and Liveness Signing [draft-ietf-lsvr-l3dl-signing-06] (10 pages) - L3DL Upper-Layer Protocol Configuration [draft-ietf-lsvr-l3dl-ulpc-05] (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 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 State of Affairs [draft-ietf-madinas-mac-address-randomization-15] (19 pages) - Randomized and Changing MAC Address Use Cases [draft-ietf-madinas-use-cases-10] (19 pages) - MAC address randomization [draft-zuniga-madinas-mac-address-randomization-01] (15 pages) No Requests for Comments Mail Maintenance (mailmaint) ---------------------------- Charter Last Modified: 2024-08-28 Current Status: Active Chair: Kenneth Murchison Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mailmaint@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mailmaint Archive: https://mailarchive.ietf.org/arch/browse/mailmaint/ Description of Working Group: Internet Messaging (“email”) is one of the oldest applications still supported by the IETF. It consists of numerous layers and extensions that support the robust construction, transport, retrieval, and interpretation of messages. (For the purposes of this charter, “email” starts in RFC 5321 which covers transport and RFC 5322 which covers message format, and extends into specifications based on those documents and their antecedents. It also includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et seq].) From time to time, new work in the email space is brought to the IETF for consideration and development. Where there is enough critical mass to create a working group to develop and publish the work, this is the preferred case. More often, however, a proposal is brought that lacks enough critical mass to independently support chartering of a working group, but would still be useful to publish as a standard. Such projects must then either seek the assent of an Area Director willing to sponsor it as a standards track document, or support via the Independent Stream Editor (ISE) without standards track status. The MAILMAINT (“Mail Maintenance”) working group will consider projects in the email space that are too small to warrant construction of a dedicated working group. This will take advantage of a common community to consider these proposals rather than forming a series of disparate but related communities. Work proposed for MAILMAINT may arrive via direct proposals, or it may be referred via one or more DISPATCH-style working groups. Recorded Calls for Adoption are required for all work proposals. Proponents of work that is not taken up within the IETF may, of course, decide to bring their proposal to the Independent Stream. The working group should discuss such proposals with the ISE and share the results of the working group’s consideration. Further, MAILMAINT will observe the following constraints when considering the adoption of new work directly: * Prior to accepting any Standards Track document for development, there must be a commitment to implement the resulting proposed standard from at least two independent parties, as recorded on a related IETF mailing list. * When deciding to send any Standards Track work to the IESG, there must first be produced a report documenting at least two (preferably more) independent implementations with at least partial interoperation based on the developed specification. * The above constraints do not apply to documents that are not intended for the Standards Track. * Chartering of a dedicated working group with a custom charter is strongly preferred when engaging any work that updates any base email documents, including but not limited to those identified above. All work will be announced to appropriate non-WG lists such as ietf-822, ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Group Last Call begins. Standards work being taken up by MAILMAINT should be checked with other relevant areas (mainly Security) to confirm appropriate oversight or possible assignment to that area. Milestones will be used to track all approved work, including during chartering and rechartering. Goals and Milestones: Jul 2024 - Discuss where work on updating/clarifying SMTPUTF8 should be done Feb 2025 - WGLC on draft-ietf-mailmaint-wrong-recipient Feb 2025 - WGLC on draft-ietf-mailmaint-expires Done - Call For Adoption of draft-dweekly-wrong-recipient Done - Call for Adoption of draft-billon-expires Done - Call for Adoption of draft-bucksch-autoconfig Internet-Drafts: - Aggregate Reports for DKIM Signers [draft-brotman-dkim-aggregate-reporting-01] (11 pages) - Email Feedback Reports for DKIM Signers [draft-brotman-dkim-fbl-03] (11 pages) - Mail Autoconfig [draft-bucksch-autoconfig-04] (21 pages) - Adding a Wrong Recipient URL for Handling Misdirected Emails [draft-dweekly-wrong-recipient-06] (9 pages) - Nice Email Addresses for SMTPUTF8 [draft-gulbrandsen-smtputf8-nice-addresses-00] (12 pages) - Updated Use of the Expires Message Header Field [draft-ietf-mailmaint-expires-00] (6 pages) - Adding a Wrong Recipient URL for Handling Misdirected Emails [draft-ietf-mailmaint-wrong-recipient-00] (9 pages) - SMTP Service Extension for Client Identity [draft-storey-smtp-client-id-17] (16 pages) - IMAP Service Extension for Client Identity [draft-yu-imap-client-id-12] (13 pages) No Requests for Comments Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2024-05-21 Current Status: Active Chairs: Donald E. Eastlake 3rd Don Fedyk Ronald in 't Velt Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde 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 Radio Channel Utilization Extension [draft-ietf-manet-dlep-channel-utilization-00] (8 pages) - DLEP Credit-Based Flow Control Messages and Data Items [draft-ietf-manet-dlep-credit-flow-control-15] (19 pages) - DLEP DiffServ Aware Credit Window Extension [draft-ietf-manet-dlep-da-credit-extension-18] (6 pages) - DLEP IEEE 802.1Q Aware Credit Window Extension [draft-ietf-manet-dlep-ether-credit-extension-06] (7 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 Radio Band Extension [draft-ietf-manet-dlep-radio-band-00] (6 pages) - DLEP Radio Quality Extension [draft-ietf-manet-dlep-radio-quality-00] (7 pages) - DLEP Traffic Classification Data Item [draft-ietf-manet-dlep-traffic-classification-12] (14 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) Multiplexed Application Substrate over QUIC Encryption (masque) --------------------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Dennis Jackson Eric Kinnear Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Mailing Lists: General Discussion: masque@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/masque Archive: https://mailarchive.ietf.org/arch/browse/masque/ Description of Working Group: Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP. The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this functionality. MASQUE leverages the HTTP request/response semantics, multiplexes flows over streams, uses a unified congestion controller, encrypts flow metadata, and enables unreliable delivery suitable for UDP and IP-based applications. The MASQUE working group will now develop HTTP extensions, which might be specific to the HTTP version, to the core client-initiated CONNECT-UDP and CONNECT-IP functionality. Services that a proxy initiates without any prompt from a client are out of scope. Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps to make it easier to support new use cases or accommodate changes in the environment in which these protocols are deployed. The initial set of extensions will be in support of UDP listening, CONNECT-UDP proxying optimizations when the UDP traffic is QUIC, and tunneling of Ethernet packets. Additional extensions that provide missing functionality, improve performance, or otherwise ease deployability for use cases may be adopted where there are multiple implementation and/or deployment proponents. The intended status is Standards Track, but the WG may downgrade if it believes that is appropriate for the ultimate document maturity level. Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions that solely relate to generic proxying functionality, and are not specific to the core MASQUE documents, are out of scope. Specifying proxy server discovery mechanisms is out of scope. New congestion control and loss recovery algorithms are also out of scope. However, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE proxies, and may issue recommendations accordingly. The working group will consider how the protocols it defines might operate over versions of HTTP that use TCP rather than QUIC, for use when QUIC is unavailable. This might include defining alternative extensions specifically for use in these HTTP versions. IP multicast is out of scope. Designs need not explicitly preclude multicast, but they will not focus on multicast-specific features. Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and CCWG on congestion control and loss recovery considerations, and intarea for IP Proxying and Ethernet tunneling. Finally, it will coordinate with IEEE 802.3 to make sure Ethernet concepts are correctly represented. MASQUE is not intended to be a long-lived working group. Goals and Milestones: - Submit an extension for UDP listeners - Submit an extension for QUIC-aware proxying - Submit an extension for Ethernet over MASQUE Internet-Drafts: - IP Proxying Support for HTTP [draft-age-masque-connect-ip-01] (20 pages) - Requirements for a MASQUE Protocol to Proxy IP Traffic [draft-cms-masque-ip-proxy-reqs-01] (10 pages) - Proxying Ethernet in HTTP [draft-ietf-masque-connect-ethernet-04] (16 pages) - Proxying IP in HTTP [draft-ietf-masque-connect-ip-13] (37 pages) - Proxying UDP in HTTP [draft-ietf-masque-connect-udp-15] (16 pages) - Proxying Bound UDP in HTTP [draft-ietf-masque-connect-udp-listen-03] (15 pages) - HTTP Datagrams and the Capsule Protocol [draft-ietf-masque-h3-datagram-11] (14 pages) - Requirements for a MASQUE Protocol to Proxy IP Traffic [draft-ietf-masque-ip-proxy-reqs-03] (11 pages) - QUIC-Aware Proxying Using HTTP [draft-ietf-masque-quic-proxy-03] (37 pages) - QUIC-Aware Proxying Using HTTP [draft-pauly-masque-quic-proxy-06] (24 pages) - The CONNECT-UDP HTTP Method [draft-schinazi-masque-connect-udp-00] (7 pages) - Using QUIC Datagrams with HTTP/3 [draft-schinazi-masque-h3-datagram-04] (10 pages) Requests for Comments: RFC9297: HTTP Datagrams and the Capsule Protocol (14 pages) RFC9298: Proxying UDP in HTTP (16 pages) * Updates RFC9484 RFC9484: Proxying IP in HTTP (37 pages) MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2023-03-24 Current Status: Active Chairs: Greg Shepherd Lenny Giuliano Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari 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) - YANG Data Model for Automatic Multicast Tunneling [draft-ietf-mboned-amt-yang-02] (22 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-12] (13 pages) - Multicast YANG Data Model [draft-ietf-mboned-multicast-yang-model-11] (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-05] (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: 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 * Updates RFC9601 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) RFC9630: Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM) (12 pages) Media Type Maintenance (mediaman) --------------------------------- Charter Last Modified: 2024-05-30 Current Status: Active Chairs: A.J. Stein Harald T. Alvestrand Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele 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: Oct 2024 - Draft about handling multiple suffixes to the IESG for approval (BCP) Dec 2024 - Publish a reviewer’s checklist about Security Considerations in media type applications, either as an RFC or a wiki page Dec 2024 - Deliver any recommendations about future registration and queue management Jul 2025 - Deliver an updated media type registration procedures RFC Done - Publish any specific criteria or guidance for handling registration of future top-level media types, either as an RFC or a wiki page. Done - Registration of the "haptics" top-level type to the IESG for approval (Proposed Standard) Internet-Drafts: - The 'haptics' Top-level Media Type [draft-ietf-mediaman-haptics-05] (13 pages) - Allowing Community Registrations in the Standards Tree [draft-ietf-mediaman-standards-tree-01] (5 pages) - Media Type Suffixes [draft-ietf-mediaman-suffixes-08] (8 pages) - Guidelines for the Definition of New Top-Level Media Types [draft-ietf-mediaman-toplevel-06] (14 pages) - Allowing Community Registrations in the Standards Tree [draft-nottingham-mediaman-standards-tree-00] (5 pages) No Requests for Comments More Instant Messaging Interoperability (mimi) ---------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Alissa Cooper Tim Geoghegan Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Orie Steele 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 2024 - WG adoption of MIMI protocol specification Mar 2024 - WG adoption of architecture document for messaging interoperability Nov 2024 - WG adoption of specification for identifier naming conventions Nov 2024 - WG adoption of specification for user discovery mechanism Nov 2024 - WG adoption of user discovery requirements document (decision about whether to forward to IESG for publication to be made later, by WG consensus) Mar 2025 - Forward specification for identifier naming conventions to IESG Mar 2025 - Forward specification of MIMI protocol to IESG Mar 2025 - Forward specification for messaging content format to IESG Nov 2025 - Forward specification for user discovery mechanism to IESG Done - WG adoption of specification for messaging content format Internet-Drafts: - An Architecture for More Instant Messaging Interoperability (MIMI) [draft-barnes-mimi-arch-03] (16 pages) - An Architecture for More Instant Messaging Interoperability (MIMI) [draft-ietf-mimi-arch-00] (16 pages) - More Instant Messaging Interoperability (MIMI) message content [draft-ietf-mimi-content-04] (55 pages) - More Instant Messaging Interoperability (MIMI) using HTTPS and MLS [draft-ietf-mimi-protocol-01] (42 pages) - More Instant Messaging Interoperability (MIMI) message content [draft-mahy-mimi-content-02] (23 pages) - More Instant Messaging Interoperability (MIMI) using HTTPS and MLS [draft-ralston-mimi-protocol-02] (40 pages) No Requests for Comments Machine Learning for Audio Coding (mlcodec) ------------------------------------------- Charter Last Modified: 2023-07-26 Current Status: Active Chairs: Greg Maxwell Mo Zanaty Applications and Real-Time Area Directors: Murray Kucherawy Orie Steele Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mlcodec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mlcodec/ Archive: https://mailarchive.ietf.org/arch/browse/mlcodec/ Description of Working Group: Problem Statement The Opus codec (RFC 6716) was adopted by the IETF in 2012. Since then, speech and audio processing technology has made significant progress, thanks in large part to deep learning techniques. It is desirable to update the existing Opus codec to benefit from recent advances without breaking compatibility with RFC 6716. Opus has achieved a wide degree of interoperability by using in-band signaling to avoid negotiation failure. Implementing new coding technology within Opus would allow incremental compatible deployment of the updated specification, while preserving interoperability with the existing billions of Opus-enabled devices. In doing so, we wish to retain the original qualities that drove the original Opus development to develop codecs that (quoting from codec WG charter): 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. Objectives The goals of this working group are: 1) Improving the robustness to packet loss of Opus through efficient redundancy transmission 2) Improving the speech coding quality at low bitrates 3) Improving the music coding quality at low bitrates The working group may also consider other improvements to Opus. The group will only consider solutions that result in bitstreams that are forwards and backwards compatible with RFC6716, and thus decodable by any decoder. Although it is likely that machine learning will be required to meet the objectives above, classical solutions will also be considered if they can achieve similar performance. As was the case with the original codec WG, this work will primarily focus on interactive, real-time applications over the Internet and will ensure interoperability with existing IETF real-time protocols, including RTP, SIP/SDP, and WebRTC. Given the widespread deployment of WebRTC, ensuring that the work improves WebRTC experience is of particular importance. Other applications, such as non-real-time streaming will be considered too, but only so long as their requirements do not interfere with those of real-time applications. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, consistent with BCP 78 and BCP 79, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. Deliverables 1. A specification for a generic Opus extension mechanism that can be used not only for the other proposed deliverables, but can also sustain further extensions to Opus in the future. This document shall be a Proposed Standard document. 2. A specification for coding large amounts of very low bitrate redundancy information for the purpose of significantly improving the robustness of Opus to bursts of packet loss. This document shall be a Proposed Standard document. 3. A specification for improving the quality of SILK- and hybrid-coded speech through decoder changes, with and without side information provided by the encoder. This will be done in a way that does not affect interoperability between original and extended implementations. This document shall be a Proposed Standard document. 4. A specification for improving the quality of CELT-coded audio (both speech and music) through decoder changes, with and without side information provided by the encoder. This will be done in a way that does not affect interoperability between original and extended implementations. This document shall be a Proposed Standard document. Goals and Milestones: Dec 2023 - Submit generic Opus extension mechanism to the IESG as Proposed Standard. Mar 2024 - Submit specification for Opus resiliency against packet loss to the IESG as Proposed Standard. Jun 2024 - Submit specification for improving the quality SILK- and hybrid-coded speech to the IESG as Proposed Standard. Sep 2024 - Sunmit specification for improving the quality of CELT-coded audio to the IESG as Proposed Standard. Internet-Drafts: - Deep Audio Redundancy (DRED) Extension for the Opus Codec [draft-ietf-mlcodec-opus-dred-01] (22 pages) - Extension Formatting for the Opus Codec [draft-ietf-mlcodec-opus-extension-02] (7 pages) No Requests for Comments Messaging Layer Security (mls) ------------------------------ Charter Last Modified: 2022-05-04 Current Status: Active Chairs: Nick Sullivan Sean Turner Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Secretary: Katriel Cohn-Gordon Mailing Lists: General Discussion: mls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mls Archive: https://mailarchive.ietf.org/arch/browse/mls/ Description of Working Group: Several Internet applications have a need for group key establishment and message protection protocols with the following properties: o Message Confidentiality - Messages can only be read by members of the group o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with o Membership Authentication - Each participant can verify the set of members in the group o Asynchronicity - Keys can be established without any two participants being online at the same time o Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the group o Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the group o Scalability - Resource requirements have good scaling in the size of the group (preferably sub-linear) Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol for human-to-human(s) communication with the above security and deployment properties so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3). Humans are assumed to have access to one or more general-purpose computers. It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs. While authentication is a key goal of this working group, it is not the objective of this working group to develop new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications: o S/MIME - https://tools.ietf.org/html/rfc5751 o OpenPGP - https://tools.ietf.org/html/rfc4880 o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html o Double Ratchet - https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm The intent of this working group is to follow the pattern of TLS 1.3, with specification, implementation, and verification proceeding in parallel. By the time we arrive at RFC, we hope to have several interoperable implementations as well as a thorough security analysis. The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, and generalizing the design described in: o draft-omara-mls-architecture o draft-barnes-mls-protocol Note that consensus is required both for changes to the protocol mechanisms from these documents and retention of the mechanisms from them. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. Goals and Milestones: Done - Initial working group documents for architecture and key management Done - Initial working group document adopted for message protection Done - Submit architecture document to IESG as Informational Done - Submit key management protocol to IESG as Proposed Standard Done - Submit message protection protocol to IESG as Proposed Standard Internet-Drafts: - The Messaging Layer Security (MLS) Protocol [draft-barnes-mls-protocol-01] (37 pages) - The Messaging Layer Security (MLS) Architecture [draft-ietf-mls-architecture-15] (50 pages) - The Messaging Layer Security (MLS) Extensions [draft-ietf-mls-extensions-04] (30 pages) - The Messaging Layer Security (MLS) Federation [draft-ietf-mls-federation-03] (8 pages) - The Messaging Layer Security (MLS) Protocol [draft-ietf-mls-protocol-20] (132 pages) - Messaging Layer Security Architecture [draft-omara-mls-architecture-01] (16 pages) - The Messaging Layer Security (MLS) Federation [draft-omara-mls-federation-00] (8 pages) - The Messaging Layer Security (MLS) Extensions [draft-robert-mls-extensions-00] (6 pages) Requests for Comments: RFC9420: The Messaging Layer Security (MLS) Protocol (132 pages) Media OPerationS (mops) ----------------------- Charter Last Modified: 2023-03-30 Current Status: Active Chairs: Kyle Rose Leslie Daigle Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari 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-18] (18 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-07] (17 pages) Requests for Comments: RFC9317: Operational Considerations for Streaming Media (37 pages) Media Over QUIC (moq) --------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Alan Frindell Martin Duke Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker 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: - Common Catalog Format for moq-transport [draft-ietf-moq-catalogformat-01] (30 pages) - Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design [draft-ietf-moq-requirements-02] (27 pages) - Media over QUIC Transport [draft-ietf-moq-transport-05] (42 pages) No Requests for Comments Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2024-03-26 Current Status: Active Chairs: Nicolai Leymann Tarek Saad Tony Li Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Jim Guichard 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: Abandoned - Submit draft-ietf-mpls-seamless-mpls 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 - 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 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base 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 Textual Conventions for Multiprotocol Label Switching (MPLS) Management 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 - 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 a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard 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-tp-ring-protection for publication Done - Submit draft-ietf-mpls-gach-adv for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-retire-ach-tlv for publication Done - Submit draft-ietf-mpls-ldp-dod for publication Done - Submit draft-ietf-mpls-mldp-hsmp for publication Done - Submit draft-ietf-mpls-tp-mip-mep-map for publication Done - Submit draft-ietf-mpls-tp-rosetta-stone 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-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-extended-admin-group for publication Done - Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication Done - Submit draft-ietf-mpls-special-purpose-labels Done - Submit draft-ietf-mpls-ldp-applicability-label-adv for publication Done - Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication Done - Submit draft-ietf-mpls-psc-updates for publication Done - Submit draft-ietf-mpls-ldp-multi-topology for publication Done - Submit draft-ietf-mpls-deprecate-bgp-entropy-label for publication Done - Submit draft-ietf-mpls-smp-requirements 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-in-udp for publication Done - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Done - Submit draft-ietf-mpls-proxy-lsp-ping fpr publication Done - Submit draft-ietf-mpls-seamless-mcast for publication Done - Submit draft-ietf-mpls-ldp-ipv6 for publication Done - Submit draft-ietf-mpls-tp-oam-id-mib for publication Done - ** Progress draft-ietf-mpls-pim-sm-over-mldp to publication Done - ++ Progress draft-ietf-mpls-lsp-ping-registry to publication Done - Submit draft-ietf-mpls-lsp-ping-relay-reply for publication Done - ++ Progress draft-ietf-mpls-ldp-ip-pw-capability to publication Done - Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion Done - ++ Progress draft-ietf-mpls-ldp-ipv6 for publication to publication Done - Submit draft-ietf-mpls-mldp-node-protection for publication Done - Submit draft-ietf-mpls-lsp-ping-registry for publication Done - Submit draft-ietf-mpls-oam-ipv6-rao for publication Done - ++ Progress draft-ietf-mpls-seamless-mcast to publication Done - Submit draft-ietf-mpls-entropy-lsp-ping for publication Done - ++ Progress draft-ietf-mpls-proxy-lsp-ping to publication Done - ++ Progress draft-ietf-mpls-oam-ipv6-rao to publication Done - Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication Done - ++ Progress draft-ietf-mpls-in-udp to publication Done - Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication Done - Submit draft-ietf-mpls-ldp-mrt for publication Done - Submit draft-ietf-mpls-lsp-ping-lag-multipath for publication Done - Submit draft-ietf-mpls-tp-linear-protection-mib Done - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Moved to TEAS - Submit draft-ietf-mpls-te-express-path 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) - MPLS Network Actions for Transporting In Situ Operations, Administration, and Maintenance (IOAM) Data Fields and Direct Exporting [draft-gandhi-mpls-mna-ioam-dex-01] (14 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-09] (17 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-31] (12 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) - Avoiding Equal Cost Multipath Treatment in MPLS Networks [draft-ietf-mpls-ecmp-bcp-03] (8 pages) - MPLS Egress Protection Framework [draft-ietf-mpls-egress-protection-framework-07] (25 pages) - Egress Validation in Label Switched Path Ping and Traceroute Mechanisms [draft-ietf-mpls-egress-tlv-for-nil-fec-15] (13 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) - 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) - 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-18] (17 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) - 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) - 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-08] (10 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) - 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) - mLDP Extensions for Multi-Topology Routing [draft-ietf-mpls-mldp-multi-topology-09] (16 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-11] (74 pages) - MPLS Network Actions (MNA) Framework [draft-ietf-mpls-mna-fwk-10] (21 pages) - MPLS Network Action (MNA) Sub-Stack Solution [draft-ietf-mpls-mna-hdr-08] (28 pages) - Requirements for Solutions that Support MPLS Network Actions (MNA) [draft-ietf-mpls-mna-requirements-16] (12 pages) - Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data [draft-ietf-mpls-mna-usecases-13] (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) - YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth [draft-ietf-mpls-msd-yang-12] (15 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-08] (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) - 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 for Segment Routing Networks with MPLS Data Plane [draft-ietf-mpls-rfc6374-sr-11] (20 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-22] (28 pages) - Resilient MPLS Rings [draft-ietf-mpls-rmr-14] (20 pages) - Resilient MPLS Rings and Multicast [draft-ietf-mpls-rmr-multicast-00] (7 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) - 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) - 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) - Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks [draft-ietf-mpls-spring-inter-domain-oam-20] (27 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 for Segment Routing (SR) Path Segment Identifier with MPLS Data Planes [draft-ietf-mpls-spring-lsp-ping-path-sid-02] (17 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Plane [draft-ietf-mpls-sr-epe-oam-19] (18 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-14] (14 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) - 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) - 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 Network Actions for Network Resource Partition Selector [draft-li-mpls-mna-nrp-selector-01] (8 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) - Supporting In-Situ Operations, Administration, and Maintenance Direct Export Using MPLS Network Actions [draft-mb-mpls-ioam-dex-08] (10 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-06] (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) - 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-13] (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) - Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes [draft-xp-mpls-spring-lsp-ping-path-sid-09] (17 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: 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 * Updates RFC9570 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) RFC9570: Deprecating the Use of Router Alert in LSP Ping (9 pages) RFC9571: Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels (18 pages) RFC9612: Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs) (9 pages) RFC9613: Requirements for Solutions that Support MPLS Network Actions (MNAs) (10 pages) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2024-07-31 Current Status: Active Chairs: Kent Watsen Per Andersson Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Secretary: Reshad Rahman 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: Internet-Drafts: - YANG Groupings for QUIC clients and QUIC servers [draft-andersson-netconf-quic-client-server-00] (12 pages) - Using NETCONF over QUIC connection [draft-dai-netconf-quic-netconf-over-quic-06] (10 pages) - 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-06] (37 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) - External Trace ID for Configuration Tracing [draft-ietf-netconf-configuration-tracing-01] (17 pages) - YANG Data Types and Groupings for Cryptography [draft-ietf-netconf-crypto-types-34] (66 pages) - Subscription to Distributed Notifications [draft-ietf-netconf-distributed-notif-09] (22 pages) - YANG Groupings for HTTP Clients and HTTP Servers [draft-ietf-netconf-http-client-server-23] (35 pages) - An HTTPS-based Transport for YANG Notifications [draft-ietf-netconf-https-notif-15] (29 pages) - A YANG Data Model for a Keystore and Keystore Operations [draft-ietf-netconf-keystore-35] (55 pages) - List Pagination for YANG-driven Protocols [draft-ietf-netconf-list-pagination-04] (65 pages) - NETCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-nc-04] (13 pages) - RESTCONF Extensions to Support List Pagination [draft-ietf-netconf-list-pagination-rc-04] (16 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (28 pages) - NETCONF Client and Server Models [draft-ietf-netconf-netconf-client-server-37] (65 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-04] (6 pages) - Partial Lock Remote Procedure Call (RPC) for NETCONF [draft-ietf-netconf-partial-lock-11] (23 pages) - NETCONF Private Candidates [draft-ietf-netconf-privcand-04] (59 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-38] (57 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) - RESTCONF Extension to support Trace Context Headers [draft-ietf-netconf-restconf-trace-ctx-headers-01] (9 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-40] (152 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-26] (39 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-41] (158 pages) - NETCONF Extension to support Trace Context propagation [draft-ietf-netconf-trace-ctx-extension-01] (21 pages) - Transaction ID Mechanism for NETCONF [draft-ietf-netconf-transaction-id-06] (76 pages) - A YANG Data Model for a Truststore [draft-ietf-netconf-trust-anchors-28] (43 pages) - YANG Groupings for UDP Clients and UDP Servers [draft-ietf-netconf-udp-client-server-03] (12 pages) - UDP-based Transport for Configured Subscriptions [draft-ietf-netconf-udp-notif-14] (33 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) - Support of Versioning in YANG Notifications Subscription [draft-ietf-netconf-yang-notifications-versioning-05] (26 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) - Augmented-by Addition into the IETF-YANG-Library [draft-lincla-netconf-yang-library-augmentedby-02] (29 pages) - RESTCONF Extension to support Trace Context Headers [draft-netconf-restconf-trace-ctx-headers-00] (7 pages) - NETCONF Extension to support Trace Context propagation [draft-netconf-trace-ctx-extension-00] (19 pages) - YANG Library [draft-nmdsdt-netconf-rfc7895bis-01] (23 pages) - External Trace ID for Configuration Tracing [draft-quilbeuf-netconf-configuration-tracing-00] (16 pages) - RESTCONF Extension to support Trace Context Headers [draft-rogaglia-netconf-restconf-trace-ctx-headers-00] (7 pages) - NETCONF Extension to support Trace Context propagation [draft-rogaglia-netconf-trace-ctx-extension-03] (19 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) Network Modeling (netmod) ------------------------- Charter Last Modified: 2024-07-08 Current Status: Active Chairs: Kent Watsen Lou Berger Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Secretary: James Cumming 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: 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) - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models [draft-boucadair-netmod-rfc8407bis-02] (70 pages) - Extensions to the Access Control Lists (ACLs) YANG Model [draft-dbb-netmod-acl-03] (32 pages) - Representing Unknown YANG bits in Operational State [draft-haas-netmod-unknown-bits-02] (18 pages) - Extensions to the Access Control Lists (ACLs) YANG Model [draft-ietf-netmod-acl-extensions-10] (82 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) - YANG Metadata Annotation for Immutable Flag [draft-ietf-netmod-immutable-flag-01] (19 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-14] (37 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-11] (30 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-16] (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) - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models [draft-ietf-netmod-rfc8407bis-15] (92 pages) - A YANG Data Model for Routing Management [draft-ietf-netmod-routing-cfg-25] (64 pages) - A Common YANG Data Model for Scheduling [draft-ietf-netmod-schedule-yang-02] (58 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-11] (34 pages) - A YANG Data Model for Syslog Configuration [draft-ietf-netmod-syslog-model-32] (44 pages) - System-defined Configuration [draft-ietf-netmod-system-config-08] (47 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) - YANG module file name convention [draft-ietf-netmod-yang-module-filename-00] (5 pages) - Updated YANG Module Revision Handling [draft-ietf-netmod-yang-module-versioning-12] (36 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-17] (34 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-10] (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) - YANG Metadata Annotation for Immutable Flag [draft-ma-netmod-immutable-flag-09] (19 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: 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) Network File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2024-01-17 Current Status: Active Chairs: Brian Pawlowski Christopher Inacio Web and Internet Transport Directors: Francesca Palombini Zaheduzzaman Sarker Web and Internet Transport Advisor: Zaheduzzaman Sarker Tech Advisor: Leif Johansson Secretary: Thomas Haynes Mailing Lists: General Discussion: nfsv4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nfsv4 Archive: https://mailarchive.ietf.org/arch/browse/nfsv4/ Description of Working Group: Network File System version 4 (NFSv4) is an IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the NFSv4 working group is chartered to maintain the existing NFSv4.0, NFSv4.1, and NFSv4.2 protocols and specifications of related ONC components, such as those defining RPC, XDR, and RPCSECGSS. The NFSv4 working group is also responsible for maintenance and extension of the RDMA protocols originally developed by the now-concluded RDDP WG (RFCs 5040-5045, e.g., RDMAP, DDP and MPA) , whose maintenance and extension were previously handled by the now-concluded STORM WG. In addition, extensions will be developed, as necessary, to correct problems with the protocols as currently specified, to accommodate needed file system semantics, and to respond to technological developments in the areas of networking and persistent storage/memory. Maintenance The working group's experience has been that, as NFSv4 implementations mature and deployments continue, clarifications and corrections to existing RFCs are needed. These specification updates help vendors in delivering high-quality and interoperable implementations. The NFSv4 working group is chartered with vetting reported issues and determining correctness of submitted errata. In addition, some areas may need more concentrated work to correct the specifications already published, to deal with unanticipated interactions between features, or to respond to evolving expectations with regard to areas such as security. Since necessary changes in such cases are generally not appropriate for the errata system, the working group will assist in publication of new RFCs that provide implementation guidance, editorial modification or technical updates to existing RFCs. Since the new NFSv4 versioning framework has been approved, these technical updates to NFSv4 minor versions could include limited XDR changes. Extensions The NFSv4 protocol is designed to allow extension by the definition of new operations, new attributes, and new Parallel NFS layout types, as well as the creation of minor versions. Similarly, associated ONC protocol components that have a versioning/ extension framework can be incrementally extended, when necessary. The working group will discuss proposals for such extensions and assure that they have adequate technical review, including discussion of their interaction with existing features, before adopting them as working group items and helping to draft specification documents. Some likely motivations for such extensions would be to: * Maximize NFS performance on advanced network fabrics. * Accommodate new storage technologies. * Provide facilities useful in management of NFS-accessed storage in large-scale virtualization environments. * Provide more effective NFS response to security challenges. New milestones that fall within the scope specified in this charter can be added to the list below after working group consensus and upon approval by the responsible Area Director. The WG will extend RDMA to enhance the Memory Placement operations such as Flush, Atomic Write and Validation using Integrity Signatures. Goals and Milestones: Aug 2025 - Submit final document describing NFSv4 security. Jul 2026 - Submit final draft of rfc5661bis Internet-Drafts: - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-dnoveck-nfsv4-rfc5661bis-05] (663 pages) - NFS version 4 Protocol [draft-ietf-nfsv4-07] (212 pages) - NFS version 4 Protocol [draft-ietf-nfsv4-03-00] (230 pages) - Mapping Between NFSv4 and Posix Draft ACLs [draft-ietf-nfsv4-acl-mapping-05] (20 pages) - NFS Version 4 ACLs [draft-ietf-nfsv4-acls-00] (35 pages) - The Channel Conjunction Mechanism (CCM) for GSS [draft-ietf-nfsv4-ccm-03] (28 pages) - On the Use of Channel Bindings to Secure Channels [draft-ietf-nfsv4-channel-bindings-04] (17 pages) - Extending the Opening of Files in NFSv4.2 [draft-ietf-nfsv4-delstid-07] (13 pages) - NFS Version 4 Design Considerations [draft-ietf-nfsv4-designconsider-03] (22 pages) - NFSv4.1: Directory Delegations and Notifications [draft-ietf-nfsv4-directory-delegation-01] (24 pages) - A DNS RR for NFSv4 ID Domains [draft-ietf-nfsv4-dns-rr-00] (11 pages) - Administration Protocol for Federated File Systems [draft-ietf-nfsv4-federated-fs-admin-15] (37 pages) - Using DNS SRV to Specify a Global File Namespace with NFS Version 4 [draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13] (11 pages) - Namespace Database (NSDB) Protocol for Federated File Systems [draft-ietf-nfsv4-federated-fs-protocol-15] (65 pages) - Requirements for Federated File Systems [draft-ietf-nfsv4-federated-fs-reqts-06] (26 pages) - Parallel NFS (pNFS) Flexible File Layout [draft-ietf-nfsv4-flex-files-19] (42 pages) - Integrity Measurement for Network File System version 4 [draft-ietf-nfsv4-integrity-measurement-08] (18 pages) - Internationalization for the NFSv4 Protocols [draft-ietf-nfsv4-internationalization-11] (61 pages) - NFS operation over IPv4 and IPv6 [draft-ietf-nfsv4-ipv4v6-00] (14 pages) - NFS operation over IPv6 [draft-ietf-nfsv4-ipv6-00] (8 pages) - Requirements for Labeled NFS [draft-ietf-nfsv4-labreqs-05] (18 pages) - Requirements for Parallel NFS (pNFS) Layout Types [draft-ietf-nfsv4-layout-types-13] (17 pages) - Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type [draft-ietf-nfsv4-layoutwcc-02] (11 pages) - Reporting of Errors via LAYOUTRETURN in NFSv4.2 [draft-ietf-nfsv4-layrec-01] (6 pages) - Registry Specification for Mandatory Access Control (MAC) Security Label Formats [draft-ietf-nfsv4-lfs-registry-06] (10 pages) - NFSv4 Migration and Trunking: Implementation and Specification Issues [draft-ietf-nfsv4-migration-issues-16] (55 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-minorversion1-29] (617 pages) - Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion1-dot-x-12] (73 pages) - Network File System (NFS) Version 4 Minor Version 2 Protocol [draft-ietf-nfsv4-minorversion2-41] (104 pages) - Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion2-dot-x-41] (87 pages) - Requirements for NFSv4.2 [draft-ietf-nfsv4-minorversion-2-requirements-00] (10 pages) - Requirements for NFSv4 Multi-Domain Namespace Deployment [draft-ietf-nfsv4-multi-domain-fs-reqs-11] (17 pages) - NFS Version 4.0 Trunking Update [draft-ietf-nfsv4-mv0-trunking-update-05] (22 pages) - NFS Version 4.1 Update for Multi-Server Namespace [draft-ietf-nfsv4-mv1-msns-update-04] (106 pages) - Network File System (NFS) Direct Data Placement [draft-ietf-nfsv4-nfsdirect-08] (10 pages) - Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement [draft-ietf-nfsv4-nfs-rdma-problem-statement-08] (15 pages) - NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 [draft-ietf-nfsv4-nfssec-03] (19 pages) - Network File System (NFS) Upper-Layer Binding To RPC-Over-RDMA Version 2 [draft-ietf-nfsv4-nfs-ulb-v2-07] (18 pages) - NFSv4 pNFS Extensions [draft-ietf-nfsv4-pnfs-00] (63 pages) - pNFS Access Permissions Check [draft-ietf-nfsv4-pnfs-access-permissions-check-00] (12 pages) - Parallel NFS (pNFS) Block/Volume Layout [draft-ietf-nfsv4-pnfs-block-12] (28 pages) - Parallel NFS (pNFS) Block Disk Protection [draft-ietf-nfsv4-pnfs-block-disk-protection-03] (6 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-pnfs-obj-12] (35 pages) - Implementation Guide for Referrals in NFSv4 [draft-ietf-nfsv4-referrals-00] (24 pages) - Server-to-Server Replication/Migration Protocol Design Principles [draft-ietf-nfsv4-repl-mig-design-00] (12 pages) - A Server-to-Server Replication/Migration Protocol [draft-ietf-nfsv4-repl-mig-proto-01] (30 pages) - NFS Version 4 Requirements [draft-ietf-nfsv4-requirements-03] (19 pages) - RPC: Remote Procedure Call Protocol Specification Version 2 [draft-ietf-nfsv4-rfc1831bis-13] (63 pages) - XDR: External Data Representation Standard [draft-ietf-nfsv4-rfc1832bis-06] (27 pages) - Network File System (NFS) version 4 Protocol [draft-ietf-nfsv4-rfc3010bis-05] (275 pages) - Network File System (NFS) Version 4 Protocol [draft-ietf-nfsv4-rfc3530bis-35] (323 pages) - Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-rfc3530bis-dot-x-24] (39 pages) - NFSv4.0 Migration: Specification Update [draft-ietf-nfsv4-rfc3530-migration-update-08] (55 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-rfc5661bis-08] (747 pages) - NFS Version 4.1 Update for Multi-Server Namespace [draft-ietf-nfsv4-rfc5661-msns-update-00] (135 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-rfc5661sesqui-msns-04] (560 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-rfc5664bis-03] (38 pages) - Remote Direct Memory Access Transport for Remote Procedure Call Version 1 [draft-ietf-nfsv4-rfc5666bis-11] (55 pages) - RPC-over-RDMA Version One Implementation Experience [draft-ietf-nfsv4-rfc5666-implementation-experience-03] (50 pages) - Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 [draft-ietf-nfsv4-rfc5667bis-13] (21 pages) - RPC Numbering Authority Transfer to IANA [draft-ietf-nfsv4-rpc-iana-03] (13 pages) - IPv6 extension to RPC [draft-ietf-nfsv4-rpc-ipv6-00] (13 pages) - IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats [draft-ietf-nfsv4-rpc-netid-06] (14 pages) - Remote Direct Memory Access Transport for Remote Procedure Call [draft-ietf-nfsv4-rpcrdma-09] (34 pages) - Bidirectional Remote Procedure Call on RPC-over-RDMA Transports [draft-ietf-nfsv4-rpcrdma-bidirection-08] (13 pages) - Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 [draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08] (12 pages) - RPC-over-RDMA Version 2 Protocol [draft-ietf-nfsv4-rpcrdma-version-two-07] (90 pages) - RPCSEC_GSS Version 2 [draft-ietf-nfsv4-rpcsec-gss-v2-06] (14 pages) - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsec-gssv3-17] (26 pages) - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsecgssv3-00] (23 pages) - Towards Remote Procedure Call Encryption by Default [draft-ietf-nfsv4-rpc-tls-11] (21 pages) - Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout [draft-ietf-nfsv4-scsi-layout-10] (30 pages) - Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices [draft-ietf-nfsv4-scsi-layout-nvme-07] (10 pages) - NFSv4.1: SECINFO Changes [draft-ietf-nfsv4-secinfo-02] (15 pages) - NFSv4 Session Extensions [draft-ietf-nfsv4-sess-02] (69 pages) - Allowing Inheritable NFSv4 Access Control Entries to Override the Umask [draft-ietf-nfsv4-umask-05] (7 pages) - Rules for NFSv4 Extensions and Minor Versions [draft-ietf-nfsv4-versioning-11] (26 pages) - File System Extended Attributes in NFSv4 [draft-ietf-nfsv4-xattrs-07] (28 pages) - NFS version 4 [draft-shepler-nfsv4-03] (133 pages) Requests for Comments: RFC2623: NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 (19 pages) RFC2624: NFS Version 4 Design Considerations (22 pages) RFC3010: NFS version 4 Protocol (212 pages) * Obsoletes RFC3530 RFC3530: Network File System (NFS) version 4 Protocol (275 pages) * Obsoletes RFC7530 RFC4506: XDR: External Data Representation Standard (27 pages) RFC5403: RPCSEC_GSS Version 2 (14 pages) * Updates RFC7861 RFC5531: RPC: Remote Procedure Call Protocol Specification Version 2 (63 pages) * Updates RFC9289 RFC5532: Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement (15 pages) RFC5661: Network File System (NFS) Version 4 Minor Version 1 Protocol (617 pages) * Updates RFC8178 * Updates RFC8434 * Obsoletes RFC8881 RFC5662: Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description (73 pages) RFC5663: Parallel NFS (pNFS) Block/Volume Layout (28 pages) * Updates RFC6688 RFC5664: Object-Based Parallel NFS (pNFS) Operations (35 pages) RFC5665: IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats (14 pages) RFC5666: Remote Direct Memory Access Transport for Remote Procedure Call (34 pages) * Obsoletes RFC8166 RFC5667: Network File System (NFS) Direct Data Placement (10 pages) * Obsoletes RFC8267 RFC5716: Requirements for Federated File Systems (26 pages) RFC6641: Using DNS SRV to Specify a Global File Namespace with NFS Version 4 (11 pages) RFC6688: Parallel NFS (pNFS) Block Disk Protection (6 pages) RFC7204: Requirements for Labeled NFS (18 pages) RFC7530: Network File System (NFS) Version 4 Protocol (323 pages) * Updates RFC7931 * Updates RFC8587 RFC7531: Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description (39 pages) RFC7532: Namespace Database (NSDB) Protocol for Federated File Systems (65 pages) RFC7533: Administration Protocol for Federated File Systems (37 pages) RFC7569: Registry Specification for Mandatory Access Control (MAC) Security Label Formats (10 pages) RFC7861: Remote Procedure Call (RPC) Security Version 3 (26 pages) RFC7862: Network File System (NFS) Version 4 Minor Version 2 Protocol (104 pages) * Updates RFC8178 RFC7863: Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description (87 pages) RFC7931: NFSv4.0 Migration: Specification Update (55 pages) RFC8000: Requirements for NFSv4 Multi-Domain Namespace Deployment (17 pages) RFC8154: Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout (30 pages) RFC8166: Remote Direct Memory Access Transport for Remote Procedure Call Version 1 (55 pages) * Updates RFC8797 RFC8167: Bidirectional Remote Procedure Call on RPC-over-RDMA Transports (13 pages) RFC8178: Rules for NFSv4 Extensions and Minor Versions (26 pages) RFC8267: Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 (21 pages) RFC8275: Allowing Inheritable NFSv4 Access Control Entries to Override the Umask (7 pages) RFC8276: File System Extended Attributes in NFSv4 (28 pages) RFC8434: Requirements for Parallel NFS (pNFS) Layout Types (17 pages) RFC8435: Parallel NFS (pNFS) Flexible File Layout (42 pages) RFC8587: NFS Version 4.0 Trunking Update (22 pages) RFC8797: Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 (12 pages) RFC8881: Network File System (NFS) Version 4 Minor Version 1 Protocol (560 pages) RFC9289: Towards Remote Procedure Call Encryption by Default (21 pages) RFC9561: Using the Parallel NFS (pNFS) SCSI Layout to Access Non-Volatile Memory Express (NVMe) Storage Devices (9 pages) Network Management Operations (nmop) ------------------------------------ Charter Last Modified: 2024-07-25 Current Status: Active Chairs: Benoît Claise Mohamed Boucadair Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani Secretary: Thomas Graf Mailing Lists: General Discussion: nmop@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nmop Archive: https://mailarchive.ietf.org/arch/browse/nmop/ Description of Working Group: The increased drive by operators for integration and deployment of network management protocols and YANG data models may expose issues and problems with the individual protocols and models, or with the wider integration of both the protocols and the models. Some of these problems may only be witnessed when trying to manage large-scale networks, e.g., due to the increased complexity and handling large volumes of data exported in frequent updates. At the same time, simplifying the network management and operations, with increased automation, is a high priority for network operators. The goals of the Network Management Operations working group are to solicit input from network operators to identify existing and anticipated operational issues arising from the near-term deployment of network management technologies, and to consider potential solutions or workarounds for those issues. Those operational issues may relate to deployments of existing network management technologies or the integration of related technologies for network management and telemetry. Solving those operational issues requires discussion, investigation, and potentially some experiments, which may take some time. However, the working group will focus on pragmatic items achievable in a short timeframe over long term architectural visions. Since the focus is on solving network management problems faced by operators, discussion and experiments are not solely limited to network management technologies standardized within the IETF but may cover the wider network management ecosystem as it relates to the management of IETF protocols, subject to the following two constraints: * The working group may discuss network management protocols and data models not standardized within the IETF only when they are being used to manage IETF protocols or to compare them to equivalent IETF solutions. * The working group will not work on specific issues or improvements to protocols or data models developed and maintained outside the IETF. They must be taken to the appropriate organization for discussion and resolution. The Network Management Operations working group is scoped, in rough order from highest to lowest priority, to: * Present and discuss operational issues faced by the deployment of existing network management technologies. * Discuss ideas for future short-term experiments (i.e., those focused on incremental improvements to network management operations that can be achieved in 1-2 years) and report on the progress of the relevant experimentation being done in the community. * Discuss network operator use cases and requirements for solving anticipated problems related to the deployment of network management technologies. * Standardize YANG data models to solve operational issues identified in the scope items above. YANG data models potentially within the scope of other WGs will only be progressed here with agreement from the relevant ADs. * Seek involvement with developers of open-source software to help drive adoption of IETF network management standards and to improve protocol maturity. * Document operational experience and best practice for network management and telemetry deployment as BCPs or Informational RFCs. This working group is not chartered to work on new protocols or protocol enhancements. Agenda time at NMOP sessions at IETF meetings should allow for presentations and discussions of operator issues and experience, and other work within scope for the working group, but with a default expectation that priority be given to operator presentations. The current topics of focus for the working group are: * NETCONF/YANG Push integration with Apache Kafka & time series databases * Anomaly detection and incident management * Issues related to deployment/usage of YANG topology modules (e.g., to model a Digital Map) * Consider/plan an approach for updating RFC 3535-bis (collecting updated operator requirements for IETF network management solutions) Like many of the “ops” working groups, this working group is expected to be long-lived, and is expected to remain open whilst there is sufficient interest and drive from the operators to work on topics within the scope described above. Goals and Milestones: Sep 2025 - Submit Architecture for YANG-Push to Message Broker Integration to the IESG Dec 2025 - Submit NMOP Terminology to the IESG Dec 2025 - Submit Network Incident Management to the IESG Dec 2025 - Submit Network Anomaly Management to the IESG Done - Adopt a document on network incident management Done - Adopt a document describing how to integrate YANG Push with Apache Kafka Done - Adopt a terminology document for anomaly and incident management Done - Adopt a document on network anomaly management Internet-Drafts: - Some Key Terms for Network Incident and Problem Management [draft-davis-nmop-incident-terminology-01] (13 pages) - A YANG Data Model for Network Incident Management [draft-feng-nmop-network-incident-yang-03] (34 pages) - Digital Map: Concept, Requirements, and Use Cases [draft-havel-nmop-digital-map-concept-00] (15 pages) - An Architecture for a Network Anomaly Detection Framework [draft-ietf-nmop-network-anomaly-architecture-00] (18 pages) - A YANG Data Model for Network Incident Management [draft-ietf-nmop-network-incident-yang-01] (42 pages) - Some Key Terms for Network Fault and Problem Management [draft-ietf-nmop-terminology-05] (13 pages) - An Architecture for YANG-Push to Message Broker Integration [draft-ietf-nmop-yang-message-broker-integration-04] (23 pages) - An Architecture for a Network Anomaly Detection Framework [draft-netana-nmop-network-anomaly-architecture-00] (18 pages) - An Architecture for YANG-Push to Message Broker Integration [draft-netana-nmop-yang-message-broker-integration-00] (21 pages) No Requests for Comments Network Time Protocols (ntp) ---------------------------- Charter Last Modified: 2024-07-25 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-25] (17 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) - Network Time Protocol Version 5 [draft-ietf-ntp-ntpv5-02] (31 pages) - NTPv5 Use Cases and Requirements [draft-ietf-ntp-ntpv5-requirements-04] (11 pages) - NTS4PTP - Network Time Security for the Precision Time Protocol [draft-ietf-ntp-nts-for-ptp-00] (78 pages) - NTP Over PTP [draft-ietf-ntp-over-ptp-03] (12 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-11] (19 pages) - Roughtime Ecosystem [draft-ietf-ntp-roughtime-ecosystem-01] (4 pages) - Updating the NTP Registries [draft-ietf-ntp-update-registries-16] (11 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) - NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol [draft-langer-ntp-nts-for-ptp-07] (76 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: 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) RFC9523: A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos (13 pages) Network Virtualization Overlays (nvo3) -------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Matthew Bocci Sam Aldrin Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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-13] (12 pages) - NVO3 Data Plane Requirements [draft-ietf-nvo3-dataplane-requirements-03] (18 pages) - Network Virtualization Overlays (NVO3) Encapsulation Considerations [draft-ietf-nvo3-encap-12] (26 pages) - Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks [draft-ietf-nvo3-evpn-applicability-06] (23 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-11] (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-13] (25 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) RFC9469: Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks (23 pages) RFC9521: Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve) (11 pages) Web Authorization Protocol (oauth) ---------------------------------- Charter Last Modified: 2024-03-27 Current Status: Active Chairs: Hannes Tschofenig Rifaat Shekh-Yusef Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: https://mailarchive.ietf.org/arch/browse/oauth/ Description of Working Group: The Web Authorization (OAuth) protocol allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite already includes * a procedure for enabling a client to register with an authorization server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, and * protocols for presenting these authorization tokens to protected resources for access to a resource. This protocol suite has been enhanced with functionality for interworking with legacy identity infrastructure (such as SAML), token revocation, token exchange, dynamic client registration, token introspection, a standardized token format with the JSON Web Token, and specifications that mitigate security attacks, such as Proof Key for Code Exchange. The ongoing standardization efforts within the OAuth working group focus on increasing interoperability of OAuth deployments and to improve security. More specifically, the working group is defining proof of possession tokens, developing a discovery mechanism, providing guidance for the use of OAuth with native apps, re-introducing the device flow used by devices with limited user interfaces, additional security enhancements for clients communicating with multiple service providers, definition of claims used with JSON Web Tokens, techniques to mitigate open redirector attacks, as well as guidance on encoding state information. For feedback and discussion about our specifications please subscribe to our public mailing list at . For security related bug reports that relate to our specifications please contact . If the reported bug report turns out to be implementation-specific we will attempt to forward it to the appropriate developers. Goals and Milestones: Mar 2021 - Submit 'OAuth 2.0 Pushed Authorization Requests" to IESG Jul 2021 - Submit "OAuth 2.1 Authorization Framework" to IESG Jul 2021 - Submit 'OAuth 2.0 Security Best Practice" to IESG Oct 2021 - Submit "OAuth 2.0 for Browser-Based Apps" to IES Jan 2022 - Submit "OAuth 2.0 Proof-of-Posession at the Application Layer" to IESG Apr 2022 - Submit "OAuth 2.0 Authorization Server Issue Identifier in Authorization Response" to IESG Done - Submit 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' to the IESG Done - Submit 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture' to the IESG Done - Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard Done - Submit 'Authentication Method Reference Values' to the IESG Done - Submit 'OAuth 2.0 for Native Apps' to the IESG Done - Submit 'OAuth 2.0 Authorization Server Discovery Metadata' to the IESG Done - Submit 'OAuth 2.0 Device Flow' to the IESG Done - Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard Internet-Drafts: - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [draft-ietf-oauth-access-token-jwt-13] (15 pages) - Authentication Method Reference Values [draft-ietf-oauth-amr-values-08] (15 pages) - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-assertions-18] (20 pages) - OAuth 2.0 Attestation-Based Client Authentication [draft-ietf-oauth-attestation-based-client-auth-03] (16 pages) - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-01] (21 pages) - OAuth 2.0 for Browser-Based Applications [draft-ietf-oauth-browser-based-apps-18] (61 pages) - OAuth 2.0 Security: Closing Open Redirectors in OAuth [draft-ietf-oauth-closing-redirectors-00] (7 pages) - Cross-Device Flows: Security Best Current Practice [draft-ietf-oauth-cross-device-security-08] (55 pages) - OAuth 2.0 Device Authorization Grant [draft-ietf-oauth-device-flow-15] (21 pages) - OAuth 2.0 Authorization Server Metadata [draft-ietf-oauth-discovery-10] (23 pages) - Distributed OAuth [draft-ietf-oauth-distributed-01] (9 pages) - OAuth 2.0 Demonstrating Proof of Possession (DPoP) [draft-ietf-oauth-dpop-16] (39 pages) - OAuth 2.0 Dynamic Client Registration Protocol [draft-ietf-oauth-dyn-reg-30] (39 pages) - OAuth 2.0 Dynamic Client Registration Management Protocol [draft-ietf-oauth-dyn-reg-management-15] (18 pages) - OAuth 2.0 Dynamic Client Registration Metadata [draft-ietf-oauth-dyn-reg-metadata-01] (4 pages) - OAuth Identity and Authorization Chaining Across Domains [draft-ietf-oauth-identity-chaining-02] (19 pages) - OAuth 2.0 Incremental Authorization [draft-ietf-oauth-incremental-authz-04] (11 pages) - OAuth 2.0 Token Introspection [draft-ietf-oauth-introspection-11] (17 pages) - OAuth 2.0 Authorization Server Issuer Identification [draft-ietf-oauth-iss-auth-resp-05] (9 pages) - JSON Web Token (JWT) [draft-ietf-oauth-json-web-token-32] (30 pages) - JWK Thumbprint URI [draft-ietf-oauth-jwk-thumbprint-uri-03] (6 pages) - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) [draft-ietf-oauth-jwsreq-34] (25 pages) - JSON Web Token Best Current Practices [draft-ietf-oauth-jwt-bcp-07] (13 pages) - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-jwt-bearer-12] (12 pages) - JWT Response for OAuth Token Introspection [draft-ietf-oauth-jwt-introspection-response-12] (19 pages) - OAuth 2.0 Mix-Up Mitigation [draft-ietf-oauth-mix-up-mitigation-01] (14 pages) - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [draft-ietf-oauth-mtls-17] (24 pages) - OAuth 2.0 for Native Apps [draft-ietf-oauth-native-apps-12] (21 pages) - OAuth 2.0 Pushed Authorization Requests [draft-ietf-oauth-par-10] (18 pages) - OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [draft-ietf-oauth-pop-architecture-08] (23 pages) - OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution [draft-ietf-oauth-pop-key-distribution-07] (17 pages) - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [draft-ietf-oauth-proof-of-possession-11] (15 pages) - OAuth 2.0 Rich Authorization Requests [draft-ietf-oauth-rar-23] (38 pages) - Reciprocal OAuth [draft-ietf-oauth-reciprocal-04] (8 pages) - Resource Indicators for OAuth 2.0 [draft-ietf-oauth-resource-indicators-08] (11 pages) - OAuth 2.0 Protected Resource Metadata [draft-ietf-oauth-resource-metadata-09] (29 pages) - OAuth 2.0 Token Revocation [draft-ietf-oauth-revocation-11] (11 pages) - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [draft-ietf-oauth-saml2-bearer-23] (15 pages) - SD-JWT-based Verifiable Credentials (SD-JWT VC) [draft-ietf-oauth-sd-jwt-vc-04] (42 pages) - OAuth 2.0 Security Best Current Practice [draft-ietf-oauth-security-topics-29] (59 pages) - Selective Disclosure for JWTs (SD-JWT) [draft-ietf-oauth-selective-disclosure-jwt-12] (93 pages) - A Method for Signing HTTP Requests for OAuth [draft-ietf-oauth-signed-http-request-03] (13 pages) - Proof Key for Code Exchange by OAuth Public Clients [draft-ietf-oauth-spop-15] (20 pages) - Token Status List [draft-ietf-oauth-status-list-03] (37 pages) - OAuth 2.0 Step Up Authentication Challenge Protocol [draft-ietf-oauth-step-up-authn-challenge-17] (14 pages) - OAuth 2.0 Token Binding [draft-ietf-oauth-token-binding-08] (30 pages) - OAuth 2.0 Token Exchange [draft-ietf-oauth-token-exchange-19] (27 pages) - Transaction Tokens [draft-ietf-oauth-transaction-tokens-03] (28 pages) - An IETF URN Sub-Namespace for OAuth [draft-ietf-oauth-urn-sub-ns-06] (5 pages) - OAuth Use Cases [draft-ietf-oauth-use-cases-03] (24 pages) - The OAuth 2.0 Authorization Framework [draft-ietf-oauth-v2-31] (76 pages) - The OAuth 2.1 Authorization Framework [draft-ietf-oauth-v2-1-11] (96 pages) - The OAuth 2.0 Authorization Framework: Bearer Token Usage [draft-ietf-oauth-v2-bearer-23] (18 pages) - OAuth 2.0 Message Authentication Code (MAC) Tokens [draft-ietf-oauth-v2-http-mac-05] (37 pages) - OAuth 2.0 Threat Model and Security Considerations [draft-ietf-oauth-v2-threatmodel-08] (71 pages) - The OAuth Protocol: Web Delegation [draft-ietf-oauth-web-delegation-01] (18 pages) Requests for Comments: RFC6749: The OAuth 2.0 Authorization Framework (76 pages) * Updates RFC8252 * Updates RFC8996 RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (18 pages) * Updates RFC8996 RFC6755: An IETF URN Sub-Namespace for OAuth (5 pages) RFC6819: OAuth 2.0 Threat Model and Security Considerations (71 pages) RFC7009: OAuth 2.0 Token Revocation (11 pages) RFC7519: JSON Web Token (JWT) (30 pages) * Updates RFC7797 * Updates RFC8725 RFC7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (20 pages) RFC7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants (15 pages) RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (12 pages) RFC7591: OAuth 2.0 Dynamic Client Registration Protocol (39 pages) RFC7592: OAuth 2.0 Dynamic Client Registration Management Protocol (18 pages) RFC7636: Proof Key for Code Exchange by OAuth Public Clients (20 pages) RFC7662: OAuth 2.0 Token Introspection (17 pages) RFC7800: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) (15 pages) RFC8176: Authentication Method Reference Values (15 pages) RFC8252: OAuth 2.0 for Native Apps (21 pages) RFC8414: OAuth 2.0 Authorization Server Metadata (23 pages) RFC8628: OAuth 2.0 Device Authorization Grant (21 pages) RFC8693: OAuth 2.0 Token Exchange (27 pages) RFC8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (24 pages) RFC8707: Resource Indicators for OAuth 2.0 (11 pages) RFC8725: JSON Web Token Best Current Practices (13 pages) RFC9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (15 pages) RFC9101: The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) (25 pages) RFC9126: OAuth 2.0 Pushed Authorization Requests (18 pages) RFC9207: OAuth 2.0 Authorization Server Issuer Identification (9 pages) RFC9278: JWK Thumbprint URI (6 pages) RFC9396: OAuth 2.0 Rich Authorization Requests (38 pages) RFC9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) (39 pages) RFC9470: OAuth 2.0 Step Up Authentication Challenge Protocol (14 pages) Oblivious HTTP Application Intermediation (ohai) ------------------------------------------------ Charter Last Modified: 2022-05-06 Current Status: Active Chairs: Richard Barnes Shivan Kaul Sahib Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Francesca Palombini Mailing Lists: General Discussion: ohai@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ohai Archive: https://mailarchive.ietf.org/arch/browse/ohai/ Description of Working Group: In a number of different settings, interactions between clients and servers involve information that could be sensitive when associated with client identity. Client-server applications built on HTTP reveal aspects of client identity to servers through these interactions, especially source addresses. Even without client identity, a server might be able to build a profile of client activity by correlating requests from the same client over time. In HTTP-based applications where the information included in requests does not need to be correlated, the protocol this working group defines will allow a supporting server to accept requests via a proxy. The proxy ensures that the server cannot see source addressing information for clients, which prevents servers linking multiple requests from the same client. Encryption ensures that the proxy is unable to read requests or responses. However, if the proxy and server collude, then neither of these privacy properties hold. Applications and use cases best suited for this protocol are those that have discrete, transactional queries that might reveal small amounts of information that accumulate over time. Examples include DNS queries, telemetry submission, and certificate revocation checking. In some of these application deployments, the relationship between client, server, and cooperating proxy might be configured out-of-band. General purpose HTTP applications such as web browsing are not in scope for the protocol that is to be defined. Broad applicability is limited by multiple factors, including the need for explicit server support of the protocol. In contrast, transport-level proxies such as HTTP CONNECT or MASQUE are a more appropriate mechanism for those use cases, as they allow connecting to unmodified servers. The OHAI working group will define a protocol for anonymization of HTTP requests using a partly-trusted intermediary, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. This protocol will use existing cryptographic primitives to meet these goals. The working group will define any data formats necessary to carry encapsulated requests and responses, plus formats for supplementary material, such as server keying material, that might be needed to use the protocol. The OHAI working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure. The working group will consider the operational impact as part of the protocol design and document operational considerations. The working group will prioritize work on the core protocol elements as identified. In addition, the working group may work on other use cases and deployment models, including those that involve discovery of proxies or servers and their key configurations. The OHAI working group will work closely with other groups that develop the tools that the protocol depends on (HTTPbis for HTTP, CFRG for HPKE) or that might use the protocol (DPRIVE and ADD for DNS over HTTPS). The working group will use draft-thomson-http-oblivious as input. Goals and Milestones: Jul 2025 - Submit Chunked OHTTP draft to the IESG for publication Done - Submit the protocol draft to the IESG for publication Internet-Drafts: - Chunked Oblivious HTTP Messages [draft-ietf-ohai-chunked-ohttp-01] (12 pages) - Oblivious HTTP [draft-ietf-ohai-ohttp-10] (49 pages) - Discovery of Oblivious Services via Service Binding Records [draft-ietf-ohai-svcb-config-07] (12 pages) - Chunked Oblivious HTTP Messages [draft-ohai-chunked-ohttp-01] (12 pages) - Discovery of Oblivious Services via Service Binding Records [draft-pauly-ohai-svcb-config-03] (11 pages) - Oblivious Relay Feedback [draft-rdb-ohai-feedback-to-proxy-09] (13 pages) - Oblivious HTTP [draft-thomson-ohai-ohttp-00] (30 pages) Requests for Comments: RFC9458: Oblivious HTTP (40 pages) RFC9540: Discovery of Oblivious Services via Service Binding Records (10 pages) Open Specification for Pretty Good Privacy (openpgp) ---------------------------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Daniel Kahn Gillmor Stephen Farrell Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Paul Wouters Mailing Lists: General Discussion: openpgp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: https://mailarchive.ietf.org/arch/browse/openpgp/ Description of Working Group: OpenPGP standardized mechanisms for object encryption, object signing, and identity certification. The working group is chartered to work on improvements and additions to the OpenPGP format and ecosystem to address certain issues that have been identified by the community, as set out in the list of in-scope topics below. Due to the WG having been dormant for a number of years, there is somewhat of a backlog of topics, and as addressing all of these topics at once seems difficult, the WG will follow the process defined below to prioritize current lists of milestones, selected from this long list of in-scope topics. # In-scope Topics The working group will produce a number of specifications that are adjacent to the OpenPGP specification and provide guidance to OpenPGP libraries and/or applications. These improvements may include: ## Security improvements - **Post-Quantum Cryptography (PQC)**: The addition and facilitation of post-quantum algorithms for encryption and signing (using draft-wussler-openpgp-pqc) as initial input). - **Forward secrecy**: enable encrypted OpenPGP communication that cannot be decrypted when long-term keys are compromised. - **Context binding**: facilitate [domain separation for signing and/or encryption](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145). ## New functionality - **Automatic Forwarding**: using proxy re-encryption (using draft-wussler-openpgp-forwarding) as initial input). - **Persistent Symmetric Keys**: for long-term storage of symmetric key material, symmetrically encrypted messages, and symmetric attestations (using draft-huigens-openpgp-persistent-symmetric-keys as initial input). - **First-Party Approval of Third-Party Certifications (1PA3PC)**: to mitigate certificate flooding attacks (using draft-dkg-openpgp-1pa3pc as initial input). - **Superseded Keys**: to facilitate [transition to new keys without revoking the old ones](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/222). - **Stateless OpenPGP Interface (SOP)**: using draft-dkg-openpgp-stateless-cli as initial input. - **PGP/MIME Separate Encrypted Parts**: Extending RFC3156 to describe [messages composed of multiple encrypted parts](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/171). - **cert-d**: A common certificate storage mechanism (using draft-nwjw-openpgp-cert-d as initial input). ## Network-based Key Discovery Mechanisms - **HTTP Keyserver Protocol (HKP)**: using draft-gallagher-openpgp-hkp as initial input. - **Web Key Directory (WKD)**: using draft-koch-openpgp-webkey-service as initial input. ## Key Verification Mechanisms - **Web-of-Trust (WoT)**: Specifying semantics for the WoT calculus (using [the OpenPGP Web of Trust draft](https://sequoia-pgp.gitlab.io/sequoia-wot/) as initial input). - **Key Transparency**: in collaboration with the [Key Transparency Working Group](https://datatracker.ietf.org/wg/keytrans/about/), e.g., integrating its outputs. - **Key Verification**: Improved manual key verification, for example using a QR code. ## Miscellaneous Cleanup Work - **Semantics**: Define semantics of mechanisms provided by OpenPGP. This includes, but is not limited to, defining validity of signatures, acceptance and placement of signature subpackets, as well as structure and meaning of certificates and messages. - **User ID Conventions**: Properly document User ID conventions (using draft-dkg-openpgp-userid-conventions as initial input). - **Revocation**: Clarify and improve revocation semantics and workflows, including replacement of the deprecated Revocation Key mechanism (using draft-dkg-openpgp-revocation as initial input). - **Message Grammar**: [Simplify](https://mailarchive.ietf.org/arch/msg/openpgp/uepOF6XpSegMO4c59tt9e5H1i4g/) the OpenPGP Message Grammar; e.g., by limiting nesting, or by constraining sequences of packet types. - **PGP/MIME One-Pass Signatures**: Extending RFC3156 to permit [one-pass signature verification for v6 signatures](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/116) # Working Group Process All work items will require demonstration of interoperable support by at least two independent implementations before being submitted to the IESG for publication. The WG chairs will periodically poll the WG for which of the topics above to add as milestones, as participant interest, document editor, review and implementer resources permit. The WG chairs will ensure that the list of active topics is credible at all times, likely resulting in only 3-4 topics being "active" at any given time. Such polls will typically result in the addition of a call-for-adoption for one or two new topics from the list above, depending on resources, and as currently active work is completed. As calls-for-adoption are held, those will also consider the intended-status (PS, informational, BCP) for the documents concerned. Completion will typically mean that a draft has passed working group last call or IETF last call, but, if needed, the chairs will make use of other datatracker IETF document states (e.g., parked WG document) if some document is stalled for technical or personnel reasons, leaving space for tackling another topic. The set of initial milestones below was selected following discussion on the WG list following the above process, and will be updated periodically as milestones are met. Goals and Milestones: Jan 2024 - Call for adoption of drafts related to post quantum cryptography to produce a proposed standard RFC Mar 2024 - Call for adoption of drafts related to superseded keys to produce a proposed standard RFC Mar 2024 - Call for adoption of drafts related to persistent symmetric keys to produce a proposed standard RFC Jun 2024 - Call for adoption of drafts related to WKD and/or HKP to produce a proposed standard RFC Internet-Drafts: - OpenPGP Replacement Key Signalling Mechanism [draft-gallagher-openpgp-replacementkey-02] (12 pages) - Persistent Symmetric Keys in OpenPGP [draft-huigens-openpgp-persistent-symmetric-keys-02] (8 pages) - OpenPGP [draft-ietf-openpgp-crypto-refresh-13] (199 pages) - OpenPGP Message Format [draft-ietf-openpgp-formats-07] (65 pages) - MIME Security with OpenPGP [draft-ietf-openpgp-mime-08] (15 pages) - Multiple Signatures using Security Multiparts [draft-ietf-openpgp-multsig-02] (6 pages) - Persistent Symmetric Keys in OpenPGP [draft-ietf-openpgp-persistent-symmetric-keys-00] (8 pages) - Post-Quantum Cryptography in OpenPGP [draft-ietf-openpgp-pqc-04] (65 pages) - OpenPGP Replacement Key Signalling Mechanism [draft-ietf-openpgp-replacementkey-00] (12 pages) - OpenPGP Message Format [draft-ietf-openpgp-rfc2440bis-22] (90 pages) - Post-Quantum Cryptography in OpenPGP [draft-wussler-openpgp-pqc-04] (41 pages) Requests for Comments: RFC2440: OpenPGP Message Format (65 pages) * Obsoletes RFC4880 RFC3156: MIME Security with OpenPGP (15 pages) RFC4880: OpenPGP Message Format (90 pages) * Updates RFC5581 * Obsoletes RFC9580 RFC9580: OpenPGP (166 pages) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2024-07-25 Current Status: Active Chairs: Benoît Claise Henk Birkholz Joe Clarke Operations and Management Area Directors: Mahesh Jethanandani Warren Kumari Operations and Management Area Advisor: Mahesh Jethanandani 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) - Finding and Using Geofeed Data [draft-ietf-opsawg-9092-update-11] (26 pages) - A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits [draft-ietf-opsawg-ac-lxsm-lxnm-glue-10] (33 pages) - RADIUS Extensions for DHCP-Configured Services [draft-ietf-opsawg-add-encrypted-dns-12] (18 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) - A Data Manifest for Contextualized Telemetry Data [draft-ietf-opsawg-collected-data-manifest-04] (46 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) - An Information Model for Packet Discard Reporting [draft-ietf-opsawg-discardmodel-03] (30 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) - IPFIX Alternate-Marking Information [draft-ietf-opsawg-ipfix-alt-mark-00] (9 pages) - Export of BGP Community Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-bgp-community-12] (18 pages) - Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry [draft-ietf-opsawg-ipfix-fixes-12] (38 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 Delay Performance Metrics in IP Flow Information eXport (IPFIX) [draft-ietf-opsawg-ipfix-on-path-telemetry-12] (32 pages) - Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-srv6-srh-14] (23 pages) - Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements [draft-ietf-opsawg-ipfix-tcpo-v6eh-18] (26 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-12] (15 pages) - Operational Considerations for Use of DNS in IoT Devices [draft-ietf-opsawg-mud-iot-dns-considerations-17] (21 pages) - Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices [draft-ietf-opsawg-mud-tls-18] (39 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) - A Network YANG Data Model for Attachment Circuits [draft-ietf-opsawg-ntw-attachment-circuit-13] (106 pages) - Guidelines for Charactering "OAM" [draft-ietf-opsawg-oam-characterization-03] (10 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-06] (9 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-04] (10 pages) - Link-Layer Types for PCAP and PCAPNG Capture File Formats [draft-ietf-opsawg-pcaplinktype-05] (26 pages) - PCAP Next Generation (pcapng) Capture File Format [draft-ietf-opsawg-pcapng-02] (60 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-07] (8 pages) - A YANG Network Data Model for Service Attachment Points (SAPs) [draft-ietf-opsawg-sap-15] (37 pages) - A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information [draft-ietf-opsawg-sbom-access-18] (18 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] (23 pages) - A YANG Data Model for Service Assurance [draft-ietf-opsawg-service-assurance-yang-11] (38 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) - Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 [draft-ietf-opsawg-tacacs-tls13-11] (17 pages) - A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) [draft-ietf-opsawg-tacacs-yang-12] (16 pages) - YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) [draft-ietf-opsawg-teas-attachment-circuit-16] (150 pages) - A Common YANG Data Model for Attachment Circuits [draft-ietf-opsawg-teas-common-ac-12] (59 pages) - Updates to the TLS Transport Model for SNMP [draft-ietf-opsawg-tlstm-update-15] (30 pages) - Export of UDP Options Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-tsvwg-udp-ipfix-14] (13 pages) - A YANG Data Model and RADIUS Extension for Policy-based Network Access Control [draft-ietf-opsawg-ucl-acl-05] (38 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) - Guidelines for Charactering "OAM" [draft-pignataro-opsawg-oam-whaaat-question-mark-05] (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: 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) * Obsoletes RFC9632 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) RFC9408: A YANG Network Data Model for Service Attachment Points (SAPs) (37 pages) RFC9417: Service Assurance for Intent-Based Networking Architecture (23 pages) RFC9418: A YANG Data Model for Service Assurance (38 pages) RFC9445: RADIUS Extensions for DHCP-Configured Services (18 pages) RFC9456: Updates to the TLS Transport Model for SNMP (30 pages) RFC9472: A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information (18 pages) RFC9487: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) (23 pages) RFC9565: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element (7 pages) RFC9632: Finding and Using Geofeed Data (23 pages) Pseudowire And LDP-enabled Services (pals) ------------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Andrew G. Malis Stewart Bryant Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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: Done - Submit PW Congestion Considerations to the IESG Done - Submit STP Application of ICCP to the IESG Done - Submit Unified Control Channel for PWs to the IESG Done - Submit Pseudowire Redundancy on S-PE 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 LDP-VPLS for Ethernet Broadcast and Multicast to the IESG Done - Submit PW Endpoint Fast Failure Protection to the IESG Done - Submit P2MP PW Signaling (root initiated) 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 Done - Submit L2VPN applicability statement for data center applications to the IESG 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) - Private Line Emulation over Packet Switched Networks [draft-ietf-pals-ple-06] (35 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) Path Computation Element (pce) ------------------------------ Charter Last Modified: 2023-06-29 Current Status: Active Chairs: Dhruv Dhody Julien Meuric Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: John Scudder Secretary: Andrew Stone 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 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, as well as new path setup types of Segment Routing (SR), BIER, and Detnet. In this architecture path computation does not necessarily occur on the head-end (ingress) node, but on some other path computation entity that may not be physically located on each head-end node. 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 works on the mechanisms for inter-domain as well as multi-layer path computation and PCEP extensions for communication between several domains or network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) and Flexible Grid 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 including PCE as a Central Controller (PCECC) and Centralized Control Dynamic Routing (CCDR). The PCEP extensions are developed in the PCE Working Group. - In cooperation with protocol-specific Working Groups (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 and Flexible Grid. - Specification of PCEP extensions for path computation in multi-layer and inter-domain networks. - Specification 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 the receiving PCC/PCE chooses not to follow the recommendation. The PCEP extensions for state synchronization are also in scope. - Specification of the PCEP extensions for SR-MPLS and SRv6 paths as per the SR Policy architecture in cooperation with SPRING Working Group. - Specification of the PCEP extensions for new path setup types (such as BIER and DETNET) in cooperation with the respective Working Groups. Goals and Milestones: Jan 2024 - Submit PCEP YANG Model as a Proposed Standard Mar 2024 - Submit PCEP extensions for SR Policy as Proposed Standard Mar 2024 - Submit PCEP extensions for Multipath as Proposed Standard Dec 2024 - Submit Enhancements to Stateful PCE Mar 2025 - Evaluate WG progress, recharter or close Done - Submit PCEP Native-IP extensions as a Proposed Standard 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) - PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-chen-pce-bier-13] (17 pages) - Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT [draft-chen-pce-pcep-ifit-06] (23 pages) - PCEP extensions for Distribution of Link-State and TE Information [draft-dhodylee-pce-pcep-ls-27] (39 pages) - Update to the IANA PCEP Registration Procedures [draft-dhody-pce-iana-update-03] (8 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) - Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. [draft-dhody-pce-stateful-pce-vendor-16] (12 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) - PCEP Extensions for BIER-TE [draft-ietf-pce-bier-te-00] (16 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 Communication Protocol (PCEP) extensions for Circuit Style Policies [draft-ietf-pce-circuit-style-pcep-extensions-06] (14 pages) - Path Computation Element (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (21 pages) - Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space [draft-ietf-pce-controlled-id-space-00] (18 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) - Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions [draft-ietf-pce-entropy-label-position-01] (10 pages) - PCEP Extension for Flexible Grid Networks [draft-ietf-pce-flexible-grid-10] (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) - Update to the IANA PCEP Registration Procedures and Allowing Experimental Error Codes [draft-ietf-pce-iana-update-01] (12 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 the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-local-protection-enforcement-11] (9 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-11] (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-04] (10 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) - Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks [draft-ietf-pce-pcep-extension-native-ip-40] (38 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-09] (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-03] (20 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-05] (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 Layer 2 (L2) Flow Specification [draft-ietf-pce-pcep-l2-flowspec-06] (14 pages) - PCEP extensions for Distribution of Link-State and TE Information [draft-ietf-pce-pcep-ls-01] (40 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-06] (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-05] (23 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks [draft-ietf-pce-pcep-stateful-pce-gmpls-23] (22 pages) - Updates for PCEPS: TLS Connection Establishment Restrictions [draft-ietf-pce-pceps-tls13-04] (6 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-25] (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 IPv6 Segment Routing [draft-ietf-pce-segment-routing-ipv6-25] (28 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths [draft-ietf-pce-segment-routing-policy-cp-17] (27 pages) - Carrying SR-Algorithm Information in PCE-based Networks. [draft-ietf-pce-sid-algo-13] (22 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-ietf-pce-sr-bidir-path-14] (20 pages) - PCEP extensions for p2mp sr policy [draft-ietf-pce-sr-p2mp-policy-09] (47 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-ietf-pce-sr-path-segment-11] (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-05] (47 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-09] (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) - Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. [draft-ietf-pce-stateful-pce-vendor-07] (12 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-07] (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) - Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space [draft-li-pce-controlled-id-space-16] (18 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 Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions [draft-peng-pce-entropy-label-position-11] (10 pages) - Path Computation Element Protocol(PCEP) Extension for Color [draft-rajagopalan-pce-pcep-color-03] (8 pages) - PCEP extensions for Circuit Style Policies [draft-sidor-pce-circuit-style-pcep-extensions-06] (11 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 * Updates RFC9488 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) RFC9488: Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP) (9 pages) RFC9504: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks (22 pages) RFC9603: Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing (23 pages) RFC9604: Carrying Binding Label/SID in PCE-Based Networks (19 pages) Protocols for IP Multicast (pim) -------------------------------- Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Mike McBride Stig Venaas Routing Area Directors: Jim Guichard John Scudder Gunter Van de Velde Routing Area Advisor: Gunter Van de Velde 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-07] (6 pages) - Internet Group Management Protocol, Version 3 [draft-ietf-pim-3376bis-12] (57 pages) - Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [draft-ietf-pim-3810bis-12] (68 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] (20 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) - Yang Data Model for EVPN multicast [draft-ietf-pim-evpn-multicast-yang-02] (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) - Group Address Allocation Protocol (GAAP) [draft-ietf-pim-gaap-01] (16 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 Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices [draft-ietf-pim-igmp-mld-proxy-yang-10] (20 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-04] (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) - Zero-Configuration Assignment of IPv6 Multicast Addresses [draft-ietf-pim-ipv6-zeroconf-assignment-02] (7 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-06] (6 pages) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages) - PIM Light [draft-ietf-pim-light-07] (9 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-05] (15 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-04] (20 pages) - Multipath Support for IGMP/MLD Proxy [draft-ietf-pim-multipath-igmpmldproxy-00] (15 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-08] (9 pages) - PIM Flooding Mechanism and Source Discovery Enhancements [draft-ietf-pim-pfm-forwarding-enhancements-00] (9 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) - Host Extensions for "Any Source" IP Multicasting (ASM) [draft-ietf-pim-rfc1112bis-02] (24 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] (7 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-09] (22 pages) - Updates to Dynamic IPv6 Multicast Address Group IDs [draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-02] (5 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) - Zeroconf Multicast Address Allocation Problem Statement and Requirements [draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-02] (7 pages) Requests for Comments: RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (61 pages) * Updates RFC8736 * Updates RFC9436 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 * Updates RFC9436 RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (42 pages) * Updates RFC8736 * Updates RFC9436 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 * Updates RFC9436 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 * Updates RFC9436 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 * Updates RFC9436 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) * Obsoletes RFC9436 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) RFC9398: A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices (20 pages) RFC9436: PIM Message Type Space Extension and Reserved Bits (7 pages) RFC9465: PIM Null-Register Packing (9 pages) RFC9466: PIM Assert Message Packing (20 pages) Privacy Preserving Measurement (ppm) ------------------------------------ Charter Last Modified: 2024-03-20 Current Status: Active Chairs: Benjamin M. Schwartz Samuel Weiler Security Area Directors: Deb Cooley Paul Wouters Security Area Advisor: Deb Cooley Mailing Lists: General Discussion: ppm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ppm Archive: https://mailarchive.ietf.org/arch/browse/ppm/ Description of Working Group: There are many situations in which it is desirable to take measurements of data which people consider sensitive. For instance, a browser company might want to measure web sites that do not render properly without learning which users visit those sites, or a public health authority might want to measure exposure to some disease without learning the identities of those exposed. In these cases, the entity taking the measurement is not interested in people's individual responses but rather in aggregated data (e.g., how many users had errors on site X). Conventional methods require collecting individual measurements in plaintext and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. New cryptographic techniques address this gap through a variety of approaches, all of which aim to ensure that the server (or multiple, non-colluding servers) can compute the aggregated value without learning the value of individual measurements. The Privacy Preserving Measurement (PPM) work will standardize protocols for deployment of these techniques on the Internet. This will include mechanisms for: - Client submission of individual measurements, potentially along with proofs of validity - Verification of validity proofs by the server(s), if sent by client - Computation of aggregate values by the server(s) and reporting of resul