6lo 6man 6tisch ace acme add alto anima asap asdf avtcore babel bess bfcpbis bfd bier bmwg calext capport cbor ccamp cdni cellar core cose curdle detnet dhc dime dispatch dmarc dmm dnsop dnssd dots dprive drip dtn ecrit emailcore emu extra gendispatch gnap grow hip homenet httpapi httpbis i2nsf i2rs idr intarea ippm ipsecme ipwave jmap jsonpath kitten lake lamps lisp lpwan lsr lsvr lwig manet masque mboned mile mls mmusic mops mpls netconf netmod nfsv4 ntp nvo3 oauth opsawg opsec pals pce perc pim privacypass quic radext rats raw regext rift rmcat roll rtgwg rum sacm secdispatch secevent sfc shmoo sidrops sipbrandy sipcore spring stir suit taps tcpm teas teep tictoc tls tokbind tram trans tsvwg uta v6ops webtrans wpack IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ Charter Last Modified: 2020-10-02 Current Status: Active Chairs: Carles Gomez Shwetha Bhandari Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: 6lo@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6lo Archive: https://mailarchive.ietf.org/arch/browse/6lo/ Description of Working Group: 6lo focuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of: * limited power, memory and processing resources * hard upper bounds on state, code space and processing cycles * optimization of energy and network bandwidth usage * lack of some layer 2 services like complete device connectivity and broadcast/multicast Specifically, 6lo will work on: 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks 2. Information and data models (e.g., MIB modules) for these adaptation layers for basic monitoring and troubleshooting. 3. Specifications, such as low-complexity header compression, that are applicable to more than one adaptation layer specification 4. Maintenance and informational documents required for the existing IETF specifications in this space. Only specifications targeting constrained node networks are in scope. 6lo will work closely with the 6man working group, which will continue to work on IP-over-foo documents outside the constrained node network space and will continue to be the focal point for IPv6 maintenance. For adaptation layer specifications that do not have implications on IPv6 architecture, 6man will be notified about 6lo's working group last call. Specifications that might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing new ND options or by exposing to IPv6 a link model different from either Ethernet or 6lowpan) will be closely coordinated with 6man, and/or specific parts will be fanned out to 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and INTAREA. 6lo works on small, focused pieces of work, but does not take on larger cross-layer efforts. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Security and management work that is not specific to the link layers being worked on is out of scope. Work related to routing is out of scope. 6lo will coordinate closely with the working groups in other areas that focus on constrained node networks, such as ROLL (RTG) and CoRE (APP). Goals and Milestones: Mar 2015 - WG LC for draft-ietf-6lo-dect-ule Mar 2015 - WG last call for draft-ietf-6lo-6lobac Apr 2015 - WG adoption call for 6lo security related draft 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 for draft-schoenw-6lo-lowpan-mib Done - WG decision on adoption of draft-mariager-6lowpan-v6over-dect-ule Done - WG LC for draft-ietf-6lo-btle Done - WG adoption call for draft-hong-6lo-ipv6-over-nfc 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] (32 pages) - IPv6 Backbone Router [draft-ietf-6lo-backbone-router-20] (37 pages) - IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP [draft-ietf-6lo-blemesh-08] (16 pages) - IPv6 over BLUETOOTH(R) Low Energy [draft-ietf-6lo-btle-17] (21 pages) - Packet Delivery Deadline time in 6LoWPAN Routing Header [draft-ietf-6lo-deadline-time-05] (21 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) - 6LoWPAN Selective Fragment Recovery [draft-ietf-6lo-fragment-recovery-21] (32 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 Multihop IPv6 Network [draft-ietf-6lo-minimal-fragment-15] (14 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) - Transmission of IPv6 Packets over Near Field Communication [draft-ietf-6lo-nfc-17] (15 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch [draft-ietf-6lo-paging-dispatch-05] (8 pages) - Transmission of IPv6 Packets over PLC Networks [draft-ietf-6lo-plc-04] (20 pages) - Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [draft-ietf-6lo-privacy-considerations-04] (10 pages) - Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery [draft-ietf-6lo-rfc6775-update-21] (47 pages) - 6LoWPAN Routing Header [draft-ietf-6lo-routing-dispatch-05] (33 pages) - IPv6 over Constrained Node Networks (6lo) Applicability & Use cases [draft-ietf-6lo-use-cases-09] (25 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) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bob Hinden Ole Trøan Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: https://mailarchive.ietf.org/arch/browse/ipv6/ Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. 6man is the design authority for extensions and modifications to the IPv6 protocol. The working group may, at its discretion, review any document produced in another working group that extends or modifies the IPv6 protocol and, in consultation with the responsible ADs of both working groups, may recommend to the IESG that 6man working group consensus is needed before any of those documents can progress for publication. Goals and Milestones: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Done - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Done - Determine way forward for ULA-C specification Done - Resolve open issues with "U/G" bits in Interface Identifiers Done - Develop approach for IPv6 Fragmentation Done - Develop approaches for IPv6 Extension Headers (Hop-by-Hop and Destination) Done - Plan for advancing core IPv6 core specifications to Internet Standard Internet-Drafts: - Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) [draft-ali-6man-spring-srv6-oam-03] (23 pages) - IPv6 Hop-by-Hop Header Handling [draft-baker-6man-hbh-header-handling-03] (9 pages) - Host routing in a multi-prefix network [draft-baker-6man-multi-homed-host-03] (9 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-carpenter-6man-why64-01] (20 pages) - IPv6 Node Requirements [draft-clw-rfc6434-bis-01] (34 pages) - Republishing the IPV6-MIB modules as obsolete [draft-fenner-ipv6-mibs-obsolete-02] (63 pages) - ICMPv6 errors for discarding packets due to processing limits [draft-herbert-6man-icmp-limits-03] (11 pages) - IPv6 Minimum Path MTU Hop-by-Hop Option [draft-hinden-6man-mtu-option-02] (14 pages) - Path MTU Discovery for IP version 6 [draft-hinden-6man-rfc1981bis-01] (16 pages) - Internet Protocol, Version 6 (IPv6) Specification [draft-hinden-6man-rfc2460bis-07] (36 pages) - IP Version 6 Addressing Architecture [draft-hinden-6man-rfc4291bis-06] (29 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-hinden-ipv4flag-04] (9 pages) - RFC 3627 to Historic Status [draft-ietf-6man-3627-historic-01] (3 pages) - Transmission of IPv6 over MS/TP Networks [draft-ietf-6man-6lobac-01] (20 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-05] (18 pages) - Distributing Address Selection Policy Using DHCPv6 [draft-ietf-6man-addr-select-opt-13] (12 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-03] (17 pages) - Duplicate Address Detection Proxy [draft-ietf-6man-dad-proxy-07] (16 pages) - Recommendation on Stable IPv6 Interface Identifiers [draft-ietf-6man-default-iids-16] (9 pages) - Generation of IPv6 Atomic Fragments Considered Harmful [draft-ietf-6man-deprecate-atomfrag-generation-08] (12 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-08] (19 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-15] (11 pages) - Transmission and Processing of IPv6 Extension Headers [draft-ietf-6man-ext-transmit-05] (10 pages) - A Uniform Format for IPv6 Extension Headers [draft-ietf-6man-exthdr-06] (6 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-03] (21 pages) - IPv6 Hop-by-Hop Options Extension Header [draft-ietf-6man-hbh-header-handling-03] (10 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) - 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-02] (15 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 Subnet Model: The Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-12] (11 pages) - IPv6 Router Advertisement IPv6-Only Flag [draft-ietf-6man-ipv6only-flag-05] (15 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-04] (18 pages) - First-Hop Router Selection by Hosts in a Multi-Prefix Network [draft-ietf-6man-multi-homed-host-10] (13 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) - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery [draft-ietf-6man-nd-extension-headers-05] (10 pages) - Validation of IPv6 Neighbor Discovery Options [draft-ietf-6man-nd-opt-validation-00] (15 pages) - IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags [draft-ietf-6man-ndpioiana-04] (4 pages) - Interface Identifier Assignment in IPv6 SLAAC [draft-ietf-6man-neighbor-inform-00] (17 pages) - IPv6 Node Requirements [draft-ietf-6man-node-req-bis-11] (30 pages) - Handling of Overlapping IPv6 Fragments [draft-ietf-6man-overlap-fragment-03] (6 pages) - Implications of Oversized IPv6 Header Chains [draft-ietf-6man-oversized-header-chain-09] (8 pages) - Security Implications of Predictable Fragment Identification Values [draft-ietf-6man-predictable-fragment-id-10] (20 pages) - Using 127-Bit IPv6 Prefixes on Inter-Router Links [draft-ietf-6man-prefixlen-p2p-01] (8 pages) - Discovering PREF64 in Router Advertisements [draft-ietf-6man-ra-pref64-09] (10 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-rdnss-rfc6106bis-16] (19 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-03] (6 pages) - Packet-Loss Resiliency for Router Solicitations [draft-ietf-6man-resilient-rs-06] (6 pages) - Path MTU Discovery for IP version 6 [draft-ietf-6man-rfc1981bis-08] (19 pages) - Internet Protocol, Version 6 (IPv6) Specification [draft-ietf-6man-rfc2460bis-13] (42 pages) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - Default Address Selection for Internet Protocol Version 6 (IPv6) [draft-ietf-6man-rfc3484bis-06] (32 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-11] (23 pages) - IPv6 Node Requirements [draft-ietf-6man-rfc6434-bis-09] (42 pages) - The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams [draft-ietf-6man-rpl-option-06] (9 pages) - An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-6man-rpl-routing-header-07] (13 pages) - IPv6 Neighbor Discovery Optional RS/RA Refresh [draft-ietf-6man-rs-refresh-02] (13 pages) - IPv6 Segment Routing Header (SRH) [draft-ietf-6man-segment-routing-header-26] (27 pages) - Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events [draft-ietf-6man-slaac-renum-01] (18 pages) - Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) [draft-ietf-6man-spring-srv6-oam-07] (22 pages) - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [draft-ietf-6man-stable-privacy-addresses-17] (19 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-07] (14 pages) - IPv6 and UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-08] (12 pages) - Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums [draft-ietf-6man-udpzero-12] (40 pages) - Significance of IPv6 Interface Identifiers [draft-ietf-6man-ug-06] (10 pages) - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [draft-ietf-6man-uri-zoneid-06] (10 pages) - Analysis of the 64-bit Boundary in IPv6 Addressing [draft-ietf-6man-why64-08] (24 pages) - Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-02] (7 pages) - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-jeong-6man-rdnss-rfc6106-bis-00] (18 pages) - Support for adjustable maximum router lifetimes per-link [draft-krishnan-6man-maxra-03] (6 pages) - Packet loss resiliency for Router Solicitations [draft-krishnan-6man-resilient-rs-01] (6 pages) - 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 ND PIO Flags IANA considerations [draft-troan-6man-ndpioiana-01] (4 pages) Requests for Comments: BCP220: IPv6 Node Requirements (42 pages) RFC5172: Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol (7 pages) RFC5453: Reserved IPv6 Interface Identifiers (6 pages) RFC5722: Handling of Overlapping IPv6 Fragments (6 pages) * Updates RFC6946 RFC5871: IANA Allocation Guidelines for the IPv6 Routing Header (3 pages) RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (11 pages) RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) RFC6106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC8106 RFC6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links (8 pages) * Updates RFC6547 RFC6434: IPv6 Node Requirements (30 pages) * Obsoletes RFC8504 RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) RFC6437: IPv6 Flow Label Specification (15 pages) RFC6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (9 pages) RFC6547: RFC 3627 to Historic Status (3 pages) RFC6553: The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams (9 pages) 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) STD86: Internet Protocol, Version 6 (IPv6) Specification (42 pages) STD87: Path MTU Discovery for IP version 6 (19 pages) IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Pascal Thubert Thomas Watteyne Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: 6tisch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch Archive: https://mailarchive.ietf.org/arch/browse/6tisch/ Description of Working Group: 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e". Background/Introduction: ------------------------ Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios. The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT). The nodes in a IEEE802.15.4 TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow- band interference and multi-path fading. These techniques enable a new range of use cases for LLNs, including: - Control loops in a wireless process control network, in which high reliability and a fully deterministic behavior are required. - Service Provider networks transporting data from different independent clients, and for which an operator needs flow isolation and traffic shaping. - Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption. IEEE802.15.4 only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network. Description of Working Group: ----------------------------- The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4 standard. The extent of the problem space for the WG is one or more LLNs, possibly federated through a common backbone link via one or more LLN Border Routers (LBRs). The WG will rely on, and if necessary extend, existing mechanisms for authenticating LBRs. Initially, the WG has limited its scope to distributed routing over a static schedule using the Routing Protocol for LLNs (RPL) on the resulting network. This new charter allows for the dynamic allocation of cells and their exchange between adjacent peers to accommodate the available bandwidth to the variations of throughput in IP traffic. The WG will continue working on securing the join process and making that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH. Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is envisioned that 6TiSCH will benefit from the work of DetNet WG to establish the so-called deterministic tracks. The group will define the objects and methods that need to be configured, and provide the associated requirements to DetNet. The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas. Work Items: ----------- The group will: - Produce a specification of the 6top sublayer that describes the protocol for neighbor nodes to negotiate adding/removing cells. This work will leverage cross participation from IEEE members including the IEEE 6TiSCH Interest Group (IG 6T) to define protocol elements and associated frame formats. - Produce a specification for a default 6top Scheduling Function including the policy to enable distributed dynamic scheduling of timeslots for IP traffic. This may include the capability for nodes to appropriate chunks of the matrix without starving, or interfering with other 6TiSCH nodes. This particular work will focus on IP traffic since the work on tracks is not yet advanced enough to specify their requirements. - Produce requirements to the DetNet WG, detailing 6TiSCH chunks and tracks, and the data models to manipulate them from an external controller such as a PCE. - Produce a specification for a secure 6TiSCH network bootstrap, adapted to the constraints of 6TiSCH nodes and leveraging existing art when possible. - Keep updating the "6TiSCH architecture" that describes the design of 6TiSCH networks. This document highlights the different architectural blocks, signaling and data flows, including the operation of the network in the presence of multiple LBRs. The existing document will be augmented to cover dynamic scheduling and application of the DetNet work but will not be delivered within this round of chartering. - Producing YANG Data Models to manage 6tisch is foreseen, but left to a later phase. Non-milestone work items: ------------------------- The Working Group regularly organizes interoperability events with support from ETSI (i.e., ETSI 6TiSCH Plugtests) to get feedback from implementers early on in the standardization process, and produce better standards. Goals and Milestones: Oct 2018 - Initial submission of draft-ietf-6tisch-dtsecurity-zerotouch-join to the IESG Dec 2018 - Evaluate WG progress, propose new charter to the IESG Done - Second submission of draft-ietf-6tisch-minimal to the IESG Done - WG call to adopt draft-ietf-6tisch-6top-sf0 Done - WG call to adopt draft-ietf-6tisch-6top-sublayer Done - ETSI 6TiSCH #3 plugtests Done - Initial submission of draft-ietf-6tisch-6top-protocol to the IESG Done - Initial submission of draft-ietf-6tisch-minimal-security to the IESG Done - Initial submission of 6TiSCH architecture to the IESG Done - 6TiSCH architecture and terminology in RFC publication queue Internet-Drafts: - 6TiSCH Minimal Scheduling Function (MSF) [draft-chang-6tisch-msf-02] (19 pages) - 6TiSCH Operation Sublayer (6top) Interface [draft-ietf-6tisch-6top-interface-04] (34 pages) - 6TiSCH Operation Sublayer (6top) Protocol (6P) [draft-ietf-6tisch-6top-protocol-12] (50 pages) - 6TiSCH 6top Scheduling Function Zero (SF0) [draft-ietf-6tisch-6top-sf0-05] (14 pages) - 6TiSCH Experimental Scheduling Function (SFX) [draft-ietf-6tisch-6top-sfx-01] (12 pages) - An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 [draft-ietf-6tisch-architecture-29] (71 pages) - 6TiSCH Resource Management and Interaction using CoAP [draft-ietf-6tisch-coap-03] (16 pages) - 6tisch Secure Join protocol [draft-ietf-6tisch-dtsecurity-secure-join-01] (16 pages) - 6tisch Zero-Touch Secure Join protocol [draft-ietf-6tisch-dtsecurity-zerotouch-join-04] (27 pages) - IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information [draft-ietf-6tisch-enrollment-enhanced-beacon-14] (11 pages) - Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [draft-ietf-6tisch-minimal-21] (28 pages) - Constrained Join Protocol (CoJP) for 6TiSCH [draft-ietf-6tisch-minimal-security-15] (53 pages) - 6TiSCH Minimal Scheduling Function (MSF) [draft-ietf-6tisch-msf-18] (22 pages) - Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e [draft-ietf-6tisch-terminology-10] (9 pages) - Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement [draft-ietf-6tisch-tsch-06] (23 pages) - IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information [draft-richardson-6tisch-enrollment-enhanced-beacon-01] (8 pages) - Enabling secure network enrollment in RPL networks [draft-richardson-6tisch-roll-enrollment-priority-03] (6 pages) - 6TiSCH Resource Management and Interaction using CoAP [draft-sudhaakar-6tisch-coap-01] (14 pages) Requests for Comments: BCP210: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration (28 pages) RFC7554: Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement (23 pages) RFC8180: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration (28 pages) RFC8480: 6TiSCH Operation Sublayer (6top) Protocol (6P) (50 pages) Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- Charter Last Modified: 2019-03-28 Current Status: Active Chairs: Daniel Migault Jim Schaad Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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 IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. ACE will need to interact with CORE and LWIG to ensure coordination. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Goals and Milestones: Nov 2018 - Submit DTLS Profile for ACE to the IESG for publication as a proposed standard Sep 2020 - WGLC for Group Communications Done - Submit "Use cases and Requirements" as a WG item. Done - Submit "An Architecture for Authorization in Constrained Environments" as a WG item. Done - Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Done - Submit "Authentication and Authorization for ACE" specification as a WG item. Done - Submit CBOR Web Token draft to the IESG for publication Done - WGLC on CWT Proof of possession Done - Submit CWT Proof of Possession to IESG for publication as proposed standard Done - WGLC for OAuth Authentication and Authorization Solution draft Done - WGLC for DTLS Profile for ACE Done - WGLC on OSCORE Profile for ACE Done - Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. Done - Submit ACE profile for OSCORE 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 ACE [draft-ietf-ace-aif-00] (11 pages) - CBOR Web Token (CWT) [draft-ietf-ace-cbor-web-token-15] (25 pages) - EST over secure CoAP (EST-coaps) [draft-ietf-ace-coap-est-18] (51 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-13] (27 pages) - Key Provisioning for Group Communication using ACE [draft-ietf-ace-key-groupcomm-09] (61 pages) - Key Management for OSCORE Groups in ACE [draft-ietf-ace-key-groupcomm-oscore-08] (50 pages) - Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework [draft-ietf-ace-mqtt-tls-profile-07] (31 pages) - Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) [draft-ietf-ace-oauth-authz-35] (87 pages) - Additional OAuth Parameters for Authorization in Constrained Environments (ACE) [draft-ietf-ace-oauth-params-13] (11 pages) - Admin Interface for the OSCORE Group Manager [draft-ietf-ace-oscore-gm-admin-00] (29 pages) - OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework [draft-ietf-ace-oscore-profile-12] (32 pages) - Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) [draft-ietf-ace-pubsub-profile-01] (21 pages) - Use Cases for Authentication and Authorization in Constrained Environments [draft-ietf-ace-usecases-10] (30 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) Automated Certificate Management Environment (acme) --------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Rich Salz Yoav Nir Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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 2020 - TNAuthlist submitted to IESG Apr 2020 - SMIME submitted to IESG Done - Initial working group draft Done - Submit working group draft to IESG as Proposed Standard Internet-Drafts: - Automatic Certificate Management Environment (ACME) [draft-ietf-acme-acme-18] (95 pages) - ACME Challenges Using an Authority Token [draft-ietf-acme-authority-token-05] (12 pages) - TNAuthList profile of ACME Authority Token [draft-ietf-acme-authority-token-tnauthlist-06] (14 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-02] (14 pages) - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension [draft-ietf-acme-dtnnodeid-00] (18 pages) - Extensions to Automatic Certificate Management Environment for end-user S/MIME certificates [draft-ietf-acme-email-smime-10] (12 pages) - Extensions to Automatic Certificate Management Environment for email TLS [draft-ietf-acme-email-tls-05] (8 pages) - ACME Integrations [draft-ietf-acme-integrations-01] (15 pages) - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension [draft-ietf-acme-ip-08] (5 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 ACME Profile for Generating Delegated STAR Certificates [draft-ietf-acme-star-delegation-04] (33 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) Adaptive DNS Discovery (add) ---------------------------- Charter Last Modified: 2020-08-25 Current Status: Active Chairs: David C. Lawrence Glenn Deen Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Barry Leiba 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: No Requests for Comments Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Jan Seedorf Vijay K. Gurbani Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke Mailing Lists: General Discussion: alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: https://mailarchive.ietf.org/arch/browse/alto/ Description of Working Group: The ALTO working group was established in 2008 to devise a request/response protocol for allowing a host to benefit from a server that is more cognizant of the network infrastructure than the host would be. The working group has developed an HTTP-based protocol to allow hosts to benefit from the network infrastructure by having access to a pair of maps: a topology map and a cost map. The origins of the ALTO protocol lie in peer-to-peer (P2P) applications, where the host is a peer in a P2P network and desires a rendezvous with other peers for file sharing, real-time communications, etc. ALTO is now being considered as a solution for problems outside the P2P domain, such as in datacenter networks and in content distribution networks (CDN) where exposing abstract topologies helps applications. To support the emerging new uses of ALTO, certain extensions are being sought. These extensions can be classified as follows: o Protocol extensions for reducing the volume of on-the-wire data exchange required to align the ALTO server and clients. Extensions under consideration are mechanisms for delivering server-initiated notifications and partial updates of maps. Efforts developed in other working groups such as Websockets and JSON-patch will be considered, as well as bespoke mechanisms specific to the ALTO protocol. o One or more alternatives to the base ALTO server discovery mechanism (RFC-to-be) to accommodate environments where (1) timely deployment of existing mechanisms, including the base ALTO server discovery mechanism, is unlikely, and/or (2) it is desirable for an ALTO client to be able to discover an ALTO server outside its own domain. The WG will consider mechanisms that are in use or defined by other WGs. If such discovery mechanisms can be reused, the WG will produce one or more documents to specify how they may be adopted as additional or alternative ALTO server discovery mechanisms. In the absence of such existing work, the WG will develop one or more ALTO-specific server discovery mechanisms. However, developing a general-purpose service discovery mechanism is not in scope. o Protocol extensions to convey a richer set of attributes to allow applications to determine not only "where" to connect but also "when" to connect. Such additional information will be related both to endpoints (e.g. conveying server load and cache geo-location information for CDN use cases) and to endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent time-averaged cost values in datacenter networks). The working group will specify such extension in coordination with other working groups that have a focus on the related use cases. The scope of extensions is not limited to those identified by the WGs, but is limited by the criteria set out below. o A document specifying how a graph representation format (originating, say, from a YANG data model) can be used in ALTO and optionally be exported by an ALTO server in addition to network and cost maps. The graph representation will be based on existing ALTO abstraction (e.g., PIDs) and complement existing path-based ALTO cost map representation. Together, they provide a more complete, potentially more compact, but still abstract representation of networks for informed traffic optimization among endpoints. In settings with multiple application source- destination pairs with shared links, such a representation will help avoid bottleneck (or failed) links. The WG will not consider, nor will it model, topology internals not affecting endpoints (e.g., routing protocol internals or RIB data). When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility: - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Can a client get that information without excessive privacy and information leakage concerns? Extensions defining new endpoint properties should focus on exposing attributes of endpoints that are related to the goals of ALTO -- optimization of application-layer traffic -- as opposed to more general properties of endpoints. privacy and information leakage aspects of new endpoint properties will in any case be evaluated to the guidelines provided in the IANA considerations and Security Considerations of the ALTO protocol specification (RFC-to-be, sections 14.3 and 15.4 at IESG review time). - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Issues related to the specific content exchanged in systems that make use of ALTO are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones: Jul 2020 - Submit network graph format document Jul 2020 - Submit endpoint property extension document Jul 2020 - Submit cost property extension document Jul 2020 - Submit alto service for CDNI FCI objects Nov 2020 - Recharter or dissolve working group Done - Submit deployment considerations document to IESG as Informational Done - Submit partial updates document Done - Submit server-initiated notifications document Done - Submit alternative server discovery document Internet-Drafts: - Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO [draft-ietf-alto-cdni-request-routing-alto-12] (41 pages) - Application-Layer Traffic Optimization (ALTO) Cost Calendar [draft-ietf-alto-cost-calendar-21] (35 pages) - Application-Layer Traffic Optimization (ALTO) Deployment Considerations [draft-ietf-alto-deployments-16] (77 pages) - ALTO Incremental Updates Using Server-Sent Events (SSE) [draft-ietf-alto-incr-update-sse-22] (58 pages) - Multi-Cost Application-Layer Traffic Optimization (ALTO) [draft-ietf-alto-multi-cost-10] (29 pages) - ALTO Extension: Path Vector [draft-ietf-alto-path-vector-11] (44 pages) - ALTO Performance Cost Metrics [draft-ietf-alto-performance-metrics-12] (32 pages) - Application-Layer Traffic Optimization (ALTO) Problem Statement [draft-ietf-alto-problem-statement-04] (14 pages) - Application-Layer Traffic Optimization (ALTO) Protocol [draft-ietf-alto-protocol-27] (91 pages) - Application-Layer Traffic Optimization (ALTO) Requirements [draft-ietf-alto-reqs-16] (20 pages) - Application-Layer Traffic Optimization (ALTO) Server Discovery [draft-ietf-alto-server-discovery-10] (15 pages) - Unified properties for the ALTO protocol [draft-ietf-alto-unified-props-new-12] (55 pages) - Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery [draft-ietf-alto-xdom-disc-06] (34 pages) Requests for Comments: RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement (14 pages) RFC6708: Application-Layer Traffic Optimization (ALTO) Requirements (20 pages) RFC7285: Application-Layer Traffic Optimization (ALTO) Protocol (91 pages) RFC7286: Application-Layer Traffic Optimization (ALTO) Server Discovery (15 pages) RFC7971: Application-Layer Traffic Optimization (ALTO) Deployment Considerations (77 pages) RFC8189: Multi-Cost Application-Layer Traffic Optimization (ALTO) (29 pages) RFC8686: Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery (34 pages) Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Sheng Jiang Toerless Eckert Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Tech Advisor: Nancy Cam-Winget 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: - An Autonomic Control Plane (ACP) [draft-ietf-anima-autonomic-control-plane-29] (175 pages) - Bootstrapping Remote Secure Key Infrastructures (BRSKI) [draft-ietf-anima-bootstrapping-keyinfra-44] (125 pages) - Support of asynchronous Enrollment in BRSKI (BRSKI-AE) [draft-ietf-anima-brski-async-enroll-00] (35 pages) - Constrained Voucher Artifacts for Bootstrapping Protocols [draft-ietf-anima-constrained-voucher-08] (41 pages) - A Generic Autonomic Signaling Protocol (GRASP) [draft-ietf-anima-grasp-15] (81 pages) - Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) [draft-ietf-anima-grasp-api-07] (32 pages) - Information Distribution over GRASP [draft-ietf-anima-grasp-distribution-01] (29 pages) - Autonomic IPv6 Edge Prefix Management in Large-scale Networks [draft-ietf-anima-prefix-management-07] (22 pages) - A Reference Model for Autonomic Networking [draft-ietf-anima-reference-model-10] (30 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) - 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) Automatic SIP trunking And Peering (asap) ----------------------------------------- Charter Last Modified: 2020-07-24 Current Status: Active Chairs: Adam Roach Gonzalo Salgueiro Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba 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: No Requests for Comments A Semantic Definition Format for Data and Interactions of Things (asdf) ----------------------------------------------------------------------- Charter Last Modified: 2020-10-14 Current Status: Active Chairs: Michael Richardson Niklas Widell Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: asdf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/asdf Archive: https://mailarchive.ietf.org/arch/browse/asdf/ Description of Working Group: ## Background Data and interaction models of IoT devices today exhibit unneeded diversity between different industry ecosystem standards development organizations (SDOs), hindering interoperability across these ecosystems with little discernible benefit from the diversity. Early 2019, One Data Model (OneDM) was started to bring several IoT SDOs and IoT device and platform vendors together under a broad, multi-party liaison agreement, with a goal of arriving at a common set of data and interaction models that describe IoT devices. Ideally, for every class of IoT device, there is just a single model selected/created by the participating organizations, which everyone can adopt. As a common language for writing down these models, the Semantic Definition Format (SDF, draft-onedm-t2trg-sdf) was created, which can represent IoT Things, their composition from reusable Objects, their Interaction Affordances (Properties, Actions, Events), and the data models relevant to describe these Affordances. SDF represents these models in JSON, enabling re-use of specification formats such as CDDL (RFC8610) and the formats proposed at json-schema.org and their tooling, for describing both the SDF format itself and the structure of the data to be modelled in SDF. By July 2020, some 200 models in SDF format have been contributed by participating ecosystems; new models are being submitted continually. Version 1.0 of the SDF specification was published on the OneDM github repository and as an Internet-Draft. OneDM is now focusing on consolidating the body of submitted models and developing processes for arriving at harmonized models that span different industry ecosystems in a common way; as expressed at the IETF 108 ASDF BoF, they look to the IETF for developing SDF 1.0 further into a high-quality specification. The IETF also defines the YANG data modelling language (RFC 7950). YANG has a strong focus on modelling the management interface for network devices, using a fairly small set of network management protocols, whereas SDF is designed to span (and transitively unify) many existing interaction models already present. While data associated with a YANG schema can be serialized to a variety of wire formats (e.g., XML, JSON, CBOR, and others), the serialization is driven directly by the structure of the data models defined in YANG; there is no separate "protocol binding" step as in the use of SDF. Conversely, SDF does not deal directly with serialization at all, modelling only the structure and semantics of the data being interchanged, hence leaving data serialization (and RPC semantics) to other standards, most likely defined by existing IoT SDOs. ## The ASDF Working Group The objective of the ASDF working group is to develop SDF into a standards-track specification for thing interaction and data modelling. In the process of developing this specification, further functional requirements that emerge in the usage of SDF for model harmonization will be addressed. The ASDF WG will work with experts from OneDM and its contributing organizations. In the IETF, it will work closely with the CBOR WG, home of the CDDL specification. It will also engage the still active mailing list of the concluded JSON WG. Recent proposals to form an IRTF formal description techniques (FDT) Research Group might lead to another collaboration partner. ASDF will work with Thing-to-Thing Research Group (T2TRG) and its WISHI (Work on IoT Semantic/Hypermedia Interoperability, http://wishi.space) program to engage researchers and other SDOs in this space, such as W3C Web of Things, which is working on Thing Models and related specifications. Goals and Milestones: Oct 2020 - SDF specification, WG document adopted Sep 2021 - SDF specification, publication requested Internet-Drafts: - 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: 2020-07-15 Current Status: Active Chairs: Dr. Bernard D. Aboba Jonathan Lennox Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Mar 2019 - Submit RTP Payload Format for the TETRA Audio Codec 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 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: - 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) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-03] (44 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) - 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-08] (16 pages) - RTP Clock Source Signalling [draft-ietf-avtcore-clksrc-11] (30 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-08] (58 pages) - RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-17] (13 pages) - Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) [draft-ietf-avtcore-idms-13] (23 pages) - RTP and Leap Seconds [draft-ietf-avtcore-leap-second-08] (9 pages) - Guidelines for Use of the RTP Monitoring Framework [draft-ietf-avtcore-monarch-22] (17 pages) - Multipath RTP (MPRTP) [draft-ietf-avtcore-mprtp-03] (41 pages) - Sending Multiple Types of Media in a Single RTP Session [draft-ietf-avtcore-multi-media-rtp-session-13] (16 pages) - RTP-mixer formatting of multi-party Real-time text [draft-ietf-avtcore-multi-party-rtt-mix-09] (37 pages) - Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams [draft-ietf-avtcore-multiplex-guidelines-12] (43 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) - Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions [draft-ietf-avtcore-rtp-circuit-breakers-18] (25 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 RTCP Reception Statistics and Other Feedback [draft-ietf-avtcore-rtp-multi-stream-optimisation-12] (18 pages) - Options for Securing RTP Sessions [draft-ietf-avtcore-rtp-security-options-10] (37 pages) - RTP Topologies [draft-ietf-avtcore-rtp-topologies-update-10] (48 pages) - RTP Payload Format for Versatile Video Coding (VVC) [draft-ietf-avtcore-rtp-vvc-03] (44 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) - Frame Marking RTP Header Extension [draft-ietf-avtext-framemarking-11] (14 pages) - RTP Payload Format for ISO/IEC 21122 (JPEG XS) [draft-ietf-payload-rtp-jpegxs-05] (28 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-10] (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) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (12 pages) RFC6284: Port Mapping between Unicast and Multicast RTP Sessions (30 pages) RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) RFC6562: Guidelines for the Use of Variable Bit Rate Audio with Secure RTP (6 pages) RFC6642: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report (13 pages) RFC6679: Explicit Congestion Notification (ECN) for RTP over UDP (58 pages) * Updates RFC8311 RFC6792: Guidelines for Use of the RTP Monitoring Framework (17 pages) RFC6904: Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) (15 pages) RFC7007: Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) (4 pages) RFC7022: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (10 pages) RFC7164: RTP and Leap Seconds (9 pages) RFC7201: Options for Securing RTP Sessions (37 pages) RFC7202: Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution (10 pages) RFC7272: Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) (23 pages) RFC7273: RTP Clock Source Signalling (30 pages) RFC7667: RTP Topologies (48 pages) RFC7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) (48 pages) RFC7983: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) (13 pages) RFC8035: Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing (7 pages) RFC8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions (25 pages) RFC8108: Sending Multiple RTP Streams in a Single RTP Session (29 pages) RFC8269: The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) (19 pages) RFC8285: A General Mechanism for RTP Header Extensions (25 pages) RFC8759: RTP Payload for Timed Text Markup Language (TTML) (15 pages) RFC8817: RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec (20 pages) Babel routing protocol (babel) ------------------------------ Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Donald E. Eastlake 3rd Russ White Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux 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: Jun 2019 - IESG Submission of Babel Management draft (Proposed Standard) Done - WG adoption of Babel Applicability draft Done - WG adoption of RFC6126bis 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) 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] (11 pages) - Babel Routing Protocol over Datagram Transport Layer Security [draft-ietf-babel-dtls-10] (10 pages) - MAC authentication for the Babel routing protocol [draft-ietf-babel-hmac-12] (22 pages) - Babel Information Model [draft-ietf-babel-information-model-11] (21 pages) - The Babel Routing Protocol [draft-ietf-babel-rfc6126bis-20] (70 pages) - Delay-based Metric Extension for the Babel Routing Protocol [draft-ietf-babel-rtt-extension-00] (9 pages) - Source-Specific Routing in Babel [draft-ietf-babel-source-specific-06] (11 pages) - IPv4 routes with an IPv6 next-hop in the Babel routing protocol [draft-ietf-babel-v4viav6-00] (8 pages) - YANG Data Model for Babel [draft-ietf-babel-yang-model-06] (38 pages) - Babel HMAC Cryptographic Authentication [draft-ovsienko-babel-rfc7298bis-00] (55 pages) No Requests for Comments BGP Enabled ServiceS (bess) --------------------------- Charter Last Modified: 2019-08-20 Current Status: Active Chairs: Matthew Bocci Stephane Litkowski Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux 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 RFC4364 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 L2VPN to IESG as PS Dec 2020 - Submit a YANG datamodel for mVPN 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 of a multicast VPN MIB to IESG as PS Done - Submit specification for the use of E-VPN for datacenter overlays 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-02] (24 pages) - Controller Based BGP Multicast Signaling [draft-ietf-bess-bgp-multicast-controller-05] (20 pages) - BGP Usage for SDWAN Overlay Networks [draft-ietf-bess-bgp-sdwan-usage-00] (28 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 Segment Routing Enabled Domain Interconnection [draft-ietf-bess-datacenter-gateway-08] (13 pages) - Interconnect Solution for EVPN Overlay networks [draft-ietf-bess-dci-evpn-overlay-10] (29 pages) - Requirements for Extending BGP/MPLS VPNs to End-Systems [draft-ietf-bess-end-system-requirements-00] (16 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-ietf-bess-evpn-ac-df-03] (10 pages) - Fault Management for EVPN networks [draft-ietf-bess-evpn-bfd-01] (22 pages) - Updates on EVPN BUM Procedures [draft-ietf-bess-evpn-bum-procedure-updates-08] (19 pages) - A new Designated Forwarder Election for the EVPN [draft-ietf-bess-evpn-df-election-03] (15 pages) - Framework for Ethernet VPN Designated Forwarder Election Extensibility [draft-ietf-bess-evpn-df-election-framework-09] (32 pages) - Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) [draft-ietf-bess-evpn-etree-14] (23 pages) - Fast Recovery for EVPN DF Election [draft-ietf-bess-evpn-fast-df-recovery-01] (19 pages) - EVPN control plane for Geneve [draft-ietf-bess-evpn-geneve-01] (10 pages) - IGMP and MLD Proxy for EVPN [draft-ietf-bess-evpn-igmp-mld-proxy-05] (33 pages) - Integrated Routing and Bridging in EVPN [draft-ietf-bess-evpn-inter-subnet-forwarding-11] (35 pages) - EVPN Interworking with IPVPN [draft-ietf-bess-evpn-ipvpn-interworking-03] (24 pages) - Extended Mobility Procedures for EVPN-IRB [draft-ietf-bess-evpn-irb-extended-mobility-03] (25 pages) - EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding [draft-ietf-bess-evpn-irb-mcast-05] (77 pages) - LSP-Ping Mechanisms for EVPN and PBB-EVPN [draft-ietf-bess-evpn-lsp-ping-03] (15 pages) - EVPN multi-homing port-active load-balancing [draft-ietf-bess-evpn-mh-pa-00] (11 pages) - EVPN Multi-Homing Extensions for Split Horizon Filtering [draft-ietf-bess-evpn-mh-split-horizon-00] (15 pages) - Seamless Multicast Interoperability between EVPN and MVPN PEs [draft-ietf-bess-evpn-mvpn-seamless-interop-01] (39 pages) - Propagation of ARP/ND Flags in EVPN [draft-ietf-bess-evpn-na-flags-08] (10 pages) - EVPN Operations, Administration and Maintenance Requirements and Framework [draft-ietf-bess-evpn-oam-req-frmwk-04] (19 pages) - Optimized Ingress Replication solution for EVPN [draft-ietf-bess-evpn-optimized-ir-07] (26 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-04] (12 pages) - Preference-based EVPN DF Election [draft-ietf-bess-evpn-pref-df-06] (16 pages) - IP Prefix Advertisement in EVPN [draft-ietf-bess-evpn-prefix-advertisement-11] (36 pages) - Operational Aspects of Proxy-ARP/ND in EVPN Networks [draft-ietf-bess-evpn-proxy-arp-nd-09] (23 pages) - Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing [draft-ietf-bess-evpn-unequal-lb-07] (18 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-06] (22 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-02] (16 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-00] (13 pages) - Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels [draft-ietf-bess-fat-pw-bgp-04] (9 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-04] (23 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-03] (14 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-11] (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) - MVPN and MSDP SA Interoperation [draft-ietf-bess-mvpn-msdp-sa-interoperation-05] (7 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-04] (41 pages) - BGP Control Plane for the Network Service Header in Service Function Chaining [draft-ietf-bess-nsh-bgp-control-plane-18] (71 pages) - Covering Prefixes Outbound Route Filter for BGP-4 [draft-ietf-bess-orf-covering-prefixes-06] (21 pages) - PBB-EVPN ISID-based CMAC-Flush [draft-ietf-bess-pbb-evpn-isid-cmacflush-00] (10 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 with an IPv6 Next Hop [draft-ietf-bess-rfc5549revision-06] (14 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) - SRv6 BGP based Overlay services [draft-ietf-bess-srv6-services-04] (28 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) - 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 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-01] (14 pages) - Interconnect Solution for EVPN Overlay networks [draft-rabadan-bess-dci-evpn-overlay-00] (22 pages) - AC-Influenced Designated Forwarder Election for EVPN [draft-rabadan-bess-evpn-ac-df-05] (10 pages) - Optimized Ingress Replication solution for EVPN [draft-rabadan-bess-evpn-optimized-ir-02] (24 pages) - Preference-based EVPN DF Election [draft-rabadan-bess-evpn-pref-df-02] (12 pages) - EVPN Vendor-Specific Route Type [draft-rabadan-bess-vendor-evpn-route-07] (5 pages) - IP Prefix Advertisement in EVPN [draft-rabadan-l2vpn-evpn-prefix-advertisement-03] (23 pages) - IANA Registry for P-Multicast Service Interface Tunnel Attribute Flags [draft-rosen-bess-pta-flags-00] (3 pages) - Ingress Replication Tunnels in Multicast VPN [draft-rosen-l3vpn-ir-02] (19 pages) - E-TREE Support in EVPN & PBB-EVPN [draft-sajassi-bess-evpn-etree-00] (11 pages) - IGMP and MLD Proxy for EVPN [draft-sajassi-bess-evpn-igmp-mld-proxy-01] (25 pages) - Per multicast flow Designated Forwarder Election for EVPN [draft-sajassi-bess-evpn-per-mcast-flow-df-election-01] (12 pages) - EVPN Virtual Ethernet Segment [draft-sajassi-bess-evpn-virtual-eth-segment-03] (22 pages) - (PBB-)EVPN Seamless Integration with (PBB-)VPLS [draft-sajassi-bess-evpn-vpls-seamless-integ-00] (10 pages) - YANG Data Model for MPLS-based L2VPN [draft-shah-bess-l2vpn-yang-01] (51 pages) - Updated processing of control flags for BGP VPLS [draft-singh-bess-bgp-vpls-control-flags-01] (8 pages) - PIM Proxy in EVPN Networks [draft-skr-bess-evpn-pim-proxy-01] (24 pages) - Loop Protection in EVPN networks [draft-snr-bess-evpn-loop-protect-04] (13 pages) - Propagation of IPv6 Neighbor Advertisement Flags in EVPN [draft-snr-bess-evpn-na-flags-07] (6 pages) - Operational Aspects of Proxy-ARP/ND in EVPN Networks [draft-snr-bess-evpn-proxy-arp-nd-02] (22 pages) - PBB-EVPN ISID-based CMAC-Flush [draft-snr-bess-pbb-evpn-isid-cmacflush-06] (10 pages) - Extended Procedures for EVPN Optimized Ingress Replication [draft-wsv-bess-extended-evpn-optimized-ir-02] (13 pages) - FIB Reduction in Virtual Subnet [draft-xu-l3vpn-virtual-subnet-fib-reduction-02] (6 pages) - Updates on EVPN BUM Procedures [draft-zzhang-bess-evpn-bum-procedure-updates-03] (16 pages) - MVPN and MSDP SA Interoperation [draft-zzhang-bess-mvpn-msdp-sa-interoperation-01] (6 pages) Requests for Comments: RFC7441: Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes (10 pages) RFC7543: Covering Prefixes Outbound Route Filter for BGP-4 (21 pages) RFC7582: Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels (34 pages) * Updates RFC8534 RFC7611: BGP ACCEPT_OWN Community Attribute (8 pages) RFC7716: Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures (22 pages) RFC7734: Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) (11 pages) RFC7740: Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication (8 pages) RFC7814: Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution (15 pages) RFC7899: Multicast VPN State Damping (18 pages) RFC7900: Extranet Multicast in BGP/IP MPLS VPNs (65 pages) * Updates RFC8534 RFC7902: Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags (7 pages) RFC7988: Ingress Replication Tunnels in Multicast VPN (23 pages) RFC8214: Virtual Private Wire Service Support in Ethernet VPN (17 pages) RFC8317: Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) (23 pages) RFC8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) (33 pages) RFC8388: Usage and Applicability of BGP MPLS-Based Ethernet VPN (31 pages) RFC8395: Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels (9 pages) RFC8502: L2L3 VPN Multicast MIB (20 pages) RFC8503: BGP/MPLS Layer 3 VPN Multicast Management Information Base (57 pages) RFC8534: Explicit Tracking with Wildcard Routes in Multicast VPN (21 pages) RFC8560: Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents (16 pages) RFC8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility (32 pages) RFC8614: Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) (9 pages) Binary Floor Control Protocol Bis (bfcpbis) ------------------------------------------- Charter Last Modified: 2020-09-15 Current Status: Active Chairs: Charles Eckel Keith Drage Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: bfcpbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bfcpbis Archive: https://mailarchive.ietf.org/arch/browse/bfcpbis/ Description of Working Group: The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Goals and Milestones: Done - Draft revision of RFC 4582 to IESG as Proposed Standard Done - Draft revision of RFC 4583 to IESG as Proposed Standard Done - Draft for BFCP over WebSocket to IESG as Proposed Standard Done - Draft for SDP WebSocket Connection URI Attribute to IESG as Proposed Standard C Internet-Drafts: - The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-bfcp-websocket-15] (14 pages) - The Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-rfc4582bis-16] (90 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-bfcpbis-rfc4583bis-27] (25 pages) - The Session Description Protocol (SDP) WebSocket Connection URI Attribute [draft-ietf-bfcpbis-sdp-ws-uri-09] (12 pages) Requests for Comments: RFC8124: The Session Description Protocol (SDP) WebSocket Connection URI Attribute (12 pages) Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Jeffrey Haas Reshad Rahman Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux 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 generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD 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 single-hop IPv4 and IPv6 adjacencies 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 multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard Done - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC Done - Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard Done - Submit the BFD Seamless IP draft to the IESG to be considered as a Proposed Standard Done - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Done - Submit a BFD Yang module to the IESG to be considered as a Proposed Standard Done - Submit BFD for VxLAN to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Stability [draft-ashesh-bfd-stability-05] (6 pages) - Unsolicited BFD for Sessionless Applications [draft-chen-bfd-unsolicited-03] (6 pages) - Unaffiliated BFD Echo Function [draft-cw-bfd-unaffiliated-echo-01] (6 pages) - BFD Encapsulated in Large Packets [draft-haas-bfd-large-packets-01] (5 pages) - Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-base-11] (49 pages) - Generic Application of Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-generic-05] (17 pages) - BFD Generic Cryptographic Authentication [draft-ietf-bfd-generic-crypto-auth-06] (13 pages) - Authenticating BFD using HMAC-SHA-2 procedures [draft-ietf-bfd-hmac-sha-05] (8 pages) - Common Interval Support in Bidirectional Forwarding Detection [draft-ietf-bfd-intervals-05] (8 pages) - BFD Encapsulated in Large Packets [draft-ietf-bfd-large-packets-02] (7 pages) - Bidirectional Forwarding Detection (BFD) Management Information Base [draft-ietf-bfd-mib-22] (39 pages) - Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-mpls-07] (12 pages) - BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks [draft-ietf-bfd-mpls-mib-07] (23 pages) - Bidirectional Forwarding Detection (BFD) for Multihop Paths [draft-ietf-bfd-multihop-09] (6 pages) - Bidirectional Forwarding Detection (BFD) for Multipoint Networks [draft-ietf-bfd-multipoint-19] (23 pages) - Bidirectional Forwarding Detection (BFD) Multipoint Active Tails [draft-ietf-bfd-multipoint-active-tail-10] (20 pages) - Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [draft-ietf-bfd-on-lags-04] (11 pages) - Optimizing BFD Authentication [draft-ietf-bfd-optimizing-authentication-11] (8 pages) - Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-rfc5884-clarifications-04] (7 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) [draft-ietf-bfd-seamless-base-11] (24 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS [draft-ietf-bfd-seamless-ip-06] (8 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases [draft-ietf-bfd-seamless-use-case-08] (15 pages) - Secure BFD Sequence Numbers [draft-ietf-bfd-secure-sequence-numbers-06] (6 pages) - BFD Stability [draft-ietf-bfd-stability-06] (6 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-08] (11 pages) - Unaffiliated BFD Echo Function [draft-ietf-bfd-unaffiliated-echo-00] (6 pages) - Unsolicited BFD for Sessionless Applications [draft-ietf-bfd-unsolicited-02] (12 pages) - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-11] (7 pages) - BFD for VXLAN [draft-ietf-bfd-vxlan-16] (11 pages) - YANG Data Model for Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-yang-17] (79 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 Point-to-Point MPLS LSP [draft-mirsky-bfd-mpls-demand-08] (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) Bit Indexed Explicit Replication (bier) --------------------------------------- Charter Last Modified: 2020-03-20 Current Status: Active Chairs: Greg Shepherd Tony Przygienda Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Secretary: Zheng Zhang Mailing Lists: General Discussion: bier@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bier Archive: https://mailarchive.ietf.org/arch/browse/bier/ Description of Working Group: The BIER (Bit Index Explicit Replication) Working Group has defined an architecture [RFC 8279] for multicast forwarding that uses an encapsulation [RFC 8296] that can be used on MPLS or Ethernet transport. The BIER-WG is now chartered to produce Standards Track RFCs, including the status update for RFCs 8279 and 8296. The BIER working group's original charter required the publication of an Informational RFC describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms as well as an analysis of the impact and benefit of the BIER data-plane to the overall Internet architecture. The WG did not produce this RFC, but the goals of that milestone have nevertheless been reached; i.e., the industry has demonstrated interest in deploying BIER and the trade-offs are now well understood. Therefore, BIER is proceeding with work on the Standards Track. The focus of the BIER-WG is on deployment: transition, partial deployments, applicability and management. First and primarily, the BIER-WG will complete its work on: 1) Transition Mechanisms and Partial Deployments: The WG will describe how BIER can be introduced in existing multicast networks to shift multicast delivery, either end-to-end or in part of a network, from mechanisms such as PIM, ng-MVPN, etc. BIER operation in networks where not all routers are BIER capable or have other BIER support constraints should be addressed. How to handle routers supporting BIER with different BitStringLengths and encapsulations should be addressed. Each new mechanism should include an applicability statement that clearly describes its utility and distinctions from already standardized mechanisms. 2) Applicability Statements: The WG will continue to work on documents describing how BIER can be applied, as has been done for MVPN in draft-ietf-bier-mvpn. A document describing applicability to EVPN should be published. 3) Use Case: The WG will produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. 4) Manageability and OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 5) Management models: The WG will work on YANG models to manage BIER. 6) Link-State Routing and BGP extensions: The BIER-WG has already defined the basic information needed to set up the BIER forwarding tables via advertisements in OSPFv2 and ISIS; the extensions to OSPFv3 will be specified. Additional extensions may be needed - for example, to support constraining the topology on which a particular BIER sub-domain operates. Any necessary extensions to the IGP will be specified by the WG as Standards Track, in cooperation with the LSR WG. The BIER-WG shall also specify the extensions to support BIER for BGP when used as an IGP (see RFC 7938) and to provide BIER-specific information in BGP-LS, in cooperation with IDR. The BIER-WG is additionally chartered to start Standards Track work on: 7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be standardized if coordinated with the 6MAN WG and with understood applicability. 8) Forwarding Plane Mechanisms for BIER Traffic Engineering: definition of how the new BIER forwarding plane structures (e.g. BIFT) can be used to support engineered multicast trees. No control-plane work will be done in BIER-WG. The BIER-WG will serve as a forum to discuss how BIER can be applied. The BIER-WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include: * mpls on the associated MPLS-based OAM mechanisms, * lsr on OSPF and ISIS extensions to flood BIER-related information, * babel on Babel extensions to support BIER, * bess and idr on BGP extensions to flood BIER-related information and the applicability of existing BGP-based mechanisms for providing multicast group membership information, * pim and mboned on the applicability of and extensions to PIM, IGMP, and MLD to support BIER operations and transition, * pce on extensions to program BIER forwarding on the BFIRs,and * teas on architecture and control-plane mechanisms to use BIER-TE forwarding mechanisms. Goals and Milestones: Mar 2018 - Published as proposed standard: draft-ietf-bier-mvpn Mar 2018 - Published as proposed standard: draft-ietf-bier-ospf-bier-extensions Mar 2018 - Published as proposed standard: draft-ietf-bier-isis-extensions Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-oam-requirements Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-path-mtu-discovery Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-pmmm-oam Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-ping Mar 2018 - Shepherd/IESG queue: draft-ietf-bier-use-cases Mar 2018 - WGLC: draft-ietf-bier-idr-extensions Mar 2018 - WGLC: draft-ietf-bier-bgp-ls-bier-ext Mar 2018 - WG call for adoption: draft-hfa-bier-pim-signaling Mar 2018 - IETF 101 discuss BIER-TE documents adoption Mar 2018 - IETF 101 discuss and target mechanisms for BIER transition Jul 2018 - Publish as proposed standard: draft-ietf-bier-oam-requirements Jul 2018 - Publish as proposed standard: draft-ietf-bier-path-mtu-discovery Jul 2018 - Publish as proposed standard: draft-ietf-bier-pmmm-oam Jul 2018 - Publish as proposed standard:draft-ietf-bier-ping Jul 2018 - Publish as proposed standard: draft-ietf-bier-use-cases Jul 2018 - WGLC: draft-ietf-bier-evpn Nov 2018 - Target feasibility and solution selection for IPv6 encap Nov 2018 - Progress YANG BIER drafts to WGLC Nov 2018 - Publish document(s) solidifying BAR/IPA complexity Mar 2019 - WGLC BIER-TE drafts Internet-Drafts: - YANG Data Model for BIER Protocol [draft-chh-bier-bier-yang-04] (19 pages) - Multicast Using Bit Index Explicit Replication (BIER) [draft-ietf-bier-architecture-08] (43 pages) - BIER Underlay Path Calculation Algorithm and Constraints [draft-ietf-bier-bar-ipa-07] (6 pages) - BGP Link-State extensions for BIER [draft-ietf-bier-bgp-ls-bier-ext-07] (11 pages) - YANG Data Model for BIER Protocol [draft-ietf-bier-bier-yang-07] (17 pages) - Use of BIER Entropy for Data Center Clos Networks [draft-ietf-bier-entropy-staged-dc-clos-04] (9 pages) - EVPN BUM Using BIER [draft-ietf-bier-evpn-03] (14 pages) - BGP Extensions for BIER [draft-ietf-bier-idr-extensions-07] (7 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-01] (13 pages) - BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols [draft-ietf-bier-mld-04] (16 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) - Applicability of BIER Multicast Overlay for Adaptive Streaming Services [draft-ietf-bier-multicast-http-response-04] (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-02] (6 pages) - Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-oam-requirements-10] (6 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-02] (10 pages) - Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-path-mtu-discovery-08] (8 pages) - BIER Penultimate Hop Popping [draft-ietf-bier-php-06] (7 pages) - PIM Signaling Through BIER Core [draft-ietf-bier-pim-signaling-10] (15 pages) - BIER Ping and Trace [draft-ietf-bier-ping-07] (25 pages) - Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer [draft-ietf-bier-pmmm-oam-08] (9 pages) - BIER Prefix Redistribute [draft-ietf-bier-prefix-redistribute-00] (12 pages) - Bit Indexed Explicit Replication (BIER) Problem Statement [draft-ietf-bier-problem-statement-00] (13 pages) - Tree Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-arch-08] (47 pages) - A YANG data model for Traffic Engineering for Bit Index Explicit Replication (BIER-TE) [draft-ietf-bier-te-yang-02] (17 pages) - Tethering A BIER Router To A BIER incapable Router [draft-ietf-bier-tether-00] (9 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) 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) RFC8444: OSPFv2 Extensions for Bit Index Explicit Replication (BIER) (12 pages) RFC8556: Multicast VPN Using Bit Index Explicit Replication (BIER) (17 pages) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2017-10-03 Current Status: Active Chairs: Al Morton Sarah Banks Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bmwg Archive: https://mailarchive.ietf.org/arch/browse/bmwg/ Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. The scope of BMWG has been extended to develop methods for virtual network functions (VNF) and their unique supporting infrastructure (such as SDN Controllers and vSwitches). Benchmarks for platform capacity and performance characteristics of virtual routers, firewalls (and other security functions), signaling control gateways, and other forms of gateways are included. The benchmarks will foster comparisons between physical and virtual network functions, and also cover unique features of Network Function Virtualization systems. Also, with the emergence of virtualized test systems, specifications for test system calibration are also in-scope. Each recommendation will describe the class of network function, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the community of users (e.g., network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminologies will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the description of the task. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for development and advancement of measurements which provide insight on the capabilities and operation of implementations of inter-networking technology. Ideally, BMWG should communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT, and consult with/inform other IETF WGs (as is the current practice). Goals and Milestones: Aug 2020 - Methodology for Next-Gen Firewall Benchmarking to IESG Review Aug 2020 - Update to RFC2544 Back-to-back Frame Benchmarking to IESG Review Aug 2020 - Methodology for EVPN Benchmarking to IESG Review Dec 2020 - Draft on Selecting and Applying Model(s) for Benchmarking to IESG Review Dec 2020 - Draft on General VNF Benchmarking Automation to IESG Review Dec 2020 - Considerations for Benchmarking Network Virtualization Platforms to IESG Review Internet-Drafts: - Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-08] (11 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (127 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-00] (32 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (16 pages) - Updates for the Back-to-back Frame Benchmark in RFC 2544 [draft-ietf-bmwg-b2b-frame-02] (14 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) - Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence [draft-ietf-bmwg-bgp-basic-convergence-05] (35 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-04] (19 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-06] (36 pages) - Data Center Benchmarking Methodology [draft-ietf-bmwg-dcbench-methodology-18] (19 pages) - Data Center Benchmarking Terminology [draft-ietf-bmwg-dcbench-terminology-19] (20 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-13] (34 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Benchmarking Methodology for EVPN and PBB-EVPN [draft-ietf-bmwg-evpntest-06] (28 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (15 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (34 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-08] (26 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-17] (6 pages) - Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-23] (42 pages) - Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-23] (29 pages) - IMIX Genome: Specification of Variable Packet Sizes for Additional Testing [draft-ietf-bmwg-imix-genome-05] (10 pages) - IP Flow Information Accounting and Export Benchmarking Methodology [draft-ietf-bmwg-ipflow-meth-10] (39 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-05] (20 pages) - Benchmarking the Neighbor Discovery Protocol [draft-ietf-bmwg-ipv6-nd-06] (17 pages) - Benchmarking Methodology for IPv6 Transition Technologies [draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08] (30 pages) - Benchmarking Methodology for In-Service Software Upgrade (ISSU) [draft-ietf-bmwg-issu-meth-02] (16 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-06] (25 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-08] (16 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-14] (31 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-02] (30 pages) - 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) - Benchmarking Methodology for Network Security Device Performance [draft-ietf-bmwg-ngfw-performance-04] (58 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-07] (11 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-10] (16 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-10] (9 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection [draft-ietf-bmwg-protection-meth-14] (35 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-09] (33 pages) - Device Reset Characterization [draft-ietf-bmwg-reset-06] (17 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-meth-09] (64 pages) - Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance [draft-ietf-bmwg-sdn-controller-benchmark-term-10] (23 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-08] (26 pages) - Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration [draft-ietf-bmwg-sip-bench-meth-12] (21 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration [draft-ietf-bmwg-sip-bench-term-12] (20 pages) - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-01] (12 pages) - Traffic Management Benchmarking [draft-ietf-bmwg-traffic-management-06] (51 pages) - Considerations for Benchmarking Virtual Network Functions and Their Infrastructure [draft-ietf-bmwg-virtual-net-05] (15 pages) - Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) [draft-ietf-bmwg-vswitch-opnfv-04] (24 pages) - Benchmarking Methodology for EVPN and PBB-EVPN [draft-kishjac-bmwg-evpntest-10] (22 pages) 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) 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) Calendaring Extensions (calext) ------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Bron Gondwana Daniel Migault Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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 Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Develop an extension to iCalendar to support non-Gregorian recurrence rules, without the need to support new calendar scale values in iCalendar as a whole. This will allow for easy implementation of the primary use case for non-Gregorian support in calendar systems, without the need for significant changes to the iCalendar format. The non-Gregorian calendar system should be based on the International Components for Unicode work by the Unicode Consortium (http://site.icu-project.org). - Develop an extension to iCalendar to support a new component type that allows users to express arbitrary, possibly repeating, periods of "available" time. The primary use case for this is for users to express their "office hours" (e.g., Monday-Friday, 9am-5pm) in a standard way to ensure free busy lookups show the correct periods of availability. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations. - Define a set of new iCalendar properties and parameters to cover key uses cases that implementers have identified, including, but not limited to, a new "IMAGE" property (to allow embedding/linking of images tied to a specific event), and a "CONFERENCE" property (to allow embedding information about dial-in numbers and similar multi-party communication options for an event). The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. Interface with the httpbis working group to ensure that any CalDAV changes are consistent with good http practices. The working group will use the following drafts as initial input for its work: draft-daboo-icalendar-rscale-03 draft-daboo-calendar-availability-05 draft-daboo-icalendar-extensions-08 The following are out of scope for the working group: - Any change that impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers will be discussed by the working group with a view to minimizing disruption to deployed implementations without compromising desirable new function. - Any attempt to develop non-Gregorian calendar systems/calculations. Goals and Milestones: Jul 2020 - Submit valarm document to IESG for publication Aug 2020 - Send JSCalendar draft to IESG Aug 2020 - Submit scheduling controls document to IESG for publication Aug 2020 - Submit icalendar relations document to IESG for publication Sep 2020 - Submit JSCalendar mapping document to IESG for publication Dec 2020 - Submit calendar series document to IESG for publication Dec 2020 - Submit Subscription Upgrade document to IESG for publication Dec 2020 - Submit Serverside Subscription draft to IESG for publication Mar 2021 - Submit vpoll document to IESG for publication Done - Submit non-Gregorian recurrence rule draft to IESG for publication Done - WG adoption of an availability draft Done - WG adoption of an extensions draft Done - Submit availability draft to IESG for publication Done - Submit extensions draft to IESG for publication Done - Send attachment dratf to IESG Done - Adopt a document for subscription upgrade Done - Send Event Publication draft to IESG Done - Send iCal relation draft to IESG Done - Adopt a document for consensus scheduling Done - Update charter/milestones to reflect current and planned work Done - Adopt a draft for Server Side Subscription 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-16] (36 pages) - New Properties for iCalendar [draft-ietf-calext-extensions-05] (23 pages) - Support for iCalendar Relationships [draft-ietf-calext-ical-relations-05] (19 pages) - Support for Series in iCalendar [draft-ietf-calext-icalendar-series-02] (26 pages) - JSCalendar: A JSON representation of calendar data [draft-ietf-calext-jscalendar-32] (85 pages) - JSCalendar: Converting from and to iCalendar [draft-ietf-calext-jscalendar-icalendar-02] (54 pages) - JSContact: A JSON representation of contact data [draft-ietf-calext-jscontact-00] (17 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-00] (11 pages) - Calendar subscription upgrades [draft-ietf-calext-subscription-upgrade-02] (15 pages) - VALARM Extensions for iCalendar [draft-ietf-calext-valarm-extensions-02] (16 pages) - VPOLL: Consensus Scheduling Component for iCalendar [draft-ietf-calext-vpoll-01] (62 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) Captive Portal Interaction (capport) ------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Erik Kline Martin Thomson Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: captive-portals@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/captive-portals Archive: https://mailarchive.ietf.org/arch/search/?email_list=captive-portals Description of Working Group: Some networks require interaction from users prior to authorizing network access. Before that authorization is granted, network access might be limited in some fashion. Frequently, this authorization process requires human interaction to arrange for payment or to accept some legal terms. Currently, network providers use a number of interception techniques to reach a human user (such as intercepting cleartext HTTP to force a redirect to a web page of their choice), and these interceptions are indistinguishable from man-in-the-middle attacks. As endpoints become inherently more secure, existing interception techniques will become less effective or will fail entirely. This will result in a poor user experience as well as a lower rate of success for the Captive Portal operator. The CAPPORT Working Group will define secure mechanisms and protocols to - allow endpoints to discover that they are in this sort of limited environment, - provide a URL to interact with the Captive Portal, - allow endpoints to learn about the parameters of their confinement, - interact with the Captive Portal to obtain information such as status and remaining access time, and - optionally, advertise a service whereby devices can enable or disable access to the Internet without human interaction. (RFC 7710 may be a full or partial solution to the first two bullets) The working group may produce working documents to define taxonomy and to survey existing portals and solutions. These might or might not be published as RFCs, and might or might not be combined in some way. Out of scope are "roaming" (federation of credentials), network selection, or the on-boarding/provisioning of clients onto secure (or any alternate) networks. These are not really captive portals, and have largely been solved in other ways. Initially, the working group will focus on simplifying captive portal interactions where a user is present. A secondary goal is to look at the problem posed to or by devices that have little or no recourse to human interaction. Goals and Milestones: Jul 2019 - Protocol to discover and interact with a Captive Portal Jul 2019 - API for Captive Portal Interaction Jul 2019 - API for Captive Portal Interaction Internet-Drafts: - Captive Portal API [draft-ietf-capport-api-08] (11 pages) - Captive Portal Architecture [draft-ietf-capport-architecture-10] (24 pages) - Captive-Portal Identification in DHCP and Router Advertisements (RAs) [draft-ietf-capport-rfc7710bis-11] (11 pages) Requests for Comments: RFC8908: Captive Portal API (11 pages) RFC8910: Captive-Portal Identification in DHCP and Router Advertisements (RAs) (11 pages) Concise Binary Object Representation Maintenance and Extensions (cbor) ---------------------------------------------------------------------- Charter Last Modified: 2020-10-09 Current Status: Active Chair: Francesca Palombini Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: cbor@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Description of Working Group: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group has updated RFC 7049 to deal with existing errata, and the new version, draft-ietf-cbor-7049bis, is in the RFC Editor queue to become an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. CDDL has been published as RFC 8610. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other than manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and, where warranted, progress them either in a standalone document or as part of a new edition of the specification. The working group will define the approach to further evolving CDDL as a sequence of editions, which might also add further extension points, probably as part of the introduction of the next edition of the CDDL base specification. The body of existing specifications that make use of CDDL is considered precious, and the WG will set out not to damage their value. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF as an RFC. There are a number of additional CBOR tagged types and CBOR related media type specifications that are currently adopted by the working group, are work items in other working groups, or exist as individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases, the working group expects to adopt and publish these proposals, and for those the working group will evaluate them individually and decide about adoption and milestones. Proposals that are deemed to be out of scope for the working group, for example because they are too narrow in purpose, may still be published as individual submissions or in another groups if there is a specific need. The CBOR group will review these proposals on request. Goals and Milestones: Internet-Drafts: - Additional Control Operators for CDDL [draft-bormann-cbor-cddl-control-02] (10 pages) - Packed CBOR [draft-bormann-cbor-packed-01] (9 pages) - Concise Binary Object Representation (CBOR) Tags for Object Identifiers [draft-bormann-cbor-tags-oid-07] (14 pages) - Concise Binary Object Representation (CBOR) [draft-ietf-cbor-7049bis-16] (80 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 CDDL [draft-ietf-cbor-cddl-control-00] (10 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-ietf-cbor-date-tag-07] (7 pages) - Packed CBOR [draft-ietf-cbor-packed-00] (9 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-01] (14 pages) - Concise Binary Object Representation (CBOR) Tags for Date [draft-jones-cbor-date-tag-01] (5 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) Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2015-10-07 Current Status: Active Chairs: Daniele Ceccarelli Fatai Zhang Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Oscar de Dios 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: Feb 2015 - Submit OTN signal types update and sub registry drafts to IESG for review Apr 2015 - Submit flexi grid framework to IESG for review Apr 2015 - First draft of G.698.2 LMP and MIBs working group draft Jun 2015 - First draft of technology specific version of signaling and routing bandwidth availability working group draft. Jun 2015 - First draft of Information Encoding for WSON with Impairments Validation working group draft Jul 2015 - First version of YANG modelling for flexi grid Working Group draft Sep 2015 - Submit flexi grid label, signaling and routing extensions to IESG for review Oct 2015 - Submit flexi grid LMP to IESG for review Nov 2015 - First versions of impairments related solutions Working Group drafts Dec 2015 - Submit Info Model for WSON with impairments validation to IESG for review Feb 2016 - Submit G.698.2 LMP and MIBs drafts to IESG for review Mar 2016 - Submit technology specific version of signaling and routing bandwidth availability draft to IESG for review May 2016 - Submit Information Encoding for WSON with Impairments Validation draft to IESG for review May 2016 - Submit YANG modelling for flexi grid draft to IESG for review Jul 2016 - Recharter or close Working Group Jul 2016 - Submit impairments related solutions for IESG review Done - Post strawman WG goals and charter Done - Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done - Build appropriate design teams Done - Submit WG document defining 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 GMPLS MIBs to IESG Done - Submit protection & restoration documents to IESG Done - Submit ASON signaling 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 ASON routing requirements doc to IESG Done - Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done - First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done - Submit ASON Routing evaluation I-D for IESG review Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D MPLS to GMPLS migration strategies Done - Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done - Submit Per-domain path computation signaling I-D for IESG review 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 - First version WG I-D for Evaluation of existing protocols for MLN/MRN 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 Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - Submit GMPLS/ASON lexicography I-D for IESG review Done - Submit LSP Stitching I-D for IESG review Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done - First version WG I-D GMPLS OAM Requirements Done - Submit GMPLS routing and signaling interoperability advice I-D for IESG review Done - Submit MPLS to GMPLS migration strategies I-D for IESG review Done - Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Done - Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Done - Submit Evaluation of existing protocols for MLN/MRN for IESG review Done - Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Done - First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Done - Submit Protocol solutions for MLN/MRN I-D for IESG review Done - First version of WSON routing related Working Group drafts Done - Submit Ethernet related drafts for IESG review Done - Submit hierarchy bis for IESG review Done - First version of 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 - Submit TE MIB module IESG review Done - Submit VCAT/LCAS with GMPLS for IESG review 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 OAM configuration solutions Working Group draft Done - First version of G.709 enhancements solutions Working Group drafts Done - First version of Working Group draft defining RSVP-TE extensions for MPLS-TP Done - Submit Control Plane Framework for MPLS-TP for IESG review Done - Submit RSVP-TE extensions for MPLS-TP for IESG review Done - Submit OAM configuration framework for IESG review Done - Submit LMP Negotiation for IESG review Done - Submit G.709 enhancements framework for IESG review Done - Submit G.709 enhancements solutions for IESG review Done - First version flexigrid requirements/framework Working Group draft Done - Submit first set of OAM configuration solutions for IESG review Done - Submit last OAM configuration solutions for IESG review Done - Submit WSON routing related drafts for IESG review Done - Submit WSON signaling related draft for IESG review 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) - 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) - 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 Transport Network Client Signals [draft-ietf-ccamp-client-signal-yang-03] (55 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-02] (16 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-04] (25 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) - 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) - 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) - Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers [draft-ietf-ccamp-flexigrid-lambda-label-05] (14 pages) - YANG data model for Flexi-Grid media-channels [draft-ietf-ccamp-flexigrid-media-channel-yang-02] (36 pages) - A YANG Data Model for Flexi-Grid Optical Networks [draft-ietf-ccamp-flexigrid-yang-07] (69 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 MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-04] (15 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 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 B100G Optical Transport Network [draft-ietf-ccamp-gmpls-otn-b100g-applicability-02] (19 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) - Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [draft-ietf-ccamp-gmpls-te-mib-16] (60 pages) - Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-15] (40 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 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-12] (18 pages) - A YANG Data Model for Layer 0 Types [draft-ietf-ccamp-layer0-types-08] (21 pages) - A YANG Data Model for Layer 1 Types [draft-ietf-ccamp-layer1-types-07] (38 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-01] (27 pages) - A YANG Data Model for Microwave Radio Link [draft-ietf-ccamp-mw-yang-13] (53 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-04] (58 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) - 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-11] (73 pages) - OTN Tunnel YANG Model [draft-ietf-ccamp-otn-tunnel-model-11] (37 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) - 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-11] (99 pages) - Transport Northbound Interface Applicability Statement and Use Cases [draft-ietf-ccamp-transport-nbi-use-cases-01] (28 pages) - Generic Tunnel Tracing Protocol (GTTP) Specification [draft-ietf-ccamp-tunproto-01] (36 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-01] (37 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments [draft-ietf-ccamp-wson-impairments-10] (31 pages) - Information Encoding for WSON with Impairments Validation [draft-ietf-ccamp-wson-iv-encode-02] (11 pages) - Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation [draft-ietf-ccamp-wson-iv-info-12] (19 pages) - GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signal-compatibility-ospf-17] (12 pages) - Signaling Extensions for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signaling-12] (16 pages) - A Yang Data Model for WSON Tunnel [draft-ietf-ccamp-wson-tunnel-model-05] (40 pages) - A YANG Data Model for WSON (Wavelength Switched Optical Networks) [draft-ietf-ccamp-wson-yang-27] (63 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) - 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) 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 RFC4873: GMPLS Segment Recovery (25 pages) 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) 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) Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: François Le Faucheur Kevin J. Ma Phil Sorber Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Jun 2020 - Recharter or dissolve Jun 2020 - Submit specification of CDNI Control Triggers Interface Extensions to IESG as Proposed Standard Jun 2020 - Submit specification of CDNI Extensions for HTTPS Delegation to IESG as Proposed Standard 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 Internet-Drafts: - CDNI SVA Request Routing Extensions [draft-finkelman-cdni-rr-sva-extensions-01] (11 pages) - Content Delivery Network Interconnection (CDNI) Control Interface / Triggers [draft-ietf-cdni-control-triggers-15] (49 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 extensions for HTTPS delegation [draft-ietf-cdni-interfaces-https-delegation-04] (11 pages) - Content Distribution Network Interconnection (CDNI) Logging Interface [draft-ietf-cdni-logging-27] (63 pages) - Content Delivery Network Interconnection (CDNI) Media Type Registration [draft-ietf-cdni-media-type-06] (7 pages) - Content Delivery Network Interconnection (CDNI) Metadata [draft-ietf-cdni-metadata-21] (66 pages) - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-08] (32 pages) - Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection [draft-ietf-cdni-redirection-20] (35 pages) - Content Delivery Network Interconnection (CDNI) Request Routing Extensions [draft-ietf-cdni-request-routing-extensions-08] (17 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-17] (23 pages) - CDNI Control Triggers Interface Extensions [draft-ietf-cdni-triggers-extensions-06] (43 pages) - URI Signing for CDN Interconnection (CDNI) [draft-ietf-cdni-uri-signing-19] (42 pages) - Use Cases for Content Delivery Network Interconnection [draft-ietf-cdni-use-cases-10] (16 pages) Requests for Comments: RFC6707: Content Distribution Network Interconnection (CDNI) Problem Statement (32 pages) RFC6770: Use Cases for Content Delivery Network Interconnection (16 pages) RFC7336: Framework for Content Distribution Network Interconnection (CDNI) (58 pages) RFC7337: Content Distribution Network Interconnection (CDNI) Requirements (23 pages) RFC7736: Content Delivery Network Interconnection (CDNI) Media Type Registration (7 pages) RFC7937: Content Distribution Network Interconnection (CDNI) Logging Interface (63 pages) RFC7975: Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection (35 pages) RFC8006: Content Delivery Network Interconnection (CDNI) Metadata (66 pages) RFC8007: Content Delivery Network Interconnection (CDNI) Control Interface / Triggers (49 pages) RFC8008: Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics (31 pages) RFC8804: Content Delivery Network Interconnection (CDNI) Request Routing Extensions (17 pages) Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ Charter Last Modified: 2020-07-13 Current Status: Active Chairs: Michael Richardson Spencer Dawkins Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: cellar@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cellar Archive: https://mailarchive.ietf.org/arch/browse/cellar/ Description of Working Group: The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community. FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption. There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption. Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Initial specifications can be accessed here: Specifications: - FFV1: https://mediaarea.net/temp/ffv1.html - Matroska: http://matroska.org/technical/specs/index.html - EBML: http://matroska-org.github.io/libebml/specs.html - FLAC: https://xiph.org/flac/format.html Development Versions: - FFV1: https://github.com/ffmpeg/ffv1 - Matroska: https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml - EBML: https://github.com/Matroska-Org/ebml-specification The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. Deliverables: - Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication - Standards Track specification for Matroska container format version 4 to IESG for publication - Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication - Standards Track specification for FFV1 video codec version 4 to IESG for publication - Standards Track specification for FLAC audio codec to IESG for publication Goals and Milestones: Apr 2019 - Submit specification for Matroska container format version 4 to IESG (Standards Track) Jun 2020 - Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication Sep 2020 - Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Apr 2021 - Submit specification for FLAC audio codec to IESG (Standards Track) Done - Adopt matroska specifications as WG documents Done - Adopt matroska specifications as WG documents Done - Submit specification for EBML to IESG (Standards Track) Done - Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Internet-Drafts: - Matroska Media Container Codec Specifications [draft-ietf-cellar-codec-05] (53 pages) - Extensible Binary Meta Language [draft-ietf-cellar-ebml-17] (51 pages) - FFV1 Video Coding Format Version 0, 1, and 3 [draft-ietf-cellar-ffv1-18] (56 pages) - FFV1 Video Coding Format Version 4 [draft-ietf-cellar-ffv1-v4-15] (56 pages) - Free Lossless Audio Codec [draft-ietf-cellar-flac-00] (31 pages) - Matroska Media Container Format Specifications [draft-ietf-cellar-matroska-06] (171 pages) - Matroska Media Container Tag Specifications [draft-ietf-cellar-tags-05] (17 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) Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Jaime Jimenez Marco Tiloca Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Dec 2017 - Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS Dec 2017 - CBOR Encoding of Data Modeled with YANG submitted to IESG for PS Dec 2017 - Object Security for Constrained RESTful Environments (OSCORE) Jan 2018 - Management over CoAP submitted to IESG for PS Mar 2018 - CoRE Resource Directory submitted to IESG for PS Dec 2099 - CoRE Interfaces submitted to IESG Done - Blockwise transfers in CoAP submitted to IESG Done - Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG Done - Representing CoRE Link Collections in JSON submitted to IESG Done - Patch and Fetch Methods for CoAP submitted to IESG for PS Done - WG adoption for Management over CoAP Done - CoAP over TCP, TLS, and WebSockets submitted to IESG for PS Internet-Drafts: - SenML Features and Versions [draft-bormann-core-senml-versions-01] (5 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) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-hartke-core-stateless-02] (16 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) - Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-pubsub-09] (25 pages) - CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [draft-ietf-core-coap-tcp-tls-11] (54 pages) - CoAP Simple Congestion Control/Advanced [draft-ietf-core-cocoa-03] (18 pages) - CoAP Management Interface (CORECONF) [draft-ietf-core-comi-10] (52 pages) - The Constrained RESTful Application Language (CoRAL) [draft-ietf-core-coral-03] (40 pages) - Uniform Resource Names for Device Identifiers [draft-ietf-core-dev-urn-07] (17 pages) - Dynamic Resource Linking for Constrained RESTful Environments [draft-ietf-core-dynlink-11] (24 pages) - CoAP: Echo, Request-Tag, and Token Processing [draft-ietf-core-echo-request-tag-10] (31 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-01] (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-01] (41 pages) - Constrained Application Protocol (CoAP) Hop-Limit Option [draft-ietf-core-hop-limit-07] (8 pages) - Constrained Resource Identifiers [draft-ietf-core-href-03] (12 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 for Faster Transmission [draft-ietf-core-new-block-01] (24 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) - Group OSCORE - Secure Group Communication for CoAP [draft-ietf-core-oscore-groupcomm-09] (70 pages) - Problem Details For CoAP APIs [draft-ietf-core-problem-details-01] (7 pages) - CoRE Resource Directory: DNS-SD mapping [draft-ietf-core-rd-dns-sd-05] (14 pages) - CoRE Resource Directory [draft-ietf-core-resource-directory-25] (83 pages) - Sensor Measurement Lists (SenML) [draft-ietf-core-senml-16] (54 pages) - SenML Data Value Content-Format Indication [draft-ietf-core-senml-data-ct-02] (7 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) - SenML Features and Versions [draft-ietf-core-senml-versions-00] (5 pages) - YANG Schema Item iDentifier (YANG SID) [draft-ietf-core-sid-14] (37 pages) - Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) [draft-ietf-core-stateless-06] (16 pages) - "Too Many Requests" Response Code for the Constrained Application Protocol [draft-ietf-core-too-many-reqs-06] (6 pages) - CBOR Encoding of Data Modeled with YANG [draft-ietf-core-yang-cbor-13] (46 pages) - Constrained YANG Module Library [draft-ietf-core-yang-library-02] (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) - 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 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) RFC8428: Sensor Measurement Lists (SenML) (54 pages) 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) CBOR Object Signing and Encryption (cose) ----------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Ivaylo Petrov Matthew A. Miller Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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) as well as outside of the IETF (i.e. W3C and FIDO). There are a number of implementations, both open source and private, now in existence. The specification is now sufficiently mature that it makes sense to try and advance it to STD status. The standards progression work will focus on: 1. Should the document be split in two? The first document would contain the definitions of the structures and rules for processing them. The second document would contain the set of original algorithms that were defined. 2. What areas in the document need clarification before the document can be progressed? 3. What implementations exist and do they cover all of the major sections of the document? 4. Resolution of any Errata or ambiguities in the document There are a small number of COSE related documents that will also be addressed by the working group dealing with additional attributes and algorithms that need to be reviewed and published. The first set are listed below in the deliverables. A re-charter will be required to expand this list. The SUIT working group has identified a need for the use of hash-based signatures in the form of Leighton-Micali Signatures (LMS) (draft-mcgrew-hash-sigs). This signature form is resistant to quantum computer attacks and is low-cost for validation. The SUIT working group additionally has identified a need for registering hash functions for indirect packaging. The W3C Web Authentication working group has identified a need for the ability to use algorithms which are currently part of TPMs which are widely deployed. At the time COSE was developed, there was a sense that X.509 certificates were not a feature that needed to be transferred from the JOSE key document (RFC 7517). Since that time a better sense of how X.509 certificates would be used both in the IoT sphere and with COSE outside of the IoT sphere has been developed. The ability to identify or carry X.509 certificates now needs to be provided. This will require the definition of a small number of hash functions for compact references to X.509 certificates. 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 we are 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 will have five deliverables: 1. Republishing a version of RFC 8152 suitable for advancement to Internet Standard. 2. Use of Hash-based Signature algorithms in COSE using draft-housley-suit-cose-hash-sig as a starting point (Informational). 3. Placement of X.509 certificates in COSE messages and keys using draft-schaad-cose-x509 as a starting point (Informational). 4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point (Informational). 5. Define a small number of hash functions for X.509 certificate thumbprints and for indirect signing (for SUIT) (Informational). Goals and Milestones: Internet-Drafts: - CBOR Object Signing and Encryption (COSE): Countersignatures [draft-ietf-cose-countersign-01] (20 pages) - CBOR Object Signing and Encryption (COSE): Hash Algorithms [draft-ietf-cose-hash-algs-09] (12 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) - CBOR Object Signing and Encryption (COSE) [draft-ietf-cose-msg-24] (121 pages) - CBOR Object Signing and Encryption (COSE): Initial Algorithms [draft-ietf-cose-rfc8152bis-algs-12] (54 pages) - CBOR Object Signing and Encryption (COSE): Structures and Process [draft-ietf-cose-rfc8152bis-struct-14] (82 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-07] (10 pages) - CBOR Encoded Message Syntax [draft-schaad-cose-msg-01] (48 pages) Requests for Comments: RFC8152: CBOR Object Signing and Encryption (COSE) (121 pages) 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) CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Daniel Migault Rich Salz Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: curdle@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/curdle Archive: https://mailarchive.ietf.org/arch/browse/curdle/ Description of Working Group: CURDLE - CURves, Deprecating and a Little more Encryption The CURDLE working group is chartered to add a small set of cryptographic mechanisms to some IETF protocols, and to make implementation requirements including deprecation of old algorithms where there is IETF consensus to do so. The focus with regards to adding mechanisms is for those mechanisms that enjoy broad support from implementers. The set of cryptographic mechanisms that can be introduced are limited to key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and Curve448 as defined by CFRG [1] [2], and the AEAD mode ciphers consisting of ChaCha20 and Poly1305 also defined by CFRG [3]. Other variants of mechanisms, such as the ChaCha20-Poly1305 construct deployed for SSH, may also be considered as well as AES-CCM[4] and AES-GCM [5] where those are not already defined and where there is implementer interest. Related specifications such as private and public key formats are also within scope. The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures and potentially XML Encryption, Kerberos and JSON. Where initial drafts for this work have been produced those will be immediately considered for adoption as working group documents. These include, for SSH, Curve25519/Curve448 digital signatures [6] and key exchange [7]; for DNSSEC, Ed25519 [8] and Curve448 [9]; for PKIX, Curve25519/448 NamedCurve [10] and EdDSA signatures [11]; for JSON curves and signatures [12]. The CURDLE working group will be handling changes to protocols and registries some of which include what are now considered outdated algorithm options, and may propose deprecation of such algorithms. Such deprecation needs to be done with care, ensuring that interoperability and the needs of existing implementers and deployments are properly considered. Where deprecation is practical, the working group is encouraged to deprecate. Where there is an IETF working group or area group with expertise in a relevant topic the CURDLE working group will defer to the consensus of the more specific working group as to where work will be done. For example, the TLS, OpenPGP and IPSECME WGs are actively considering some of these topics. The CURDLE working group will liaise with W3C to ensure that XML digital signature and XML encryption work does not conflict with W3C. The CURDLE working group is expected to be a short-lived working group that may not need to ever meet face-to-face. Once the work on the initially adopted set of drafts has completed the working group will close or re-charter. The CURDLE working group is not chartered to consider allocating new codepoints for any algorithms or modes other than those mentioned above. Should someone wish to propose such work, a re-charter will be required. At this time, there is no expectation that such a re-charter will be requested. [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves [2] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 [3] RFC 7539 [4] RFC 3610 [5] RFC5288 [6] https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 [7] https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 [8] https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 [9] https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 [10] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 [11] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 [12] http://www.ietf.org/mail-archive/web/jose/current/msg05357.html Goals and Milestones: Jan 2016 - Decision on which drafts to adopt Jun 2016 - Send last draft to IESG Internet-Drafts: - Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-chacha20-poly1305-06] (9 pages) - Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-ecdh-new-curves-10] (18 pages) - Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) [draft-ietf-curdle-cms-eddsa-signatures-08] (9 pages) - Deprecate Triple-DES (3DES) and RC4 in Kerberos [draft-ietf-curdle-des-des-des-die-die-die-05] (10 pages) - Ed25519 for DNSSEC [draft-ietf-curdle-dnskey-ed25519-01] (7 pages) - Ed448 for DNSSEC [draft-ietf-curdle-dnskey-ed448-00] (7 pages) - Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC [draft-ietf-curdle-dnskey-eddsa-03] (7 pages) - Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 [draft-ietf-curdle-gss-keyex-sha2-10] (12 pages) - Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure [draft-ietf-curdle-pkix-10] (20 pages) - Using EdDSA with Ed25519/Ed448 in the Internet X.509 Public Key Infrastructure [draft-ietf-curdle-pkix-eddsa-00] (10 pages) - Using Curve25519 and Curve448 in PKIX [draft-ietf-curdle-pkix-newcurves-00] (4 pages) - Deprecating RC4 in Secure Shell (SSH) [draft-ietf-curdle-rc4-die-die-die-18] (5 pages) - Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol [draft-ietf-curdle-rsa-sha2-12] (9 pages) - Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 [draft-ietf-curdle-ssh-curves-12] (6 pages) - Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits [draft-ietf-curdle-ssh-dh-group-exchange-06] (5 pages) - Ed25519 public key algorithm for the Secure Shell (SSH) protocol [draft-ietf-curdle-ssh-ed25519-02] (5 pages) - Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol [draft-ietf-curdle-ssh-ed25519-ed448-11] (7 pages) - Extension Negotiation in the Secure Shell (SSH) Protocol [draft-ietf-curdle-ssh-ext-info-15] (14 pages) - Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) [draft-ietf-curdle-ssh-kex-sha2-11] (18 pages) - More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) [draft-ietf-curdle-ssh-modp-dh-sha2-09] (8 pages) - IANA Registration for the Cryptographic Algorithm Object Identifier Range [draft-schaad-curdle-oid-registry-03] (5 pages) Requests for Comments: BCP218: Deprecate Triple-DES (3DES) and RC4 in Kerberos (10 pages) BCP227: Deprecating RC4 in Secure Shell (SSH) (5 pages) RFC8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC (7 pages) RFC8103: Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) (9 pages) RFC8268: More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) (8 pages) RFC8270: Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits (5 pages) RFC8308: Extension Negotiation in the Secure Shell (SSH) Protocol (14 pages) RFC8332: Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol (9 pages) RFC8410: Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure (20 pages) RFC8411: IANA Registration for the Cryptographic Algorithm Object Identifier Range (5 pages) RFC8418: Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) (18 pages) RFC8419: Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) (9 pages) RFC8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos (10 pages) RFC8709: Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol (7 pages) RFC8731: Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 (6 pages) RFC8732: Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 (12 pages) RFC8758: Deprecating RC4 in Secure Shell (SSH) (5 pages) Deterministic Networking (detnet) --------------------------------- Charter Last Modified: 2018-07-14 Current Status: Active Chairs: János Farkas Lou Berger Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Tech Advisor: David Black Secretary: Ethan Grossman Mailing Lists: General Discussion: detnet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/detnet Archive: https://mailarchive.ietf.org/arch/browse/detnet/ Description of Working Group: The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. The Working Group addresses Layer 3 aspects in support of applications requiring deterministic networking. The Working Group collaborates with IEEE802.1 Time-Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being considered by the IEEE 802.1 TSN Task Group. The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also can include private WANs. The DetNet WG will not spend energy on solutions for large groups of domains such as the Internet. The Working Group is responsible for the overall DetNet architecture and DetNet-specific specifications that encompasses the data plane, OAM (Operations, Administration, and Maintenance), time synchronization, management, control, and security aspects which are required to enable a multi-hop path, and forwarding along the path, with the deterministic properties of controlled latency, low packet loss, low packet delay variation, and high reliability. The work applies to point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required. The work covers the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes. Layer 3 data plane technologies that can be used include: IP and MPLS, and Layer 2 encapsulations that run over IP and/or MPLS, such as pseudowires and GRE. The Working Group will document which deployment environments and types of topologies are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane aspects and is independent from any path setup protocol or mechanism. The Working Group will also document DetNet Controller Plane approaches that reuse existing IETF solutions, such as Path Computation Element (PCE), and identify the Working Group responsible for any extensions needed to support DetNet. Documents produced by the Working Group will be compatible with the work done in IEEE802.1 TSN and other IETF Working Groups. The Working Group's scope explicitly excludes modifications of transport protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss requirements for such modifications and the work will be done in the Working Group responsible for the technology. DetNet is chartered to work in the following areas: Overall architecture: This work encompasses the data plane, OAM, time synchronization, management, control, and security aspects. Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet forwarding over Layer 3. Other IETF defined data plane technologies may also be used. Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as "the aggregation of the Control and Management Planes". This work will document how to use IETF control plane solutions to support DetNet, including the identification of any gaps in existing solutions. Any modification to Controller Plane protocols to address identified gaps should be carried out in their associated Working Groups, but may be done in DetNet if agreed to by the relevant Working Group chairs and responsible Area Directors. Data flow information model: This work will identify the information needed for flow establishment and control and be used by reservation protocols and YANG data models. The work will be independent from the protocol(s) used to control the flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). YANG models: This work will document device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) for use in device configuration and status reporting. Such information may also be used when advertising the deterministic network elements to a control plane. Control plane related information will be independent from the protocol(s) which may be used to advertise this information (e.g. IS-IS or GMPLS extensions). Any new YANG models will be coordinated with the Working Groups that define any base models that are to be augmented. As needed, vertical requirements: This effort will detail the requirements for deterministic networks in various industries that have previously not been documented and cannot be supported using defined DetNet solutions. To investigate whether existing data plane encryption mechanisms can be applied, possibly opportunistically, to improve security and privacy. The Working Group coordinates with other relevant IETF Working Groups, including CCAMP, IPPM, LSR, PCE, PALS, TEAS, TSVWG, RAW, and 6TiSCH. As the work progresses, requirements may be provided to the responsible Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to maintain the consistency of the overall architecture and related solutions. The WG will liaise with appropriate groups in IEEE and other Standards Development Organizations (SDOs). Goals and Milestones: Jun 2020 - Adopt controller plane framework Aug 2020 - Submit YANG model (Standards Track) Aug 2020 - Submit TSN data plane documents (Standards track) Aug 2020 - Adopt DetNet IP OAM document Mar 2021 - Submit first OAM document for publication May 2021 - Submit controller plane framework Jun 2021 - Submit DetNet IP OAM document Done - Finalize use cases (informational) Done - Submit architecture (Standards Track) Done - WG adoption of YANG model Done - Finalize problem statement (informational) Done - Submit data plane specification (Standards Track) Done - Initial OAM WG document Done - Submit security considerations document for publications Done - Submit data flow information model (informational) 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) - DetNet Bounded Latency [draft-ietf-detnet-bounded-latency-01] (28 pages) - DetNet Data Plane Framework [draft-ietf-detnet-data-plane-framework-06] (26 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) - DetNet Flow Information Model [draft-ietf-detnet-flow-information-model-11] (21 pages) - DetNet Data Plane: IP [draft-ietf-detnet-ip-07] (25 pages) - Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane [draft-ietf-detnet-ip-oam-00] (8 pages) - DetNet Data Plane: IP over MPLS [draft-ietf-detnet-ip-over-mpls-09] (13 pages) - DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) [draft-ietf-detnet-ip-over-tsn-03] (12 pages) - DetNet Data Plane: MPLS [draft-ietf-detnet-mpls-13] (32 pages) - Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane [draft-ietf-detnet-mpls-oam-01] (13 pages) - DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN) [draft-ietf-detnet-mpls-over-tsn-03] (13 pages) - DetNet Data Plane: MPLS over UDP/IP [draft-ietf-detnet-mpls-over-udp-ip-07] (9 pages) - Deterministic Networking Problem Statement [draft-ietf-detnet-problem-statement-09] (11 pages) - Deterministic Networking (DetNet) Security Considerations [draft-ietf-detnet-security-12] (47 pages) - Deterministic Networking (DetNet) Topology YANG Model [draft-ietf-detnet-topology-yang-00] (18 pages) - DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS [draft-ietf-detnet-tsn-vpn-over-mpls-03] (15 pages) - Deterministic Networking Use Cases [draft-ietf-detnet-use-cases-20] (97 pages) - Deterministic Networking (DetNet) Configuration YANG Model [draft-ietf-detnet-yang-08] (42 pages) - Deterministic Networking (DetNet) Security Considerations [draft-sdt-detnet-security-01] (35 pages) Requests for Comments: RFC8557: Deterministic Networking Problem Statement (11 pages) RFC8578: Deterministic Networking Use Cases (97 pages) RFC8655: Deterministic Networking Architecture (38 pages) Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2020-06-09 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: Nov 2020 - WGLC draft-ietf-dhc-dhcpv6-yang Apr 2021 - Advance 3315bis RFC to Internet Standard Apr 2021 - Recharter or close down WG Done - WGLC draft-ietf-dhc-dhcp4o6-saddr-opt Done - WGLC Link-Layer Addresses Assignment Mechanism for DHCPv6 Done - WGLC SLAP quadrant selection options for DHCPv6 Done - Adopt DHCPv6 Prefix Delegating relay Done - Adopt IPv6-Only-Preferred Option for DHCP Done - WGLC Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Done - WGLC IPv6-Only-Preferred Option for DHCP Done - WGLC DHCPv6 Prefix Delegating relay 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) - Forcerenew Reconfiguration Extensions for DHCPv4 [draft-fang-dhc-dhcpv4-forcerenew-extensions-02] (7 pages) - DHCPv6 Prefix Delegating relay [draft-fkhp-dhc-dhcpv6-pd-relay-requirements-03] (11 pages) - DHCPv4 over DHCPv6 Source Address Option [draft-fsc-softwire-dhcp4o6-saddr-opt-07] (9 pages) - DHCP Relay Initiated Release [draft-gandhewar-dhc-relay-initiated-release-01] (11 pages) - DHCPv6 Relay Initiated Release [draft-gandhewar-dhc-v6-relay-initiated-release-01] (14 pages) - A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-gont-dhc-stable-privacy-addresses-01] (8 pages) - Anonymity profile for DHCP clients [draft-huitema-dhc-anonymity-profile-02] (19 pages) - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) [draft-ietf-dhc-3315id-for-v4-05] (12 pages) - IEEE 802.11 parameters DHCP Option [draft-ietf-dhc-80211-option-01] (5 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - Access-Network-Identifier Option in DHCP [draft-ietf-dhc-access-network-identifier-13] (20 pages) - Registering Self-generated IPv6 Addresses in DNS using DHCPv6 [draft-ietf-dhc-addr-registration-07] (10 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-11] (14 pages) - 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) - 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) - 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) - 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) - 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) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 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) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Privacy Considerations for DHCP [draft-ietf-dhc-dhcp-privacy-05] (14 pages) - Softwire Provisioning Using DHCPv4 over DHCPv6 [draft-ietf-dhc-dhcp4o6-saddr-opt-08] (18 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 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) - 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-load-balancing-02] (6 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-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 [draft-ietf-dhc-dhcpv6-pd-relay-requirements-02] (12 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) - YANG Data Model for DHCPv6 Configuration [draft-ietf-dhc-dhcpv6-yang-11] (78 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 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) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - Dynamic Allocation of Shared IPv4 Addresses [draft-ietf-dhc-dynamic-shared-v4allocation-09] (15 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 Addresses Assignment Mechanism for DHCPv6 [draft-ietf-dhc-mac-assign-09] (20 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) - 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) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-05] (5 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-05] (12 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 (DHCP) Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-03] (7 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-03] (14 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) - 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) - SLAP quadrant selection option for DHCPv6 [draft-ietf-dhc-slap-quadrant-12] (18 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) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - Provisioning IPv4 Configuration Over IPv6 Only Networks [draft-ietf-dhc-v4configuration-06] (17 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - IPv6-Only Preferred Option for DHCPv4 [draft-ietf-dhc-v6only-08] (12 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 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) - 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) Requests for Comments: BCP180: DHCPv6 Redundancy Deployment Considerations (16 pages) BCP187: Guidelines for Creating New DHCPv6 Options (35 pages) BCP29: Procedure for Defining New DHCP Options (5 pages) BCP43: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) RFC1531: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1541 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Obsoletes RFC1542 RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC2132 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC2131: Dynamic Host Configuration Protocol (45 pages) * Updates RFC3396 * Updates RFC4361 * Updates RFC5494 * Updates RFC6842 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Updates RFC3442 * Updates RFC3942 * Updates RFC4361 * Updates RFC4833 * Updates RFC5494 RFC2241: DHCP Options for Novell Directory Services (5 pages) RFC2242: NetWare/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (4 pages) RFC2489: Procedure for Defining New DHCP Options (5 pages) * Obsoletes RFC2939 RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) * Updates RFC8925 RFC2610: DHCP Options for Service Location Protocol (6 pages) RFC2937: The Name Service Search Option for DHCP (5 pages) RFC2939: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) RFC3004: The User Class Option for DHCP (6 pages) RFC3011: The IPv4 Subnet Selection Option for DHCP (7 pages) RFC3046: DHCP Relay Agent Information Option (14 pages) * Updates RFC6607 RFC3074: DHC Load Balancing Algorithm (10 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) * Updates RFC6704 RFC3256: The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option (5 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (101 pages) * Updates RFC4361 * Updates RFC5494 * Updates RFC6221 * Updates RFC6422 * Updates RFC6644 * Updates RFC7083 * Updates RFC7283 * Updates RFC7227 * Updates RFC7550 * Obsoletes RFC8415 RFC3396: Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) (9 pages) RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (13 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (9 pages) RFC3594: PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option (7 pages) RFC3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 (19 pages) * Updates RFC6603 * Updates RFC7550 * Obsoletes RFC8415 RFC3634: Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option (7 pages) RFC3646: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (7 pages) RFC3679: Unused Dynamic Host Configuration Protocol (DHCP) Option Codes (8 pages) * Updates RFC8910 RFC3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 (9 pages) * Obsoletes RFC8415 RFC3898: Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (7 pages) RFC3925: Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) (9 pages) RFC3942: Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options (7 pages) RFC3993: Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (7 pages) RFC4014: Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (8 pages) RFC4030: The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (15 pages) RFC4039: Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (10 pages) RFC4075: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (5 pages) RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4174: The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service (13 pages) * Updates RFC7146 RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) * Obsoletes RFC8415 RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (7 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (11 pages) RFC4361: Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (12 pages) * Updates RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) * Updates RFC6148 RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (15 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (7 pages) RFC4580: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (6 pages) RFC4649: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (6 pages) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (13 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4833: Timezone Options for DHCP (10 pages) RFC4994: DHCPv6 Relay Agent Echo Request Option (6 pages) RFC5007: DHCPv6 Leasequery (23 pages) RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (7 pages) RFC5071: Dynamic Host Configuration Protocol Options Used by PXELINUX (14 pages) RFC5107: DHCP Server Identifier Override Suboption (7 pages) RFC5192: DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents (8 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) * Updates RFC7653 RFC5970: DHCPv6 Options for Network Boot (11 pages) RFC6148: DHCPv4 Lease Query by Relay Agent Remote ID (13 pages) RFC6221: Lightweight DHCPv6 Relay Agent (17 pages) RFC6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (5 pages) RFC6422: Relay-Supplied DHCP Options (8 pages) RFC6603: Prefix Exclude Option for DHCPv6-based Prefix Delegation (10 pages) RFC6607: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (26 pages) RFC6644: Rebind Capability in DHCPv6 Reconfigure Messages (10 pages) RFC6656: Description of Cisco Systems' Subnet Allocation Option for DHCPv4 (24 pages) RFC6704: Forcerenew Nonce Authentication (12 pages) RFC6842: Client Identifier Option in DHCP Server Replies (5 pages) RFC6853: DHCPv6 Redundancy Deployment Considerations (16 pages) RFC6925: The DHCPv4 Relay Agent Identifier Sub-Option (8 pages) RFC6926: DHCPv4 Bulk Leasequery (41 pages) * Updates RFC7724 RFC6939: Client Link-Layer Address Option in DHCPv6 (7 pages) RFC6977: Triggering DHCPv6 Reconfiguration from Relay Agents (13 pages) RFC7031: DHCPv6 Failover Requirements (17 pages) RFC7037: RADIUS Option for the DHCPv6 Relay Agent (10 pages) RFC7083: Modification to Default Values of SOL_MAX_RT and INF_MAX_RT (7 pages) * Obsoletes RFC8415 RFC7227: Guidelines for Creating New DHCPv6 Options (35 pages) RFC7283: Handling Unknown DHCPv6 Messages (7 pages) * Obsoletes RFC8415 RFC7341: DHCPv4-over-DHCPv6 (DHCP 4o6) Transport (16 pages) RFC7550: Issues and Recommendations with Multiple Stateful DHCPv6 Options (24 pages) * Obsoletes RFC8415 RFC7618: Dynamic Allocation of Shared IPv4 Addresses (15 pages) RFC7653: DHCPv6 Active Leasequery (30 pages) RFC7724: Active DHCPv4 Lease Query (28 pages) RFC7819: Privacy Considerations for DHCP (14 pages) RFC7824: Privacy Considerations for DHCPv6 (18 pages) RFC7839: Access-Network-Identifier Option in DHCP (20 pages) RFC7844: Anonymity Profiles for DHCP Clients (26 pages) RFC7969: Customizing DHCP Configuration on the Basis of Network Topology (20 pages) RFC8156: DHCPv6 Failover Protocol (96 pages) RFC8168: DHCPv6 Prefix-Length Hint Issues (9 pages) RFC8213: Security of Messages Exchanged between Servers and Relay Agents (8 pages) RFC8357: Generalized UDP Source Port for DHCP Relay (10 pages) RFC8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (154 pages) RFC8539: Softwire Provisioning Using DHCPv4 over DHCPv6 (18 pages) RFC8925: IPv6-Only Preferred Option for DHCPv4 (12 pages) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Jouni Korhonen Lionel Morand Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: https://mailarchive.ietf.org/arch/browse/dime/ Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. - Diameter overload control. The aim of this work is to identify the limitations of the Diameter protocol level overload control provided by the current Diameter Base protocol. A set of requirements will be provided to define a new Diameter level overload control mechanism. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard Jan 2016 - Submit I-D 'Diameter Overload Control Rate Abatement Algorithm' to the IESG for consideration as a Proposed Standard Oct 2016 - Submit RFC4006bis as a working group document. Aug 2017 - Submit RFC4006bis to the IESG. Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Done - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item Done - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Done - Submit I-D 'Diameter Overload Control Requirements' as a working group document. To be Informational RFC Done - Submit I-D 'Diameter Overload Control' as a working group document. To be Standards Track RFC Done - Submit I-D 'Diameter Overload Control Requirements' to the IESG for consideration as a Informational Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Done - Submit I-D 'Diameter Overload Control' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Congestion and Filter Attributes' to the IESG for considerations as a Proposed Standard Done - Submit a document on 'Diameter Agent Overload' as a working group item Done - Submit a document on 'Diameter Overload Control Rate Abatement Algorithm' as a working group item Done - Submit a document on 'Diameter Load Information' as a working group item Done - Submit I-D 'Diameter Agent Overload' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Load Information' to the IESG for consideration as a Proposed Standard Done - Submit I-D 'Diameter Routing Message Priority' to the IESG for considerations as a Proposed Standard Done - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Internet-Drafts: - Diameter Credit-Control Application [draft-bertz-dime-rfc4006bis-01] (113 pages) - Diameter Overload Indication Conveyance [draft-docdt-dime-ovli-01] (41 pages) - Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions [draft-ietf-dime-4over6-provisioning-06] (23 pages) - Diameter Agent Overload and the Peer Overload Report [draft-ietf-dime-agent-overload-11] (19 pages) - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-28] (29 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-07] (6 pages) - Diameter Congestion and Filter Attributes [draft-ietf-dime-congestion-flow-attributes-02] (9 pages) - The Diameter API [draft-ietf-dime-diameter-api-08] (46 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-06] (51 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-01] (5 pages) - Diameter Quality-of-Service Application [draft-ietf-dime-diameter-qos-15] (51 pages) - Diameter Overload Rate Control [draft-ietf-dime-doic-rate-control-11] (20 pages) - Diameter Routing Message Priority [draft-ietf-dime-drmp-07] (18 pages) - Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements [draft-ietf-dime-e2e-sec-req-05] (11 pages) - Diameter Support for the EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-17] (18 pages) - Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage [draft-ietf-dime-extended-naptr-09] (14 pages) - Diameter Group Signaling [draft-ietf-dime-group-signaling-13] (26 pages) - Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers [draft-ietf-dime-ikev2-psk-diameter-11] (17 pages) - Diameter Load Information Conveyance [draft-ietf-dime-load-09] (23 pages) - Diameter Attribute-Value Pairs for Cryptographic Key Transport [draft-ietf-dime-local-keytran-14] (7 pages) - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-12] (17 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-17] (34 pages) - Clarifications on the Routing of Diameter Requests Based on the Username and the Realm [draft-ietf-dime-nai-routing-04] (11 pages) - Diameter Network Address and Port Translation Control Application [draft-ietf-dime-nat-control-17] (58 pages) - Diameter Overload Control Requirements [draft-ietf-dime-overload-reqs-13] (29 pages) - Diameter Overload Indication Conveyance [draft-ietf-dime-ovli-10] (42 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-04] (20 pages) - Diameter Support for Proxy Mobile IPv6 Localized Routing [draft-ietf-dime-pmip6-lr-18] (11 pages) - Diameter Priority Attribute-Value Pairs [draft-ietf-dime-priority-avps-06] (10 pages) - Traffic Classification and Quality of Service (QoS) Attributes for Diameter [draft-ietf-dime-qos-attributes-15] (43 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-11] (12 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-13] (10 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-34] (152 pages) - Diameter Network Access Server Application [draft-ietf-dime-rfc4005bis-14] (70 pages) - Diameter Credit-Control Application [draft-ietf-dime-rfc4006bis-12] (130 pages) - Diameter AVP Level Security: Scenarios and Requirements [draft-tschofenig-dime-e2e-sec-req-01] (8 pages) - Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions [draft-zhou-dime-4over6-provisioning-05] (19 pages) Requests for Comments: BCP193: Diameter Applications Design Guidelines (29 pages) RFC5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (17 pages) RFC5624: Quality of Service Parameters for Usage with Diameter (12 pages) RFC5719: Updated IANA Considerations for Diameter Command Code Allocations (5 pages) * Obsoletes RFC6733 RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (11 pages) RFC5777: Traffic Classification and Quality of Service (QoS) Attributes for Diameter (43 pages) RFC5778: Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (34 pages) RFC5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (20 pages) RFC5866: Diameter Quality-of-Service Application (51 pages) RFC6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage (14 pages) RFC6733: Diameter Base Protocol (152 pages) * Updates RFC7075 * Updates RFC8553 RFC6734: Diameter Attribute-Value Pairs for Cryptographic Key Transport (7 pages) RFC6735: Diameter Priority Attribute-Value Pairs (10 pages) RFC6736: Diameter Network Address and Port Translation Control Application (58 pages) RFC6737: The Diameter Capabilities Update Application (6 pages) RFC6738: Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers (17 pages) RFC6942: Diameter Support for the EAP Re-authentication Protocol (ERP) (18 pages) RFC7068: Diameter Overload Control Requirements (29 pages) RFC7075: Realm-Based Redirection In Diameter (10 pages) RFC7155: Diameter Network Access Server Application (70 pages) RFC7156: Diameter Support for Proxy Mobile IPv6 Localized Routing (11 pages) RFC7423: Diameter Applications Design Guidelines (29 pages) RFC7660: Diameter Congestion and Filter Attributes (9 pages) RFC7678: Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions (23 pages) RFC7683: Diameter Overload Indication Conveyance (42 pages) * Updates RFC8581 RFC7944: Diameter Routing Message Priority (18 pages) RFC7966: Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements (11 pages) RFC8506: Diameter Credit-Control Application (130 pages) RFC8581: Diameter Agent Overload and the Peer Overload Report (19 pages) RFC8582: Diameter Overload Rate Control (20 pages) RFC8583: Diameter Load Information Conveyance (23 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Ben Campbell Patrick McManus Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Apr 2018 - EMCAscript Media Type Updates to IESG for publication as Informational Internet-Drafts: - ECMAScript Media Types Updates [draft-ietf-dispatch-javascript-mjs-07] (27 pages) No Requests for Comments Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Alexey Melnikov Seth Blank Tim Wicinski Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba 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) - 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) - Email Authentication for Internationalized Mail [draft-ietf-dmarc-eaiauth-06] (6 pages) - Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows [draft-ietf-dmarc-interoperability-18] (27 pages) - DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) [draft-ietf-dmarc-psd-09] (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) Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Dapeng Liu Satoru Matsushima Sri Gundavelli Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: dmm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmm Archive: https://mailarchive.ietf.org/arch/browse/dmm/ Description of Working Group: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic between mobile and correspondent nodes can take an optimal route. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flattening network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. For example, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. When extending protocols that are not based on Mobile IP, DMM solutions will have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. The working group will produce one or more documents on the following work item topics. o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network-side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit into the overall DMM charter scope as outlined above. Goals and Milestones: Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. Nov 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. Mar 2016 - 'RFC4283bis on MN-IDs as a working group document' submitted to the IESG. Nov 2016 - RFC5149bis on Service Selection as a working group document Mar 2017 - RFC5149bis submitted to IESG. Done - Submit 'Enhanced mobility anchoring' as a working group document. Done - Submit 'Forwarding path and signaling management' 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-03] (39 pages) - Distributed Mobility Management: Current Practices and Gap Analysis [draft-ietf-dmm-best-practices-gap-analysis-09] (34 pages) - DMM Deployment Models and Architectural Considerations [draft-ietf-dmm-deployment-models-04] (15 pages) - Distributed Mobility Anchoring [draft-ietf-dmm-distributed-mobility-anchoring-15] (18 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-ietf-dmm-fpc-cpdp-14] (34 pages) - YANG for Protocol for Forwarding Policy Configuration (FPC) [draft-ietf-dmm-fpc-yang-00] (82 pages) - Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) [draft-ietf-dmm-hnprenum-07] (10 pages) - Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor [draft-ietf-dmm-lma-controlled-mag-params-05] (14 pages) - Mobile Access Gateway (MAG) Multipath Options [draft-ietf-dmm-mag-multihoming-07] (15 pages) - On-Demand Mobility Management [draft-ietf-dmm-ondemand-mobility-18] (12 pages) - Proxy Mobile IPv6 Extensions for Distributed Mobility Management [draft-ietf-dmm-pmipv6-dlif-06] (25 pages) - Requirements for Distributed Mobility Management [draft-ietf-dmm-requirements-17] (24 pages) - Segment Routing IPv6 for Mobile User Plane [draft-ietf-dmm-srv6-mobile-uplane-09] (30 pages) - MN Identifier Types for RFC 4283 Mobile Node Identifier Option [draft-perkins-dmm-4283mnids-01] (7 pages) - Privacy considerations for DMM [draft-perkins-dmm-privacy-00] (6 pages) - MAG Multipath Binding Option [draft-seite-dmm-rg-multihoming-02] (13 pages) - DMM Deployment Models and Architectural Considerations [draft-wt-dmm-deployment-models-00] (15 pages) - Protocol for Forwarding Policy Configuration (FPC) in DMM [draft-wt-dmm-fpc-cpdp-00] (26 pages) - Home Network Prefix Renumbering in PMIPv6 [draft-yan-dmm-hnprenum-03] (8 pages) - On Demand Mobility Management [draft-yegin-dmm-ondemand-mobility-03] (10 pages) Requests for Comments: RFC7333: Requirements for Distributed Mobility Management (24 pages) RFC7429: Distributed Mobility Management: Current Practices and Gap Analysis (34 pages) RFC8127: Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor (14 pages) RFC8191: Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) (10 pages) RFC8278: Mobile Access Gateway (MAG) Multipath Options (15 pages) RFC8371: Mobile Node Identifier Types for MIPv6 (16 pages) RFC8653: On-Demand Mobility Management (12 pages) RFC8818: Distributed Mobility Anchoring (18 pages) RFC8885: Proxy Mobile IPv6 Extensions for Distributed Mobility Management (25 pages) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2020-04-20 Current Status: Active Chairs: Benno Overeinder Suzanne Woolf Tim Wicinski Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: https://mailarchive.ietf.org/arch/browse/dnsop/ Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software and services and for the administration of DNS zones. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Describe practices by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, TLD name servers, or any other resolver or server functioning as part of the global DNS. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software and services, including root, TLD, and recursive servers. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning DNS operational procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation and guidance on DNS-related IPv6 transition and coexistence issues. 4. Publish documents to address operational issues with the DNS protocols by extending or performing protocol maintenance on them. Act as focal-point for operator discussion and provide advice to the Ops ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a home for drafts that document the problem space around existing or new DNS issues. The group, with the advice and consent of the responsible AD in coordination with other areas, will then decide whether these issues belong in DNSOP under the existing charter and, if not, will work with the authors and appropriate ADs to determine the proper place for the work to be carried out. 6. Publish documents that attempt to better define the overlapping area among the public DNS root, DNS-like names as used in local or restricted naming scopes, and the 'special names' registry that IETF manages, perhaps including how they might interact. This work must take into consideration issues that are strictly beyond the operation of the DNS itself, and the working group will consult with IETF liaisons to other organizations as appropriate. Goals and Milestones: Done - IESG Appoval for dnssec-key-timing Internet-Drafts: - A Common Operational Problem in DNS Servers - Failure To Respond. [draft-andrews-dns-no-response-issue-16] (16 pages) - Glue In DNS Referral Responses Is Not Optional [draft-andrews-dnsop-glue-is-not-optional-01] (5 pages) - The .onion Special-Use Domain Name [draft-appelbaum-dnsop-onion-tld-01] (6 pages) - Top-level Domains for Private Internets [draft-arends-private-use-tld-02] (12 pages) - DNS Multiple QTYPEs [draft-bellis-dnsext-multi-qtypes-06] (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) - DNS query name minimisation to improve privacy [draft-bortzmeyer-dns-qname-minimisation-02] (6 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-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) - Domain Name System (DNS) Cookies [draft-eastlake-dnsext-cookies-05] (27 pages) - Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE [draft-fanf-dnsop-rfc2317bis-01] (22 pages) - Fragmentation Avoidance in DNS [draft-fujiwara-dnsop-avoid-fragmentation-03] (10 pages) - Aggressive use of NSEC/NSEC3 [draft-fujiwara-dnsop-nsec-aggressiveuse-03] (14 pages) - Updating Resolver Algorithm [draft-fujiwara-dnsop-resolver-update-00] (9 pages) - Security Considerations for RFC5011 Publishers [draft-hardaker-rfc5011-security-considerations-04] (9 pages) - Terminology for DNS Transports and Location [draft-hoffman-dns-terminology-ter-02] (3 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-howard-dnsop-ip6rdns-00] (14 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) - 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) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsind-rollover-00] (11 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-12] (11 pages) - Address-specific DNS aliases (ANAME) [draft-ietf-dnsop-aname-04] (17 pages) - AS112 Redirection Using DNAME [draft-ietf-dnsop-as112-dname-06] (16 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-09] (18 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-06] (8 pages) - Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves [draft-ietf-dnsop-attrleaf-16] (15 pages) - DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names [draft-ietf-dnsop-attrleaf-fix-07] (15 pages) - Fragmentation Avoidance in DNS [draft-ietf-dnsop-avoid-fragmentation-02] (10 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-06] (18 pages) - Child-to-Parent Synchronization in DNS [draft-ietf-dnsop-child-syncronization-07] (15 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-01] (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-00] (11 pages) - DNS Response Policy Zones (RPZ) [draft-ietf-dnsop-dns-rpz-00] (30 pages) - DNS Transport over TCP - Operational Requirements [draft-ietf-dnsop-dns-tcp-requirements-06] (27 pages) - DNS Terminology [draft-ietf-dnsop-dns-terminology-05] (27 pages) - An Proxy Use Case of DNS over HTTPS [draft-ietf-dnsop-dns-wireformat-http-03] (6 pages) - Message Digest for DNS Zones [draft-ietf-dnsop-dns-zone-digest-14] (39 pages) - A Framework for DNSSEC Policies and DNSSEC Practice Statements [draft-ietf-dnsop-dnssec-dps-framework-11] (27 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) - DNSSEC Trust Anchor Configuration and Maintenance [draft-ietf-dnsop-dnssec-trust-anchor-04] (14 pages) - DNSSEC Trust Anchor History Service [draft-ietf-dnsop-dnssec-trust-history-02] (11 pages) - Recommendations for DNSSEC Resolvers Operators [draft-ietf-dnsop-dnssec-validator-requirements-00] (23 pages) - DNSSEC Implementation in the CAIRN Testbed [draft-ietf-dnsop-dnsseccairn-00] (22 pages) - IP Addresses that should never appear in the public DNS [draft-ietf-dnsop-dontpublish-unreachable-03] (0 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) - Glue In DNS Referral Responses Is Not Optional [draft-ietf-dnsop-glue-is-not-optional-00] (5 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-01] (13 pages) - Encouraging the use of DNS IN-ADDR Mapping [draft-ietf-dnsop-inaddr-required-07] (7 pages) - An Interim Scheme for Signing the Public DNS Root [draft-ietf-dnsop-interim-signed-root-01] (0 pages) - Reverse DNS in IPv6 for Internet Service Providers [draft-ietf-dnsop-ip6rdns-00] (16 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) - Requirements for Automated Key Rollover in DNSsec [draft-ietf-dnsop-key-rollover-requirements-02] (8 pages) - Handling of DNS Zone Signing Keys [draft-ietf-dnsop-keyhand-04] (9 pages) - A Root Key Trust Anchor Sentinel for DNSSEC [draft-ietf-dnsop-kskroll-sentinel-17] (19 pages) - Let 'localhost' be localhost. [draft-ietf-dnsop-let-localhost-be-localhost-02] (10 pages) - Managing DS Records from the Parent via CDS/CDNSKEY [draft-ietf-dnsop-maintain-ds-06] (10 pages) - Common Misbehavior Against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-02] (6 pages) - Multi-Signer DNSSEC Models [draft-ietf-dnsop-multi-provider-dnssec-05] (13 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-05] (17 pages) - Definition and Use of DNSSEC Negative Trust Anchors [draft-ietf-dnsop-negative-trust-anchors-13] (16 pages) - A Common Operational Problem in DNS Servers: Failure to Communicate [draft-ietf-dnsop-no-response-issue-23] (24 pages) - Delegation Revalidation by DNS Resolvers [draft-ietf-dnsop-ns-revalidation-00] (9 pages) - Aggressive Use of DNSSEC-Validated Cache [draft-ietf-dnsop-nsec-aggressiveuse-10] (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) - Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-03] (5 pages) - Testing Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-test-00] (3 pages) - The ".onion" Special-Use Domain Name [draft-ietf-dnsop-onion-tld-01] (7 pages) - Parent's SIG over child's KEY [draft-ietf-dnsop-parent-sig-00] (0 pages) - Top-level Domains for Private Internets [draft-ietf-dnsop-private-use-tld-00] (10 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) - DNS Resolver Information Self-publication [draft-ietf-dnsop-resolver-information-01] (9 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-11] (7 pages) - Rollover of statically configured resolver keys [draft-ietf-dnsop-resolver-rollover-00] (9 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-15] (21 pages) - Considerations for the use of DNS Reverse Mapping [draft-ietf-dnsop-reverse-mapping-considerations-06] (15 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] (29 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-02] (8 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-07] (13 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsop-rollover-01] (11 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) - Serving Stale Data to Improve DNS Resiliency [draft-ietf-dnsop-serve-stale-10] (12 pages) - Interoperable Domain Name System (DNS) Server Cookies [draft-ietf-dnsop-server-cookies-03] (16 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-08] (8 pages) - DNS Stateful Operations [draft-ietf-dnsop-session-signal-20] (64 pages) - Distributing Root Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-shared-root-server-01] (4 pages) - Special-Use Domain Names Problem Statement [draft-ietf-dnsop-sutld-ps-08] (25 pages) - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) [draft-ietf-dnsop-svcb-https-01] (42 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) - IPv4-to-IPv6 migration and DNS name space fragmentation [draft-ietf-dnsop-v6-name-space-fragmentation-01] (0 pages) - Ordering of RRSets in DNS Messages [draft-jabley-dnsop-ordered-answers-00] (12 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) - 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) - Definition and Use of DNSSEC Negative Trust Anchors [draft-livingood-dnsop-negative-trust-anchors-01] (17 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) - DNS message checksums [draft-muks-dnsop-dns-message-checksums-01] (9 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) - DNS Resolver Information Self-publication [draft-sah-resolver-information-02] (9 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) - DNS Catalog Zones [draft-toorop-dnsop-dns-catalog-zones-01] (11 pages) - DNS Response Policy Zones (RPZ) [draft-vixie-dns-rpz-04] (30 pages) - DNS Delegation Requirements [draft-wallstrom-dnsop-dns-delegation-requirements-03] (20 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) - 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) - Returning extra answers in DNS responses. [draft-wkumari-dnsop-multiple-responses-05] (9 pages) - Decreasing Access Time to Root Servers by Running One on Loopback [draft-wkumari-dnsop-root-loopback-02] (9 pages) - BULK DNS Resource Records [draft-woodworth-bulk-rr-09] (16 pages) - Algorithm Implementation Requirements and Usage Guidance for DNSSEC [draft-wouters-sury-dnsop-algorithm-update-02] (9 pages) - A DNS Query including A Main Question with Accompanying Questions [draft-yao-dnsop-accompanying-questions-04] (11 pages) Requests for Comments: BCP123: Observed DNS Resolution Misbehavior (18 pages) BCP140: Preventing Use of Recursive Nameservers in Reflector Attacks (7 pages) BCP163: Locally Served DNS Zones (10 pages) BCP207: DNSSEC Roadblock Avoidance (19 pages) BCP209: Initializing a DNS Resolver with Priming Queries (7 pages) BCP219: DNS Terminology (50 pages) BCP222: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves (15 pages) BCP231: A Common Operational Problem in DNS Servers: Failure to Communicate (24 pages) BCP40: Root Name Server Operational Requirements (10 pages) BCP91: DNS IPv6 Transport Operational Guidelines (5 pages) RFC2870: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC7720 RFC3258: Distributing Authoritative Name Servers via Shared Unicast Addresses (11 pages) RFC3901: DNS IPv6 Transport Operational Guidelines (5 pages) RFC4074: Common Misbehavior Against DNS Queries for IPv6 Addresses (6 pages) RFC4339: IPv6 Host Configuration of DNS Server Information Approaches (26 pages) RFC4472: Operational Considerations and Issues with IPv6 DNS (29 pages) RFC4641: DNSSEC Operational Practices (35 pages) * Obsoletes RFC6781 RFC4697: Observed DNS Resolution Misbehavior (18 pages) RFC4892: Requirements for a Mechanism Identifying a Name Server Instance (8 pages) RFC5358: Preventing Use of Recursive Nameservers in Reflector Attacks (7 pages) RFC6168: Requirements for Management of Name Servers for the DNS (17 pages) RFC6303: Locally Served DNS Zones (10 pages) RFC6304: AS112 Nameserver Operations (18 pages) * Obsoletes RFC7534 RFC6305: I'm Being Attacked by PRISONER.IANA.ORG! (8 pages) RFC6781: DNSSEC Operational Practices, Version 2 (71 pages) RFC6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (27 pages) RFC7344: Automating DNSSEC Delegation Trust Maintenance (18 pages) * Updates RFC8078 RFC7477: Child-to-Parent Synchronization in DNS (15 pages) RFC7534: AS112 Nameserver Operations (24 pages) RFC7535: AS112 Redirection Using DNAME (16 pages) RFC7583: DNSSEC Key Rollover Timing Considerations (31 pages) RFC7646: Definition and Use of DNSSEC Negative Trust Anchors (16 pages) RFC7686: The ".onion" Special-Use Domain Name (7 pages) RFC7706: Decreasing Access Time to Root Servers by Running One on Loopback (12 pages) * Obsoletes RFC8806 RFC7719: DNS Terminology (27 pages) * Obsoletes RFC8499 RFC7766: DNS Transport over TCP - Implementation Requirements (19 pages) * Updates RFC8490 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) 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) RFC7901: CHAIN Query Requests in DNS (16 pages) RFC8020: NXDOMAIN: There Really Is Nothing Underneath (10 pages) RFC8027: DNSSEC Roadblock Avoidance (19 pages) RFC8078: Managing DS Records from the Parent via CDS/CDNSKEY (10 pages) RFC8109: Initializing a DNS Resolver with Priming Queries (7 pages) RFC8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (13 pages) * Updates RFC8553 RFC8198: Aggressive Use of DNSSEC-Validated Cache (13 pages) RFC8244: Special-Use Domain Names Problem Statement (25 pages) RFC8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (10 pages) RFC8490: DNS Stateful Operations (64 pages) RFC8499: DNS Terminology (50 pages) RFC8501: Reverse DNS in IPv6 for Internet Service Providers (15 pages) RFC8509: A Root Key Trust Anchor Sentinel for DNSSEC (19 pages) RFC8552: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves (15 pages) RFC8553: DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names (15 pages) RFC8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture (79 pages) RFC8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC (11 pages) 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) Extensions for Scalable DNS Service Discovery (dnssd) ----------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Barbara Stark 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: Jul 2017 - Adopt DNS-SD Advertising Proxy draft as a WG document Sep 2017 - Submit Privacy Extensions for DNS-SD draft to the IESG as Standards Track RFC Sep 2017 - Submit Device Pairing Using Short Authentication Strings draft to the IESG as Standards Track RFC Dec 2017 - Submit DNS-SD Advertising Proxy draft to the IESG as Standards Track RFC Mar 2018 - Submit DNS-SD Deployment for campus/enterprise networks draft to the IESG as a BCP document 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 wide-area service discovery solution draft as WG document Done - Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services 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 wide-area service discovery solution draft to the IESG as Standards Track RFC Done - Submit DNS Push draft to the IESG as Standards Track RFC Done - Adopt hybrid-proxy implementation draft as WG document Internet-Drafts: - Service Discovery Road Map [draft-cheshire-dnssd-roadmap-03] (20 pages) - DNS-SD Privacy and Security Requirements [draft-huitema-dnssd-prireq-00] (15 pages) - Privacy Extensions for DNS-SD [draft-huitema-dnssd-privacy-02] (20 pages) - DNS-SD Privacy Scaling Tradeoffs [draft-huitema-dnssd-privacyscaling-01] (13 pages) - 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-03] (30 pages) - Device Pairing Using Short Authentication Strings [draft-ietf-dnssd-pairing-05] (11 pages) - Device Pairing Design Issues [draft-ietf-dnssd-pairing-info-02] (17 pages) - DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements [draft-ietf-dnssd-prireq-08] (17 pages) - Privacy Extensions for DNS-SD [draft-ietf-dnssd-privacy-05] (21 pages) - DNS-SD Privacy Scaling Tradeoffs [draft-ietf-dnssd-privacyscaling-00] (13 pages) - DNS Push Notifications [draft-ietf-dnssd-push-25] (32 pages) - Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions [draft-ietf-dnssd-requirements-06] (14 pages) - Service Registration Protocol for DNS-Based Service Discovery [draft-ietf-dnssd-srp-04] (23 pages) - Device Pairing Using Short Authentication Strings [draft-kaiser-dnssd-pairing-00] (20 pages) - Multicast DNS Discovery Relay [draft-sctl-dnssd-mdns-relay-04] (20 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) DDoS Open Threat Signaling (dots) --------------------------------- Charter Last Modified: 2019-03-23 Current Status: Active Chairs: Liang Xia Valery Smyslov Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: dots@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dots Archive: https://mailarchive.ietf.org/arch/browse/dots/ Description of Working Group: The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards based approach for the realtime signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. The elements may be described as: * On-premise DDoS mitigation platforms * Service provider DDoS mitigation platforms * Other network elements and services with the ability to analyze and/or influence network traffic Elements may participate in DDoS detection, classification, traceback and mitigation individually or within the context of a larger collaborative system. These elements may be communicating inter-domain or intra-domain over links that may be congested by attack traffic resulting in potentially hostile conditions for any type of upstream signaling, in particular transport protocols that yield to congestion, and more generalized signaling and telemetry solutions. Robustness under these conditions is paramount while ensuring appropriate regard for authentication, authorization, privacy and data integrity. Elements may be deployed as part of a wider strategy incorporating multiple points of DDoS detection, classification, traceback and mitigation, both on premise or service provider based. Should changing conditions necessitate altering the specifics of mitigation actions and/or the topological scope of mitigation coverage, timely and effective signaling of telemetry and current threat status to all elements involved in the mitigation is essential. Feedback between participating elements is required for increased awareness supporting effective decision making. The WG will, where appropriate, reuse or extend existing standard protocols and mechanisms (for example, IPFIX and its associated templating and extension mechanisms). Any modification of or extension to existing protocols must be in close coordination with the working groups responsible for the protocol being modified, and may be done in this working group after agreement with all the relevant WGs and responsible Area Directors. The WG may coordinate on a situationally appropriate basis with other working groups and initiatives which compliment the DOTS effort e.g. M3AAWG, SACM, MILE, SUPA, I2NSF et. al. The WG will document requirements for the transport protocol to be used for the signaling of DOTS and consult with the Transport Area about the requirements and, if applicable, any new development of an encapsulation scheme for DOTS. The working group may develop an applicability statement (architecture document) explaining how all these elements should communicate together for a complete DDoS service. The charter of the working group is to produce one or more standards track specifications to provide for this open signaling in the DDoS problem space. While the resulting standards should be designed so they apply to network security applications beyond the DDoS problem space, this working group will focus on signaling and coordination mechanisms directly related to DDoS attack detection, classification, traceback and mitigation, incorporating the general principles articulated in RFC5218 . Focusing the WG efforts on DDoS is intended to meet the community's desire for a deployable solution in the near term. The specification(s) produced by the WG will include a standard mechanism for authentication and authorization, data integrity, and providing for privacy in operation, with privacy-friendly choices being the default in all cases. The WG will produce the following deliverables and milestones: * Document or Documents describing the problem space, use cases, protocol requirements and other qualifying information as the WG sees fit. * Document or Documents specifying protocols and associated data models to address the stated goals of the WG. Goals and Milestones: Done - Requirements document to WGLC Done - Use case document to WGLC Done - Signal channel document as proposed standard to WGLC Done - Data channel document as proposed standard to WGLC Done - Architecture document to WGLC Done - DOTS Server Discovery document to WGLC Done - DOTS Signal Channel Call Home document to WGLC Internet-Drafts: - Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) [draft-boucadair-dots-multihoming-04] (14 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification [draft-boucadair-dots-rfc8782-bis-01] (119 pages) - Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery [draft-boucadair-dots-server-discovery-05] (25 pages) - Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry [draft-hayashi-dots-telemetry-use-cases-00] (14 pages) - DDoS Open Threat Signaling (DOTS) Architecture [draft-ietf-dots-architecture-18] (29 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification [draft-ietf-dots-data-channel-31] (66 pages) - Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) [draft-ietf-dots-multihoming-04] (15 pages) - DDoS Open Threat Signaling (DOTS) Requirements [draft-ietf-dots-requirements-22] (22 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification [draft-ietf-dots-rfc8782-bis-01] (120 pages) - Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery [draft-ietf-dots-server-discovery-13] (25 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home [draft-ietf-dots-signal-call-home-10] (41 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification [draft-ietf-dots-signal-channel-41] (100 pages) - Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel [draft-ietf-dots-signal-filter-control-07] (26 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry [draft-ietf-dots-telemetry-13] (107 pages) - Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry [draft-ietf-dots-telemetry-use-cases-00] (14 pages) - Use cases for DDoS Open Threat Signaling [draft-ietf-dots-use-cases-25] (15 pages) - Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry [draft-reddy-dots-telemetry-04] (41 pages) Requests for Comments: RFC8612: DDoS Open Threat Signaling (DOTS) Requirements (22 pages) RFC8782: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification (100 pages) RFC8783: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification (66 pages) RFC8811: DDoS Open Threat Signaling (DOTS) Architecture (29 pages) DNS PRIVate Exchange (dprive) ----------------------------- Charter Last Modified: 2019-03-27 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: Mar 2020 - Submit draft on operating DNS privacy services for publication (BCP) Aug 2020 - Submit draft on DNS privacy exchanges involving authoritative servers (Exp) Mar 2021 - Submit draft on DNS privacy performance metrics and actual measurements (Info) 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) - 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) - Specification for DNS over Transport Layer Security (TLS) [draft-ietf-dprive-dns-over-tls-09] (19 pages) - DNS over Datagram Transport Layer Security (DTLS) [draft-ietf-dprive-dnsodtls-15] (13 pages) - Specification of DNS over Dedicated QUIC Connections [draft-ietf-dprive-dnsoquic-01] (20 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) - 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-01] (10 pages) - DNS Privacy Considerations [draft-ietf-dprive-problem-statement-06] (17 pages) - DNS Privacy Considerations [draft-ietf-dprive-rfc7626-bis-08] (29 pages) - TLS for DNS: Initiation and Performance Considerations [draft-ietf-dprive-start-tls-for-dns-01] (18 pages) - DNS Zone Transfer-over-TLS [draft-ietf-dprive-xfr-over-tls-02] (27 pages) - Padding Profiles for EDNS(0) [draft-mayrhofer-dprive-padding-profile-00] (6 pages) - DNS over DTLS (DNSoD) [draft-wing-dprive-dnsodtls-01] (13 pages) Requests for Comments: BCP232: Recommendations for DNS Privacy Service Operators (34 pages) RFC7626: DNS Privacy Considerations (17 pages) 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) Drone Remote ID Protocol (drip) ------------------------------- Charter Last Modified: 2020-03-12 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: Jul 2020 - Requirements and architecture drafts in the WGLC Sep 2020 - Solution space documents adopted by the WG Mar 2021 - Solution space documents in the WGLC Done - Requirements and architecture drafts adopted by the WG 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-03] (19 pages) - Drone Remote Identification Protocol (DRIP) Requirements [draft-ietf-drip-reqs-05] (34 pages) - UAS Remote ID [draft-ietf-drip-rid-03] (22 pages) - UAS Remote ID [draft-ietf-drip-uas-rid-01] (19 pages) No Requests for Comments Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Marc Blanchet Rick Taylor Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund Secretary: Edward Birrane 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 Network Working Group (DTNWG) specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. Delay-Tolerant Networking (DTN) protocols have been the subject of extensive research and development in the Delay-Tolerant Networking Research Group (DTNRG) of the Internet Research Task Force since 2002.  The key documents are the DTN Architecture  (RFC 4838), the Bundle Protocol (RFC 5050), Licklider Transmission Protocol (RFC 5326) and convergence layers (RFC 7122, 7242). Multiple independent implementations exist for these technologies and multiple deployments in space and terrestrial environments.  There is an increase interest in the commercial world for these technologies, for similar and different use cases, such as unmanned air vehicles.  In this context, there is a need to update the base specifications, i.e., RFC 5050, RFC 7122, RFC 7242, RFC 6257 and RFC 6260,  based on the deployment and implementation experience as well as the new use cases.  Moreover, there is also a need to have standards track documents for the market. Therefore, the purpose of this working group is to update the base specifications in light of implementation experience. The group shall do a review of deployment problems and lessons learned, come to consensus on the issues to be addressed in the base protocol documents, and update the specifications accordingly. The group shall not endeavour to change the underlying architecture or the bundle protocol principle. Work items are: o  Agree to a list of use cases for evolving the DTN specifications and     a list of work items to be worked on. o  Create updates to RFC5050, convergence layer RFCs, and security     (RFC6257), as standard track documents. o  Document a registry for DTN Service Identifiers. Goals and Milestones: Feb 2017 - Neighbor Discovery Feb 2017 - Network Management Requirements Feb 2017 - Key Management Requirements May 2017 - Registry of Service Identifiers May 2017 - Addressing Architecture Jul 2019 - RFC5050bis Jul 2019 - Bundle Security Protocol Jul 2019 - TCP CL update Oct 2019 - Custody Done - Use Cases for evolving the DTN specifications and list of work items to be worked on. Internet-Drafts: - Asynchronous Management Architecture [draft-ietf-dtn-ama-00] (27 pages) - Bundle-in-Bundle Encapsulation [draft-ietf-dtn-bibect-03] (14 pages) - Bundle Protocol Version 7 [draft-ietf-dtn-bpbis-26] (66 pages) - Bundle Protocol Security Specification [draft-ietf-dtn-bpsec-23] (42 pages) - BPSec Interoperability Security Contexts [draft-ietf-dtn-bpsec-interop-sc-01] (10 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-22] (69 pages) No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Allison Mankin Roger Marshall Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba 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: Aug 2017 - Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC Aug 2017 - Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC Done - Informational RFC containing terminology definitions and the requirements 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 - A Standards Track RFC describing how to route an emergency call based on location information Done - An Informational document describing the Mapping Protocol Architecture Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multimedia' 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 '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 'Additional Data related to a Call for Emergency Call Purposes' 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 ‘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 '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) - 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-03] (17 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-08] (17 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) Requests for Comments: BCP181: Best Current Practice for Communications Services in Support of Emergency Calling (28 pages) RFC5012: Requirements for Emergency Context Resolution with Internet Technologies (23 pages) RFC5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (14 pages) * Updates RFC7163 RFC5069: Security Threats and Requirements for Emergency Call Marking and Mapping (12 pages) RFC5222: LoST: A Location-to-Service Translation Protocol (69 pages) * Updates RFC6848 * Updates RFC8917 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) 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) Revision of core Email specifications (emailcore) ------------------------------------------------- Charter Last Modified: 2020-10-14 Current Status: Active Chairs: Alexey Melnikov Seth Blank Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: emailcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emailcore Archive: ​https://mailarchive.ietf.org/arch/browse/emailcore/ Description of Working Group: The base documents defining Internet messaging — colloquially, email -- are RFC 5321 (protocol) and RFC 5322 (format). These are revisions and consolidations of prior documents and were last published in 2008. They currently sit at Draft Standard status, a status that no longer exists according to the current IETF procedure. Since then some errata have accumulated (both submitted to IETF and reported directly to editors), as have comments made about these documents not necessarily describing best email practices. There is now sufficient critical mass to undertake a limited review and revision of these documents for the purpose of advancing them to Internet Standard status. This working group will conduct a limited review and revision to the base email specifications, and will publish new versions of these documents at Internet Standard status, per RFC 6410. The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping these minimal and avoiding broader changes to terminology or document organization. In addition to processing existing, verified errata and errata marked as "held for document update", the WG may address newly-offered errata. However, no new protocol extensions or amendments will be considered for inclusion into 5321bis and 5322bis documents, unless they are already published as IETF Stream RFCs and are at sufficient maturity level to move to Internet Standard. The working group will also work on an Applicability Statement in parallel with 5321bis and 5322bis, to capture relationships to other documented and widely deployed work (recommended extensions, transport security and other issues from the UTA working group's output, and such) and current email practices. 5321bis and 5322bis will be submitted for publication before this document is finalized, and the "bis" documents will have priority for the working group's attention until they are finished. Upon completion of these three milestones, and assuming there is still the momentum to do so, the working group may undertake similar review and revision of other email specifications. Such future work will require rechartering. Goals and Milestones: Internet-Drafts: - Applicability Statement for IETF Core Email Protocols [draft-ietf-emailcore-as-00] (6 pages) - Simple Mail Transfer Protocol [draft-ietf-emailcore-rfc5321bis-00] (108 pages) - Internet Message Format [draft-ietf-emailcore-rfc5322bis-00] (56 pages) No Requests for Comments EAP Method Update (emu) ----------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Joseph A. Salowey Mohit Sethi Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] 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 (v1.3) 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. At the same time, some new use cases for EAP have been identified. EAP is now more broadly used in mobile network authentication. The group will update existing EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. Forward secrecy is an important security property for modern protocols to thwart pervasive monitoring. The group will work on an extension to EAP-AKA' for providing PFS. 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. 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 bug 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. * Develop an extension to EAP-AKA' such that forward secrecy can be provided. There may also be privacy improvements that have become feasible with the introduction of recent identity privacy improvements in 3GPP networks. * 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. 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), and the 3GPP security architecture group (for EAP-AKA' work). Goals and Milestones: Nov 2019 - WG adopts initial draft addressing the errata found in EAP-TEAP Jan 2020 - WG adopts initial draft on creation of long-term credentials for EAP peer based on initial limited-use credentials Mar 2020 - WG last call on extension to EAP-AKA to support forward secrecy Done - WG last call on operational recommendations for large certificate and chain sizes Done - WG last call on definition of session identifiers for fast re- authentication in EAP-SIM and EAP-AKA Done - WG adopts initial draft on an EAP method for mutual authentication based on an OOB channel Done - WG adopts draft providing guidance for use of TLS 1.3 with TLS based 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) - 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) - Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS) [draft-ietf-emu-aka-pfs-04] (26 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) - 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-02] (66 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) - Using EAP-TLS with TLS 1.3 [draft-ietf-emu-eap-tls13-11] (30 pages) - Tunnel Extensible Authentication Protocol (TEAP) Version 1 [draft-ietf-emu-eap-tunnel-method-10] (101 pages) - Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods [draft-ietf-emu-eaptlscert-05] (14 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-07] (50 pages) - TLS-based EAP types and TLS 1.3 [draft-ietf-emu-tls-eap-types-01] (12 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) 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) 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) Email mailstore and eXtensions To Revise or Amend (extra) --------------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Bron Gondwana Jiankang Yao Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Aug 2020 - Adopt a document for EAI with Sieve Aug 2020 - Adopt a sieve-snooze document Aug 2020 - Submit sieve-mailboxid to the IESG as a proposed standard Sep 2020 - Submit "IMAP4rev2" to IESG as a Proposed Standard Dec 2020 - Update charter to reflect current and planned work Dec 2020 - Submit "Quota BIS" to IESG as a Proposed Standard Dec 2020 - 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 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) - 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] (13 pages) - IMAP4 Extension: Message Snippet Generation [draft-ietf-extra-imap-fetch-snippet-00] (10 pages) - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST [draft-ietf-extra-imap-list-myrights-07] (6 pages) - IMAP Extension for Object Identifiers [draft-ietf-extra-imap-objectid-08] (16 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 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) - Internet Message Access Protocol (IMAP) - Version 4rev2 [draft-ietf-extra-imap4rev2-20] (163 pages) - IMAP QUOTA Extension [draft-ietf-extra-quota-02] (17 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-03] (10 pages) - Sieve Email Filtering: Snooze Extension [draft-ietf-extra-sieve-snooze-00] (12 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) General Area Dispatch (gendispatch) ----------------------------------- Charter Last Modified: 2019-10-18 Current Status: Active Chairs: Francesca Palombini Pete Resnick General Area Directors: Alissa Cooper General Area Advisor: Alissa Cooper 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. The working group is chartered to identify, or help create, an appropriate venue for the work. The working group will not consider any technical standardization work. Guiding principles for the 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 amongst published or ongoing work in the GEN area, within the IESG, or within the IETF LLC. 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 the the IESG or the IETF LLC consider taking up the work. - 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. 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 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 GENDISPATCH 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 GEN area is expected to be considered in the GENDISPATCH working group, there may be times where 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. Another major objective of the GENDISPATCH WG is to streamline how the IETF community considers process improvements. Community discussions about process suggestions that begin on other mailing lists, including ietf@ietf.org, will be redirected to the GENDISPATCH mailing list where they will be facilitated by the WG chairs. Proponents of process improvements will be encouraged to craft concrete proposals for discussion on the GENDISPATCH mailing list, with the goal of producing a concrete outcome in bounded time. Direct requests to the IESG may also, after proper consideration, be redirected to the WG. For proposals to be considered by the WG they will be expected to meet guiding principle #1 above. The existence of this working group 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. A review of the efficacy of this working group will be undertaken 18-24 months after its chartering. Goals and Milestones: Internet-Drafts: No Requests for Comments Grant Negotiation and Authorization Protocol (gnap) --------------------------------------------------- Charter Last Modified: 2020-07-24 Current Status: Active Chairs: Leif Johansson Yaron Sheffer Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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: Jul 2021 - Core delegation protocol to Working Group Last Call Oct 2021 - Key presentation mechanism binding for each communication channel to Working Group Last Call Dec 2021 - Guidelines for use of protocol extension points to Working Group Last Call Feb 2022 - Guidelines on migration paths, implementation, and operations to Working Group Last Call Internet-Drafts: - Grant Negotiation and Authorization Protocol [draft-ietf-gnap-core-protocol-00] (119 pages) No Requests for Comments Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2020-03-18 Current Status: Active Chairs: Chris Morrow Job Snijders Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: https://mailarchive.ietf.org/arch/browse/grow/ Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Goals and Milestones: Done - Publish Risk, Interference and Fit (RIFT) document as WG I-D Done - Publish Embedding Globally ...Considered Harmful as WG I-D Done - Publish MED Considerations Draft as WG I-D Done - Publish Collection Communities as WG I-D Done - Submit Collection Communities to IESG for BCP Done - Submit Embedding Globally ...Considered Harmful to IESG for Info Done - Submit MED Considerations to IESG for Info Internet-Drafts: - Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) [draft-evens-grow-bmp-adj-rib-out-01] (10 pages) - Support for Local RIB in BGP Monitoring Protocol (BMP) [draft-evens-grow-bmp-local-rib-00] (12 pages) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-04] (24 pages) - AS Path Prepending [draft-ietf-grow-as-path-prepending-00] (10 pages) - Requirements for the Graceful Shutdown of BGP Sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-07] (20 pages) - Graceful BGP Session Shutdown [draft-ietf-grow-bgp-gshut-13] (12 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-05] (13 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - Default External BGP (EBGP) Route Propagation Behavior without Policies [draft-ietf-grow-bgp-reject-08] (7 pages) - Mitigating the Negative Impact of Maintenance through BGP Session Culling [draft-ietf-grow-bgp-session-culling-05] (10 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-03] (10 pages) - BLACKHOLE Community [draft-ietf-grow-blackholing-03] (9 pages) - BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-17] (27 pages) - Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-adj-rib-out-07] (9 pages) - Support for Local RIB in BGP Monitoring Protocol (BMP) [draft-ietf-grow-bmp-local-rib-07] (15 pages) - BMP Peer Up Message Namespace [draft-ietf-grow-bmp-peer-up-00] (5 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-ietf-grow-bmp-registries-change-01] (3 pages) - TLV support for BMP Route Monitoring and Peer Down Messages [draft-ietf-grow-bmp-tlv-03] (7 pages) - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-08] (12 pages) - Distribution of Diverse BGP Paths [draft-ietf-grow-diverse-bgp-path-dist-08] (22 pages) - Embedding Globally-Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-05] (10 pages) - Impact of BGP Filtering on Inter-Domain Routing Policies [draft-ietf-grow-filtering-threats-08] (16 pages) - Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions [draft-ietf-grow-geomrt-07] (8 pages) - Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration [draft-ietf-grow-irr-routing-policy-considerations-06] (18 pages) - Internet Exchange BGP Route Server Operations [draft-ietf-grow-ix-bgp-route-server-operations-05] (15 pages) - Use of BGP Large Communities [draft-ietf-grow-large-communities-usage-07] (15 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format [draft-ietf-grow-mrt-17] (33 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions [draft-ietf-grow-mrt-add-paths-03] (6 pages) - Time to Remove Filters for Previously Unallocated IPv4 /8s [draft-ietf-grow-no-more-unallocated-slash8s-04] (5 pages) - 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-04] (10 pages) - Problem Definition and Classification of BGP Route Leaks [draft-ietf-grow-route-leak-problem-definition-06] (11 pages) - RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering [draft-ietf-grow-rpki-as-cones-02] (10 pages) - The "import-via" and "export-via" attributes in RPSL Policy Specifications [draft-ietf-grow-rpsl-via-01] (10 pages) - Routing System Stability [draft-ietf-grow-rss-00] (13 pages) - Route-Leaks & MITM Attacks Against BGPSEC [draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04] (8 pages) - Simple Virtual Aggregation (S-VA) [draft-ietf-grow-simple-va-12] (8 pages) - Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services [draft-ietf-grow-unique-origin-as-01] (10 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-06] (24 pages) - Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-05] (6 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-00] (7 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-00] (16 pages) - Policy Behavior for Well-Known BGP Communities [draft-ietf-grow-wkc-behavior-08] (7 pages) - Revision to Registration Procedures for Multiple BMP Registries [draft-scudder-grow-bmp-registries-change-00] (3 pages) - Usage of Large BGP Communities [draft-snijders-grow-large-communities-usage-00] (10 pages) - The "import-via" and "export-via" attributes in RPSL Policy Specifications [draft-snijders-rpsl-via-03] (9 pages) Requests for Comments: BCP105: Embedding Globally-Routable Internet Addresses Considered Harmful (10 pages) BCP114: BGP Communities for Data Collection (12 pages) BCP122: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (27 pages) BCP126: Operation of Anycast Services (24 pages) BCP169: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) BCP171: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) BCP214: Mitigating the Negative Impact of Maintenance through BGP Session Culling (10 pages) RFC4085: Embedding Globally-Routable Internet Addresses Considered Harmful (10 pages) RFC4264: BGP Wedgies (10 pages) RFC4384: BGP Communities for Data Collection (12 pages) RFC4451: BGP MULTI_EXIT_DISC (MED) Considerations (13 pages) RFC4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (27 pages) RFC4786: Operation of Anycast Services (24 pages) RFC6198: Requirements for the Graceful Shutdown of BGP Sessions (20 pages) RFC6382: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) RFC6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format (33 pages) RFC6397: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions (8 pages) RFC6441: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) RFC6752: Issues with Private IP Addressing in the Internet (14 pages) RFC6769: Simple Virtual Aggregation (S-VA) (8 pages) RFC6774: Distribution of Diverse BGP Paths (22 pages) RFC7682: Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration (18 pages) RFC7789: Impact of BGP Filtering on Inter-Domain Routing Policies (16 pages) RFC7854: BGP Monitoring Protocol (BMP) (27 pages) * Updates RFC8671 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) Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chair: Gonzalo Camarillo Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: https://mailarchive.ietf.org/arch/browse/hipsec/ Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The HIP WG will now produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones: Apr 2016 - Submit RFC5770bis to the IESG Jun 2016 - Submit the mobility portion of RFC5206bis to the IESG Jun 2016 - Submit the multihoming portion of RFC5206bis to the IESG Oct 2016 - WGLC RFC4423bis Dec 2016 - Submit RFC4423bis to the IESG Jan 2017 - Recharter or close the WG Done - Submit Native API specification to the IESG Done - Submit Framework for HIP overlays specification to the IESG Done - Submit Multi-hop routing mechanism for HIP Done - Submit Upper-layer data transport in HIP to the IESG Done - WGLC Certs in HIP base exchange specification Done - WGLC the HIP over HIP specification Done - Submit Certs in HIP base exchange to the IESG as Experimental Done - Submit the HIP over HIP specification to the IESG Done - WGLC the specification on how to build HIP-based overlays using RELOAD Done - Submit the specification on how to build HIP-based overlays using RELOAD to the IESG Done - WGLC RFC4843bis Done - WGLC RFC5201bis Done - WGLC RFC5202bis Done - Submit RFC5201bis to the IESG Done - Submit RFC4843bis to the IESG Done - Submit RFC5202bis to the IESG Done - WGLC RFC5203bis Done - WGLC RFC5204bis Done - WGLC RFC5205bis Done - Submit RFC5203bis to the IESG Done - Submit RFC5204bis to the IESG Done - Submit RFC5205bis to the IESG Done - WGLC RFC5770bis Done - WGLC Certs in HIP base exchange specification (referencing RFC5201bis) Done - Submit Certs in HIP base exchange (referencing RFC5201bis) to the IESG as PS Done - WGLC the mobility portion of RFC5206bis Done - WGLC the multihoming portion of RFC5206bis Internet-Drafts: - Using the Host Identity Protocol with Legacy Applications [draft-ietf-hip-applications-04] (14 pages) - Host Identity Protocol (HIP) Architecture [draft-ietf-hip-arch-03] (24 pages) - Host Identity Protocol [draft-ietf-hip-base-10] (104 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) [draft-ietf-hip-bone-07] (21 pages) - Host Identity Protocol Certificates [draft-ietf-hip-cert-12] (12 pages) - HIP Diet EXchange (DEX) [draft-ietf-hip-dex-21] (60 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extensions [draft-ietf-hip-dns-09] (17 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-esp-06] (30 pages) - Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-05] (17 pages) - End-Host Mobility and Multihoming with the Host Identity Protocol [draft-ietf-hip-mm-05] (40 pages) - Host Multihoming with the Host Identity Protocol [draft-ietf-hip-multihoming-12] (22 pages) - Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators [draft-ietf-hip-nat-traversal-09] (34 pages) - Basic Socket Interface Extensions for the Host Identity Protocol (HIP) [draft-ietf-hip-native-api-12] (18 pages) - Native NAT Traversal Mode for the Host Identity Protocol [draft-ietf-hip-native-nat-traversal-33] (67 pages) - Encrypted Signaling Transport Modes for the Host Identity Protocol [draft-ietf-hip-over-hip-06] (13 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-registration-02] (13 pages) - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) [draft-ietf-hip-reload-instance-10] (10 pages) - Host Identity Protocol Architecture [draft-ietf-hip-rfc4423-bis-20] (50 pages) - An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [draft-ietf-hip-rfc4843-bis-08] (14 pages) - Host Identity Protocol Version 2 (HIPv2) [draft-ietf-hip-rfc5201-bis-20] (128 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-rfc5202-bis-07] (40 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-rfc5203-bis-11] (16 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rfc5204-bis-08] (14 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extension [draft-ietf-hip-rfc5205-bis-10] (18 pages) - Host Mobility with the Host Identity Protocol [draft-ietf-hip-rfc5206-bis-14] (37 pages) - Host Identity Protocol Certificates [draft-ietf-hip-rfc6253-bis-09] (13 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rvs-05] (15 pages) - Host Identity Protocol (HIP) Multi-Hop Routing Extension [draft-ietf-hip-via-03] (10 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (104 pages) * Updates RFC6253 * Obsoletes RFC7401 RFC5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (30 pages) * Obsoletes RFC7402 RFC5203: Host Identity Protocol (HIP) Registration Extension (13 pages) * Obsoletes RFC8003 RFC5204: Host Identity Protocol (HIP) Rendezvous Extension (15 pages) * Obsoletes RFC8004 RFC5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (17 pages) * Obsoletes RFC8005 RFC5206: End-Host Mobility and Multihoming with the Host Identity Protocol (40 pages) * Obsoletes RFC8046 RFC5338: Using the Host Identity Protocol with Legacy Applications (14 pages) RFC5770: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators (34 pages) RFC6028: Host Identity Protocol (HIP) Multi-Hop Routing Extension (10 pages) RFC6078: Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) (17 pages) RFC6079: HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) (21 pages) RFC6253: Host Identity Protocol Certificates (12 pages) * Obsoletes RFC8002 RFC6261: Encrypted Signaling Transport Modes for the Host Identity Protocol (13 pages) RFC6317: Basic Socket Interface Extensions for the Host Identity Protocol (HIP) (18 pages) RFC7086: Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) (10 pages) RFC7343: An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) (14 pages) RFC7401: Host Identity Protocol Version 2 (HIPv2) (128 pages) * Updates RFC8002 RFC7402: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (40 pages) RFC8002: Host Identity Protocol Certificates (13 pages) RFC8003: Host Identity Protocol (HIP) Registration Extension (16 pages) RFC8004: Host Identity Protocol (HIP) Rendezvous Extension (14 pages) RFC8005: Host Identity Protocol (HIP) Domain Name System (DNS) Extension (18 pages) RFC8046: Host Mobility with the Host Identity Protocol (37 pages) RFC8047: Host Multihoming with the Host Identity Protocol (22 pages) Home Networking (homenet) ------------------------- Charter Last Modified: 2019-06-04 Current Status: Active Chairs: Barbara Stark Stephen Farrell Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Tech Advisor: Acee Lindem Mailing Lists: General Discussion: homenet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/homenet Archive: https://mailarchive.ietf.org/arch/browse/homenet/ Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small "residential home" networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network for the home. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture, as appropriate. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The group should assume that an IPv4 network may have to co-exist alongside the IPv6 network and should take this into account insofar as alignment with IPv6 is desirable. But the group should also ensure that even IPv6-only are possible, and while IP-version agnostic work is of course desirable, IPv4-specific work is outside the scope of the group. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, UPnP Forum, OASIS, ZigBee Alliance and other SDOs is necessary, as is understanding existing technology from these groups. Goals and Milestones: Nov 2018 - First WG draft on perimeter security Nov 2018 - Submission of the name resolution draft to the IESG as Standards Track RFC Mar 2019 - Submission of the service discovery draft to the IESG as Standards Track RFC Nov 2019 - Submission of the perimeter security draft to the IESG as Informational RFC Done - Formation of the working group Done - First WG draft on the architecture Done - Submission of the architecture draft to the IESG as Informational RFC Done - First WG draft on prefix configuration Done - First WG draft on routing Done - First WG draft on name resolution Done - First WG draft on service discovery Done - Start of routing related work in the relevant routing area working group, if needed Done - RFC 7695 - Submission of the prefix configuration draft to the IESG as Standards Track RFC Superceded - Submission of the routing draft to the IESG as Informational RFC Internet-Drafts: - Homenet profile of the Babel routing protocol [draft-chroboczek-homenet-babel-profile-00] (7 pages) - IPv6 Home Networking Architecture Principles [draft-ietf-homenet-arch-17] (49 pages) - Homenet profile of the Babel routing protocol [draft-ietf-homenet-babel-profile-07] (9 pages) - Distributed Node Consensus Protocol [draft-ietf-homenet-dncp-12] (41 pages) - Special-Use Domain 'home.arpa.' [draft-ietf-homenet-dot-14] (12 pages) - Outsourcing Home Network Authoritative Naming Service [draft-ietf-homenet-front-end-naming-delegation-11] (39 pages) - Home Networking Control Protocol [draft-ietf-homenet-hncp-10] (40 pages) - Home Networking Control Protocol [draft-ietf-homenet-hncp-bis-00] (38 pages) - Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes [draft-ietf-homenet-hybrid-proxy-zeroconf-02] (16 pages) - DHCPv6 Options for Home Network Naming Authority [draft-ietf-homenet-naming-architecture-dhc-options-08] (14 pages) - Distributed Prefix Assignment Algorithm [draft-ietf-homenet-prefix-assignment-08] (20 pages) - Redacting .home from HNCP [draft-ietf-homenet-redact-03] (3 pages) - Homenet Routing Consensus Call [draft-ietf-homenet-routing-consensus-call-01] (4 pages) - Homenet Naming and Service Discovery Architecture [draft-ietf-homenet-simple-naming-03] (23 pages) - Homenet Naming and Service Discovery Architecture [draft-lemon-homenet-naming-architecture-01] (21 pages) - Outsourcing Home Network Authoritative Naming Service [draft-mglt-homenet-front-end-naming-delegation-04] (21 pages) - DHCP Options for Homenet Naming Architecture [draft-mglt-homenet-naming-architecture-dhc-options-02] (24 pages) - Prefix and Address Assignment in a Home Network [draft-pfister-homenet-prefix-assignment-02] (29 pages) - Home Networking Control Protocol [draft-stenberg-homenet-hncp-00] (27 pages) - Simple Homenet Naming and Service Discovery Architecture [draft-tldm-simple-homenet-naming-01] (9 pages) Requests for Comments: RFC7368: IPv6 Home Networking Architecture Principles (49 pages) RFC7695: Distributed Prefix Assignment Algorithm (20 pages) RFC7787: Distributed Node Consensus Protocol (41 pages) RFC7788: Home Networking Control Protocol (40 pages) * Updates RFC8375 RFC8375: Special-Use Domain 'home.arpa.' (12 pages) Building Blocks for HTTP APIs (httpapi) --------------------------------------- Charter Last Modified: 2020-10-23 Current Status: Active Chairs: Darrel Miller Rich Salz Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Editor: Mark Nottingham Mailing Lists: General Discussion: httpapi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/httpapi Archive: https://mailarchive.ietf.org/arch/browse/httpapi/ Description of Working Group: In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs. This Working Group will standardise HTTP protocol extensions for use in such cases, with a focus on building blocks for separate or combined use. Its output can include the following: • Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields) • Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects) • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc. Other items are out of scope. In particular, this WG will not take on work items for HTTP APIs for specific applications or services, and it will not define new HTTP extension points. APIs for HTTP itself (e.g., in clients and servers) are also out of scope. To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. To assess whether the group is functioning well, this charter will be reviewed by the IESG nine months after chartering. This Working Group will also need to coordinate closely with the HTTP Working Group, in particular when new methods and status codes are proposed. Work items that are more broadly applicable (e.g., for implementation in Web browsers) are likely to be more appropriate in the HTTP Working Group, but it is expected that coordination and discussion between the groups' Chairs and Area Director(s) will guide work items to the appropriate venue. Goals and Milestones: Internet-Drafts: No Requests for Comments HTTP (httpbis) -------------- Charter Last Modified: 2020-09-10 Current Status: Active Chairs: Mark Nottingham Tommy Pauly Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba 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: Jun 2020 - Submit the "core" HTTP documents for consideration as Internet Standards - Submit RFC6265bis (Cookies) - Submit Client Hints - Submit Structured Headers - Submit Secondary Certificates - Submit Building Protocols with HTTP (BCP56bis) - Submit HTTP Representation Variants - Submit Cache-Status Header - Submit Proxy-Status Header - Submit Digest Headers Internet-Drafts: - Secondary Certificate Authentication in HTTP/2 [draft-bishop-httpbis-http2-additional-certs-05] (21 pages) - Using TLS 1.3 with HTTP/2 [draft-davidben-http2-tls13-00] (4 pages) - The Key HTTP Response Header Field [draft-fielding-http-key-03] (17 pages) - HTTP Client Hints [draft-grigorik-http-client-hints-03] (11 pages) - 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-09] (32 pages) - HTTP Caching [draft-ietf-httpbis-cache-12] (42 pages) - Cache Digests for HTTP/2 [draft-ietf-httpbis-cache-digest-05] (17 pages) - The Cache-Status HTTP Response Header Field [draft-ietf-httpbis-cache-header-05] (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) - HTTP Client Hints [draft-ietf-httpbis-client-hints-15] (14 pages) - HTTP Conditional Requests [draft-ietf-httpbis-conditional-01] (4 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 Headers [draft-ietf-httpbis-digest-headers-04] (37 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] (23 pages) - Bootstrapping WebSockets with HTTP/2 [draft-ietf-httpbis-h2-websockets-07] (8 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] (42 pages) - Hypertext Transfer Protocol Version 2 (HTTP/2) [draft-ietf-httpbis-http2-17] (96 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) - Signing HTTP Messages [draft-ietf-httpbis-message-signatures-00] (38 pages) - HTTP/1.1 Messaging [draft-ietf-httpbis-messaging-12] (54 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-15] (5 pages) - The ORIGIN HTTP/2 Frame [draft-ietf-httpbis-origin-frame-06] (11 pages) - 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-02] (22 pages) - The Proxy-Status HTTP Response Header Field [draft-ietf-httpbis-proxy-status-02] (19 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) - 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-06] (53 pages) - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) [draft-ietf-httpbis-rfc7238bis-03] (6 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - HTTP Semantics [draft-ietf-httpbis-semantics-12] (219 pages) - The ALPN HTTP Header Field [draft-ietf-httpbis-tunnel-protocol-05] (7 pages) - HTTP Representation Variants [draft-ietf-httpbis-variants-06] (23 pages) - Extensible Prioritization Scheme for HTTP [draft-kazuho-httpbis-priority-04] (20 pages) - Bootstrapping WebSockets with HTTP/2 [draft-mcmanus-httpbis-h2-websockets-02] (7 pages) - The ORIGIN HTTP/2 Frame [draft-nottingham-httpbis-origin-frame-01] (4 pages) - The Proxy-Status HTTP Header Field [draft-nottingham-proxy-status-00] (17 pages) - Signing HTTP Messages [draft-richanna-http-message-signatures-00] (38 pages) - Reactive Certificate-Based Client Authentication in HTTP/2 [draft-thomson-http2-client-certs-02] (19 pages) - Same-site Cookies [draft-west-first-party-cookies-07] (14 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (14 pages) RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (89 pages) * Updates RFC8615 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (101 pages) RFC7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (28 pages) RFC7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests (25 pages) RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching (43 pages) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication (19 pages) 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) RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (96 pages) * Updates RFC8740 RFC7541: HPACK: Header Compression for HTTP/2 (55 pages) RFC7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields (6 pages) RFC7639: The ALPN HTTP Header Field (7 pages) RFC7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding (7 pages) 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) Interface to Network Security Functions (i2nsf) ----------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Linda Dunbar Yoav Nir Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: i2nsf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2nsf Archive: https://mailarchive.ietf.org/arch/browse/i2nsf/ Description of Working Group: A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, or availability of network communications, to detect unwanted network activity, or to block or at least mitigate the effects of unwanted activity. NSFs are provided and consumed in increasingly diverse environments. Users could consume network security services enforced by NSFs hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Similarly, service providers may offer their customers network security services that are enforced by multiple security products, functions from different vendors, or open source technologies. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to control and monitor the behavior of NSFs, it has become virtually impossible for providers of security services to automate service offerings that utilize different security functions from multiple vendors. The goal of I2NSF is to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs, enabling clients to specify rulesets. If the working group finds it necessary to work on an information model before the data models, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope. As there are many different security vendors or open source technologies supporting different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), web filtering, flow filtering, deep packet inspection, or pattern matching and remediation. Controlling and monitoring aspects of NSFs include the ability to specify rules (by a single controller at the first phase), query, and monitor NSFs by one or more management entities. The initial phase of I2NSF will only consider one single controller that can specify or change rules to NSFs because multi-headed control requires the coordination to avoid potential conflict of rules. The NSFs can be monitored by multiple entities, but the database update and synchronization among multiple management entities are out of scope for I2NSF. I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions: The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. The term "Functional Implementation" is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs. The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF Capability Layer. The I2NSF Service Layer also allows the client to monitor the client specific policies. A client may leverage the I2NSF Service Layer interface to express security policies to a security controller, which in turn interacts with one or more NSFs through the I2NSF Capability Layer interface. Alternatively, a client may interact with one or more NSFs directly through the I2NSF Capability Layer interface. Since there could be many depths or types of Service Layer policies, the following bullets further clarify the scope of I2NSF: o Only the simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope. Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF. This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy. o I2NSF will not specify abstract or sophisticated policies from clients. Expressing policies in ways other than the model used by the Capability Layer is out of scope. o The translation mechanism/methods from Service Layer policies to Capability layer commands are out of scope for I2NSF. However, I2NSF will provide a discussion forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions. Such documents would be pursued outside the WG. Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for providers of security service to automate the use of different NSFs from multiple vendors. This work will leverage the existing protocols and data models defined by the I2RS, NETCONF, and NETMOD working groups. If extensions to these protocols or data models are needed, requirements will be developed by this WG, and the extensions will be developed in cooperation with the working groups responsible for the protocols. The I2NSF working group's deliverables include: o A single document covering use cases, problem statement, and gap analysis document. This document will initially be produced for reference as a living list to track and record discussions: the working group may decide to not publish this document as an RFC. o A framework document, presenting an overview of the use of NSFs and the purpose of the models developed by the working group. This document will also be a reference text to guide the main work and the working group may decide to not publish this document as an RFC. o If the working group considers it necessary, a single, unified, Information Model to describe the control and monitoring of flow-based NSFs. o YANG data models for the control and monitoring of NSFs. o A vendor-neutral vocabulary to enable the characteristics and behavior of NSFs to be specified without requiring the NSFs themselves to be standardized, so that "security controller" or "manager" have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients. o An examination of existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entities. This document may also be produced as a working document that is not published as an RFC. The working group may additionally choose to develop documents to describe requirements for extensions (if any) to existing protocols used by the working group, to explain how the data models are used to monitor and control flow-based NSFs, and to describe how to use I2RS and NETCONF to carry the content of the data models. These documents may be published as Informational RFCs or may be working documents that are discarded once they have triggered the necessary work. The working group will work closely with the I2RS, NETCONF, and NETMOD WGs. The working group will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the working group scope in organizations like ONF, OpenStack, ODL, and OPNFV. The working group must have the above deliverables completed within 24 months. The responsible AD will close the working group at that time if they are not completed or close to completion. The working group may be closed earlier if substantial progress is not being made. Goals and Milestones: Dec 2016 - Adopt examination of existing secure communication mechanisms as WG document Dec 2018 - Data Models and Applicability Statements to IESG for publication Feb 2019 - Adopt IANA registry consideration as WG document Feb 2019 - Working group re-charter or close Done - Adopt use Cases, problem statement, and gap analysis as WG document Done - Adopt framework as WG document Done - Adopt requirements for extensions to protocols as WG document Done - WG decides whether to progress adopted drafts for publication as RFCs (use cases, framework, information model, and examination of existing secure communication mechanisms) Done - Adopt info model as WG document (if desired) Done - Adopt data models as WG document Done - Adopt applicability statements as WG Document Done - All early drafts to IESG for publication (if WG decided to proceed): use cases, problem statement, and gap analysis document; framework document; information model requirements for extensions to protocols document; examination of existing secure communication mechanisms document Internet-Drafts: - Software-Defined Networking (SDN)-based IPsec Flow Protection [draft-abad-i2nsf-sdn-ipsec-flow-protection-03] (45 pages) - Analysis of Existing work for I2NSF [draft-hares-i2nsf-gap-analysis-01] (44 pages) - I2NSF Problem Statement and Use cases [draft-hares-i2nsf-merged-problem-use-cases-00] (23 pages) - A YANG Data Model for Monitoring I2NSF Network Security Functions [draft-hong-i2nsf-nsf-monitoring-data-model-06] (75 pages) - Applicability of Interfaces to Network Security Functions to Network-Based Security Services [draft-ietf-i2nsf-applicability-18] (29 pages) - Information Model of NSFs Capabilities [draft-ietf-i2nsf-capability-05] (26 pages) - I2NSF Capability YANG Data Model [draft-ietf-i2nsf-capability-data-model-12] (56 pages) - Requirements for Client-Facing Interface to Security Controller [draft-ietf-i2nsf-client-facing-interface-req-05] (24 pages) - I2NSF Consumer-Facing Interface YANG Data Model [draft-ietf-i2nsf-consumer-facing-interface-dm-12] (57 pages) - Framework for Interface to Network Security Functions [draft-ietf-i2nsf-framework-10] (25 pages) - Analysis of Existing work for I2NSF [draft-ietf-i2nsf-gap-analysis-03] (48 pages) - I2NSF Network Security Function-Facing Interface YANG Data Model [draft-ietf-i2nsf-nsf-facing-interface-dm-10] (104 pages) - I2NSF NSF Monitoring YANG Data Model [draft-ietf-i2nsf-nsf-monitoring-data-model-04] (80 pages) - Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases [draft-ietf-i2nsf-problem-and-use-cases-16] (29 pages) - I2NSF Registration Interface YANG Data Model [draft-ietf-i2nsf-registration-interface-dm-09] (43 pages) - Software-Defined Networking (SDN)-based IPsec Flow Protection [draft-ietf-i2nsf-sdn-ipsec-flow-protection-11] (92 pages) - Interface to Network Security Functions (I2NSF) Terminology [draft-ietf-i2nsf-terminology-08] (13 pages) - Applicability of Interfaces to Network Security Functions to Networked Security Services [draft-jeong-i2nsf-applicability-01] (15 pages) - Requirements for Client-Facing Interface to Security Controller [draft-kumar-i2nsf-client-facing-interface-req-02] (22 pages) - Information Model of NSFs Capabilities [draft-xibassnez-i2nsf-capability-02] (57 pages) Requests for Comments: RFC8192: Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases (29 pages) RFC8329: Framework for Interface to Network Security Functions (25 pages) Interface to the Routing System (i2rs) -------------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Russ White Susan Hares Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Mailing Lists: General Discussion: i2rs@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2rs Archive: https://mailarchive.ietf.org/arch/browse/i2rs/ Description of Working Group: In an IP routed network, the routing system: - Distributes topology and other state (network metadata) - Uses this network metadata to determine the best paths to each given reachable destination attached to the network - Communicates these decisions to the forwarding plane of each forwarding device in the network. That is, the routing system is the collection of entities, protocols and processes that collectively build the forwarding tables that are exported into the entities that constitute the network's forwarding plane. While processes participating in the routing system are often colocated with the local forwarding elements, this isn't a necessary condition. Thus, the routing system includes control plane protocols and processes that compute routes and paths for data packets, wherever the processes implementing those protocols and processes may be running. I2RS facilitates real-time or event driven interaction with the routing system through a collection of protocol-based control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or by notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and among multiple interactions with the routing system. The I2RS interfaces will co-exist with existing configuration and management systems and interfaces. It is envisioned that users of the I2RS interfaces will be management applications, network controllers, and user applications that make specific demands on the network. The I2RS working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the specific use cases, and that will lead to an understanding of the abstract informational models and requirements for encodings and protocols for the I2RS interfaces. Small and well-scoped use cases are critical to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. Initial work within the working group will be limited to a single administrative domain. The working group is chartered to work on the following items: - High-level architecture for I2RS including considerations of policy and security. - Tightly scoped key use cases for operational use of I2RS as follows: o Interactions with the Routing Information Base (RIB). Allowing read and write access to the RIB, but no direct access to the Forwarding Information Base (FIB). o Filter-based RIBs include a match of fields in IP header plus other IP packet format fields. The matches in the filter-based RIBs may be ordered to allow appropriate sequencing of the filter. Each match contains an action which may be forwarding to a next hop address or other actions. I2RS will coordinate this work with appropriate working groups in routing, security and operations & management areas. o Control and analysis of the operation of the Border Gateway Protocol (BGP) including the setting and activation of policies related to the protocol. o Control, optimization, and choice of traffic exit points from networks based on more information than provided by the dynamic control plane. o Distributed reaction to network-based attacks through rapid modification of the control plane behavior to reroute traffic for one destination while leaving standard mechanisms (filters, metrics, and policy) in place for other routes. o Service layer routing to improve on existing hub-and-spoke traffic. o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as a work item. Such topology-related models will be based on a generic topology model to support multiple uses; the generic topology model should support topology extension for non-I2RS uses. o Other use cases may be adopted by the working group only through rechartering. - Yang Data Models consistent with the use cases. Such documents should include an information overview. The existing WG draft - draft-ietf-i2rs-rib-info-model - that is just an informational model can be completed or extended with the associated YANG data model. - Requirements for I2RS protocols and encoding languages. - An analysis of existing IETF and other protocols and encoding languages against the requirements. Goals and Milestones: Mar 2016 - Request Publication of Filter-Based RIB Data Model Aug 2016 - Request publication of an Informational document defining the protocol requirements Aug 2016 - Request publication of Standards Track documents specifying information models Sep 2016 - Request publication of Informational documents describing use cases Sep 2016 - Request Publication of Protocol Independent RIB Data Model Oct 2016 - Consider re-chartering Nov 2016 - Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements Dec 2016 - Request publication of an Informational document defining encoding language requirements Dec 2016 - Request Publication of Protocol Independent Topology Data Models Done - Working Group adoption of Filter-Based RIB Yang Data Model RFC7921 - Request publication of an Informational document defining the problem statement RFC7921 - Request publication of an Informational document defining the high-level architecture Internet-Drafts: - An Architecture for the Interface to the Routing System [draft-atlas-i2rs-architecture-02] (21 pages) - Interface to the Routing System Problem Statement [draft-atlas-i2rs-problem-statement-02] (10 pages) - Identifier Management for I2RS Protocol [draft-chen-i2rs-identifier-management-00] (9 pages) - A YANG Data Model for Layer 3 Topologies [draft-clemm-i2rs-yang-l3-topo-00] (39 pages) - A Data Model for Network Topologies [draft-clemm-i2rs-yang-network-topo-04] (25 pages) - A YANG Data Model for Layer-2 Network Topologies [draft-dong-i2rs-l2-network-topology-01] (14 pages) - I2RS Ephemeral State Requirements [draft-haas-i2rs-ephemeral-state-reqs-00] (9 pages) - I2RS requirements for netmod/netconf [draft-haas-i2rs-netmod-netconf-requirements-01] (9 pages) - I2RS Security Related Requirements [draft-hares-i2rs-auth-trans-05] (10 pages) - An Information Model for Basic Network Policy and Filter Rules [draft-hares-i2rs-bnp-eca-data-model-03] (30 pages) - Filter-Based RIB Data Model [draft-hares-i2rs-fb-rib-data-model-03] (20 pages) - Filter-Based Packet Forwarding ECA Policy [draft-hares-i2rs-pkt-eca-data-model-02] (37 pages) - An Information Model for Basic Network Policy [draft-hareskini-i2rs-pbr-info-model-00] (17 pages) - An Architecture for the Interface to the Routing System [draft-ietf-i2rs-architecture-15] (40 pages) - Interface to the Routing System (I2RS) Ephemeral State Requirements [draft-ietf-i2rs-ephemeral-state-23] (12 pages) - Filter-Based RIB Data Model [draft-ietf-i2rs-fb-rib-data-model-01] (21 pages) - Filter-Based RIB Information Model [draft-ietf-i2rs-fb-rib-info-model-00] (21 pages) - Filter-Based Packet Forwarding ECA Policy [draft-ietf-i2rs-pkt-eca-data-model-03] (39 pages) - Problem Statement for the Interface to the Routing System [draft-ietf-i2rs-problem-statement-11] (12 pages) - Interface to the Routing System (I2RS) Security-Related Requirements [draft-ietf-i2rs-protocol-security-requirements-17] (20 pages) - Requirements for Subscription to YANG Datastores [draft-ietf-i2rs-pub-sub-requirements-09] (18 pages) - A YANG Data Model for the Routing Information Base (RIB) [draft-ietf-i2rs-rib-data-model-15] (71 pages) - RIB Information Model [draft-ietf-i2rs-rib-info-model-17] (28 pages) - I2RS Environment Security Requirements [draft-ietf-i2rs-security-environment-reqs-06] (28 pages) - Interface to the Routing System (I2RS) Traceability: Framework and Information Model [draft-ietf-i2rs-traceability-11] (17 pages) - Summary of I2RS Use Case Requirements [draft-ietf-i2rs-usecase-reqs-summary-03] (34 pages) - A YANG Data Model for Fabric Topology in Data-Center Networks [draft-ietf-i2rs-yang-dc-fabric-network-topology-12] (32 pages) - A YANG Data Model for Layer 2 Network Topologies [draft-ietf-i2rs-yang-l2-network-topology-18] (34 pages) - A YANG Data Model for Layer 3 Topologies [draft-ietf-i2rs-yang-l3-topology-16] (35 pages) - A YANG Data Model for Network Topologies [draft-ietf-i2rs-yang-network-topo-20] (57 pages) - Use Cases for an Interface to BGP Protocol [draft-keyupate-i2rs-bgp-usecases-04] (21 pages) - Filter-Based RIB Information Model [draft-kini-i2rs-fb-rib-info-model-03] (21 pages) - I2RS Environment Security Requirements [draft-mglt-i2rs-security-environment-reqs-01] (19 pages) - Routing Information Base Info Model [draft-nitinb-i2rs-rib-info-model-02] (26 pages) - BGP Model for Service Provider Networks [draft-shaikh-idr-bgp-model-02] (77 pages) - Requirements for Subscription to YANG Datastores [draft-voit-i2rs-pub-sub-requirements-00] (13 pages) - Data Model for RIB I2RS protocol [draft-wang-i2rs-rib-data-model-02] (38 pages) - A YANG Data Model for Layer 1 Network Topology [draft-zhang-i2rs-l1-topo-yang-model-01] (23 pages) - TRILL Support of Point to Multipoint BFD [draft-zhang-trill-p2mp-bfd-02] (7 pages) - Yang Data Model for BGP Protocol [draft-zhdankin-idr-bgp-cfg-00] (44 pages) Requests for Comments: RFC7920: Problem Statement for the Interface to the Routing System (12 pages) RFC7921: An Architecture for the Interface to the Routing System (40 pages) RFC7922: Interface to the Routing System (I2RS) Traceability: Framework and Information Model (17 pages) RFC7923: Requirements for Subscription to YANG Datastores (18 pages) RFC8241: Interface to the Routing System (I2RS) Security-Related Requirements (20 pages) RFC8242: Interface to the Routing System (I2RS) Ephemeral State Requirements (12 pages) RFC8345: A YANG Data Model for Network Topologies (57 pages) RFC8346: A YANG Data Model for Layer 3 Topologies (35 pages) RFC8430: RIB Information Model (28 pages) RFC8431: A YANG Data Model for the Routing Information Base (RIB) (71 pages) RFC8542: A YANG Data Model for Fabric Topology in Data-Center Networks (32 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2020-03-20 Current Status: Active Chairs: John Scudder Susan Hares Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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 Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Jun 2015 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Nov 2015 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Nov 2015 - Submit Multisession BGP 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 ASpath ORF draft to IESG as a Proposed Standard Feb 2016 - Submit Yang BGP Modules to IESG as Proposed Standard Apr 2016 - Solicit work items for scalability improvements Apr 2016 - Progress base BGP specification (RFC 4271) as Full Standard Done - Submit to BGP Capability Advertisement to the IESG Done - Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done - Submit BGP4 MIB to IESG as a Proposed Standard Done - Submit BGP4 document to IESG as a Draft Standard Done - Submit BGP Graceful Restart to IESG as a Proposed Standard Done - Submit Extended Communities draft to IESG as a Proposed Standard Done - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit 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 Extended Community Registries Update [draft-cl-idr-bgp-ext-com-registry-update-01] (5 pages) - BGP Link State Extensions for SRv6 [draft-dawra-idr-bgpls-srv6-ext-06] (24 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-dong-idr-rtc-hierarchical-rr-02] (6 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) - 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) - A BGP/IDRP Route Server alternative to a full mesh routing [draft-haskin-bgp-idrp-mesh-routing-00] (16 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) - 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) - 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) - 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) - 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) - AS Path Based Outbound Route Filter for BGP-4 [draft-ietf-idr-aspath-orf-13] (7 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) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp-analysis-07] (16 pages) - Constrain Attribute announcement within BGP [draft-ietf-idr-bgp-attribute-announcement-02] (9 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-03] (6 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) - 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 Community Registries Update [draft-ietf-idr-bgp-ext-com-registry-00] (5 pages) - BGP Extended Communities Attribute [draft-ietf-idr-bgp-ext-communities-09] (12 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-01] (10 pages) - Revised Validation Procedure for BGP Flow Specifications [draft-ietf-idr-bgp-flowspec-oid-12] (11 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) - 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 Attributes Advertisement with BGP Link-State [draft-ietf-idr-bgp-ls-app-specific-attr-03] (13 pages) - Flexible Algorithm Definition Advertisement with BGP Link-State [draft-ietf-idr-bgp-ls-flex-algo-04] (14 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-01] (5 pages) - BGP Link-State Extensions for Seamless BFD [draft-ietf-idr-bgp-ls-sbfd-extensions-02] (9 pages) - BGP Link-State extensions for Segment Routing [draft-ietf-idr-bgp-ls-segment-routing-ext-16] (31 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) - SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS [draft-ietf-idr-bgp-ls-sr-policy-path-segment-00] (11 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) - BGP YANG Model for Service Provider Networks [draft-ietf-idr-bgp-model-09] (134 pages) - Multisession BGP [draft-ietf-idr-bgp-multisession-07] (19 pages) - Carrying next-hop cost information in BGP [draft-ietf-idr-bgp-nh-cost-02] (10 pages) - Route Leak Prevention using Roles in Update and Open messages [draft-ietf-idr-bgp-open-policy-13] (11 pages) - BGP Optimal Route Reflection (BGP-ORR) [draft-ietf-idr-bgp-optimal-route-reflection-21] (16 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) - 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) - 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) - BGP-4 Requirement Satisfaction Report [draft-ietf-idr-bgp4-stdreport1-02] (3 pages) - BGP4/IDRP for IP---OSPF Interaction [draft-ietf-idr-bgp4ospf-interact-07] (19 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-ietf-idr-bgpls-inter-as-topology-ext-09] (12 pages) - BGP-LS extensions for Segment Routing BGP Egress Peer Engineering [draft-ietf-idr-bgpls-segment-routing-epe-19] (18 pages) - BGP Link State Extensions for SRv6 [draft-ietf-idr-bgpls-srv6-ext-03] (24 pages) - Revision to Capability Codes Registration Procedures [draft-ietf-idr-capabilities-registry-change-09] (5 pages) - Subcodes for BGP Cease Notification Message [draft-ietf-idr-cease-subcode-07] (6 pages) - BGP Communities Attribute [draft-ietf-idr-communities-00] (5 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-00] (10 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-usage-00] (9 pages) - BGP Custom Decision Process [draft-ietf-idr-custom-decision-08] (11 pages) - Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 [draft-ietf-idr-deprecate-30-31-129-02] (3 pages) - Deprecation of AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-set-confed-set-04] (7 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-14] (7 pages) - Distribution of Traffic Engineering Extended Admin Groups using BGP-LS [draft-ietf-idr-eag-distribution-12] (6 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) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-error-handling-19] (19 pages) - Extended Optional Parameters Length for BGP OPEN Message [draft-ietf-idr-ext-opt-param-09] (6 pages) - IANA Registries for BGP Extended Communities [draft-ietf-idr-extcomm-iana-02] (16 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-flow-spec-09] (22 pages) - Dissemination of Flow Specification Rules for IPv6 [draft-ietf-idr-flow-spec-v6-17] (18 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-15] (23 pages) - BGP Flow Specification Filter for MPLS Label [draft-ietf-idr-flowspec-mpls-match-01] (8 pages) - BGP Dissemination of Flow Specification Rules for Tunneled Traffic [draft-ietf-idr-flowspec-nvo3-10] (21 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-11] (12 pages) - BGP Flow-Spec Redirect to IP Action [draft-ietf-idr-flowspec-redirect-ip-02] (9 pages) - Clarification of the Flowspec Redirect Extended Community [draft-ietf-idr-flowspec-redirect-rt-bis-05] (7 pages) - Subcodes for BGP Finite State Machine Error [draft-ietf-idr-fsm-subcode-03] (5 pages) - IDRP for IP v4 and v6 [draft-ietf-idr-idrp-v4v6-02] (20 pages) - Inter-Domain Routing Protocol, Version 2 [draft-ietf-idr-idrp2-00] (110 pages) - Internet Exchange BGP Route Server [draft-ietf-idr-ix-bgp-route-server-12] (12 pages) - Internet Exchange Route Server - Implementation Report [draft-ietf-idr-ix-bgp-route-server-implementation-00] (5 pages) - BGP Large Communities Attribute [draft-ietf-idr-large-community-12] (8 pages) - Reservation of Last Autonomous System (AS) Numbers [draft-ietf-idr-last-as-reservation-07] (5 pages) - Automatic Route Target Filtering for legacy PEs [draft-ietf-idr-legacy-rtc-08] (10 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-07] (5 pages) - Support for Long-lived BGP Graceful Restart [draft-ietf-idr-long-lived-gr-00] (25 pages) - North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP [draft-ietf-idr-ls-distribution-13] (48 pages) - BGP Link-State Information Distribution Implementation Report [draft-ietf-idr-ls-distribution-impl-04] (15 pages) - Distribution of TRILL Link-State using BGP [draft-ietf-idr-ls-trill-05] (16 pages) - Key Management Considerations for the TCP MD5 Signature Option [draft-ietf-idr-md5-keys-00] (7 pages) - Multicast Distribution Control Signaling [draft-ietf-idr-mdcs-00] (9 pages) - Multicast Distribution Reachability Signaling [draft-ietf-idr-mdrs-00] (6 pages) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-04] (4 pages) - BGP Next-Hop dependent capabilities [draft-ietf-idr-next-hop-capability-06] (13 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-02] (10 pages) - Configuring IDRP Confederations [draft-ietf-idr-rdc-config-01] (5 pages) - Registered Wide BGP Community Values [draft-ietf-idr-registered-wide-bgp-communities-02] (18 pages) - Assigned BGP extended communities [draft-ietf-idr-reserved-extended-communities-09] (6 pages) - Graceful Restart Mechanism for BGP [draft-ietf-idr-restart-13] (15 pages) - Reclassification of RFC 1863 to Historic [draft-ietf-idr-rfc1863-historic-00] (3 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-rfc2385bis-01] (6 pages) - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) [draft-ietf-idr-rfc2796bis-02] (12 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc2842bis-01] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc2858bis-10] (12 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-rfc3065bis-06] (14 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc3392bis-05] (7 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc4760bis-03] (13 pages) - BGP Support for Four-Octet Autonomous System (AS) Number Space [draft-ietf-idr-rfc4893bis-07] (12 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-rfc5575bis-27] (39 pages) - Distribution of Link-State and Traffic Engineering Information Using BGP [draft-ietf-idr-rfc7752bis-04] (59 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-07] (19 pages) - Making Route Servers Aware of Data Link Failures at IXPs [draft-ietf-idr-rs-bfd-09] (14 pages) - Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios [draft-ietf-idr-rtc-hierarchical-rr-03] (6 pages) - Route Target Constrained Distribution of Routes with no Route Targets [draft-ietf-idr-rtc-no-rt-12] (7 pages) - Advertising Segment Routing Policies in BGP [draft-ietf-idr-segment-routing-te-policy-09] (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 Path MTU in BGP [draft-ietf-idr-sr-policy-path-mtu-01] (9 pages) - SR Policy Extensions for Path Segment and Bidirectional Path [draft-ietf-idr-sr-policy-path-segment-01] (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-14] (49 pages) - BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions [draft-ietf-idr-te-pm-bgp-18] (10 pages) - The BGP Tunnel Encapsulation Attribute [draft-ietf-idr-tunnel-encaps-19] (45 pages) - Advertising an IPv4 NLRI with an IPv6 Next Hop [draft-ietf-idr-v4nlri-v6nh-01] (10 pages) - BGP Community Container Attribute [draft-ietf-idr-wide-bgp-communities-05] (25 pages) - IDRP for SIP [draft-ietf-ipidrp-sip-01] (9 pages) - Border Gateway Protocol (BGP) [draft-ietf-iwg-bgp-00] (29 pages) - Definitions of Managed Objects for the Border Gateway Protocol: Version 3 [draft-ietf-iwg-bgp-mib-02] (13 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-iwg-bgpapplication-00] (23 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) - Application Specific Attributes Advertisement with BGP Link-State [draft-ketant-idr-bgp-ls-app-specific-attr-01] (13 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) - 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-03] (9 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) - 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) - 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) - Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) [draft-ooms-v6ops-bgp-tunnel-07] (14 pages) - Segment Routing Egress Peer Engineering BGP-LS Extensions [draft-previdi-idr-bgpls-segment-routing-epe-03] (17 pages) - Advertising Segment Routing Policies in BGP [draft-previdi-idr-segment-routing-te-policy-07] (30 pages) - Advertising Node Admin Tags in BGP Link-State Advertisements [draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05] (11 pages) - 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) - Revision to Capability Codes Registration Procedures [draft-scudder-idr-capabilities-registry-change-02] (4 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) - Methods for Detection and Mitigation of BGP Route Leaks [draft-sriram-idr-route-leak-detection-mitigation-01] (17 pages) - Signaling Maximum SID Depth using Border Gateway Protocol Link-State [draft-tantsura-idr-bgp-ls-segment-routing-msd-05] (7 pages) - Support for Long-lived BGP Graceful Restart [draft-uttaro-idr-bgp-persistence-05] (25 pages) - Signalling ERLD using BGP-LS [draft-vandevelde-idr-bgp-ls-segment-routing-rld-03] (6 pages) - Flowspec Indirection-id Redirect [draft-vandevelde-idr-flowspec-path-redirect-03] (12 pages) - BGP Remote-Next-Hop [draft-vandevelde-idr-remote-next-hop-09] (17 pages) - BGP Persistent Route Oscillation Solutions [draft-walton-bgp-route-oscillation-stop-09] (9 pages) - BGP-LS Extension for Inter-AS Topology Retrieval [draft-wang-idr-bgpls-inter-as-topology-ext-02] (10 pages) - Distribution of MPLS-TE Extended admin Group Using BGP [draft-wang-idr-eag-distribution-02] (5 pages) - BGP Extensions for IDs Allocation [draft-wu-idr-bgp-segment-allocation-ext-05] (16 pages) - A YANG Data Model for Flow Specification [draft-wu-idr-flowspec-yang-cfg-02] (32 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) - 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) Requests for Comments: BCP172: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (5 pages) BCP6: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) RFC1163: Border Gateway Protocol (BGP) (29 pages) * Obsoletes RFC1267 RFC1164: Application of the Border Gateway Protocol in the Internet (23 pages) * Obsoletes RFC1268 RFC1265: BGP Protocol Analysis (8 pages) RFC1266: Experience with the BGP Protocol (9 pages) RFC1267: Border Gateway Protocol 3 (BGP-3) (35 pages) RFC1268: Application of the Border Gateway Protocol in the Internet (13 pages) * Obsoletes RFC1655 RFC1269: Definitions of Managed Objects for the Border Gateway Protocol: Version 3 (13 pages) * Obsoletes RFC4273 RFC1364: BGP OSPF Interaction (14 pages) * Obsoletes RFC1403 RFC1397: Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol (2 pages) RFC1654: A Border Gateway Protocol 4 (BGP-4) (56 pages) * Obsoletes RFC1771 RFC1655: Application of the Border Gateway Protocol in the Internet (19 pages) * Obsoletes RFC1772 RFC1656: BGP-4 Protocol Document Roadmap and Implementation Experience (4 pages) * Obsoletes RFC1773 RFC1657: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 (21 pages) * Obsoletes RFC4273 RFC1745: BGP4/IDRP for IP---OSPF Interaction (19 pages) RFC1773: Experience with the BGP-4 protocol (9 pages) RFC1774: BGP-4 Protocol Analysis (10 pages) RFC1863: A BGP/IDRP Route Server alternative to a full mesh routing (16 pages) * Obsoletes RFC4223 RFC1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) * Updates RFC6996 * Updates RFC7300 RFC1965: Autonomous System Confederations for BGP (7 pages) * Obsoletes RFC3065 RFC1966: BGP Route Reflection An alternative to full mesh IBGP (7 pages) * Obsoletes RFC4456 * Updates RFC2796 RFC1997: BGP Communities Attribute (5 pages) * Updates RFC7606 * Updates RFC8642 RFC1998: An Application of the BGP Community Attribute in Multi-home Routing (9 pages) RFC2270: Using a Dedicated AS for Sites Homed to a Single Provider (6 pages) RFC2283: Multiprotocol Extensions for BGP-4 (9 pages) * Obsoletes RFC2858 RFC2385: Protection of BGP Sessions via the TCP MD5 Signature Option (6 pages) * Obsoletes RFC5925 * Updates RFC6691 RFC2439: BGP Route Flap Damping (37 pages) RFC2519: A Framework for Inter-Domain Route Aggregation (13 pages) RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing (5 pages) RFC2796: BGP Route Reflection - An Alternative to Full Mesh IBGP (11 pages) * Obsoletes RFC4456 RFC2842: Capabilities Advertisement with BGP-4 (5 pages) * Obsoletes RFC3392 RFC2858: Multiprotocol Extensions for BGP-4 (11 pages) * Obsoletes RFC4760 RFC2918: Route Refresh Capability for BGP-4 (4 pages) * Updates RFC7313 RFC3065: Autonomous System Confederations for BGP (11 pages) * Obsoletes RFC5065 RFC3345: Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (19 pages) RFC3392: Capabilities Advertisement with BGP-4 (6 pages) * Obsoletes RFC5492 RFC3562: Key Management Considerations for the TCP MD5 Signature Option (7 pages) RFC4223: Reclassification of RFC 1863 to Historic (3 pages) RFC4271: A Border Gateway Protocol 4 (BGP-4) (104 pages) * Updates RFC6286 * Updates RFC6608 * Updates RFC6793 * Updates RFC7607 * Updates RFC7606 * Updates RFC7705 * Updates RFC8212 * Updates RFC8654 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 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 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) 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) 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) 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) 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) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2020-03-25 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) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-10] (19 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-10] (52 pages) - IP over Intentionally Partially Partitioned Links [draft-nordmark-intarea-ippl-05] (12 pages) Requests for Comments: BCP162: Logging Recommendations for Internet-Facing Servers (5 pages) BCP168: IP Router Alert Considerations and Usage (19 pages) BCP177: IPv6 Support Required for All IP-Capable Nodes (6 pages) BCP230: IP Fragmentation Considered Fragile (23 pages) RFC6269: Issues with IP Address Sharing (29 pages) RFC6302: Logging Recommendations for Internet-Facing Servers (5 pages) RFC6398: IP Router Alert Considerations and Usage (19 pages) RFC6540: IPv6 Support Required for All IP-Capable Nodes (6 pages) RFC6864: Updated Specification of the IPv4 ID Field (19 pages) RFC6967: Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments (24 pages) RFC7098: Using the IPv6 Flow Label for Load Balancing in Server Farms (13 pages) RFC7588: A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem (12 pages) RFC7676: IPv6 Support for Generic Routing Encapsulation (GRE) (11 pages) RFC8117: Current Hostname Practice Considered Harmful (12 pages) RFC8335: PROBE: A Utility for Probing Interfaces (19 pages) RFC8386: Privacy Considerations for Protocols Relying on IP Broadcast or Multicast (13 pages) RFC8801: Discovering Provisioning Domain Names and Data (27 pages) RFC8900: IP Fragmentation Considered Fragile (23 pages) IP Performance Measurement (ippm) --------------------------------- Charter Last Modified: 2020-04-02 Current Status: Active Chairs: Ian Swett Tommy Pauly Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke 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: Mar 2020 - submit a Standards Track draft on inband OAM based measurement methodologies to the IESG Mar 2020 - Submit a Standards Track document on Direct Export for IOAM Jul 2020 - Submit a Standards Track document on Metrics and Methods for IP Capacity Measurement 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 defining a metric for unidirectional route assessment to the IESG Internet-Drafts: - Two-Way Active Measurement Protocol (TWAMP) Data Model [draft-cmzrjp-ippm-twamp-yang-02] (56 pages) - Multipoint Alternate Marking method for passive and hybrid performance monitoring [draft-fioccola-ippm-multipoint-alt-mark-04] (20 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) - A Bulk Transfer Capacity Methodology for Cooperating Hosts [draft-ietf-ippm-btc-cap-00] (5 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-04] (24 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 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) - Framework for IP Performance Metrics [draft-ietf-ippm-framework-02] (40 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-09] (18 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] (78 pages) - Data Fields for In-situ OAM [draft-ietf-ippm-ioam-data-10] (44 pages) - In-situ OAM Direct Exporting [draft-ietf-ippm-ioam-direct-export-01] (10 pages) - In-situ OAM Flags [draft-ietf-ippm-ioam-flags-03] (11 pages) - In-situ OAM IPv6 Options [draft-ietf-ippm-ioam-ipv6-options-03] (13 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] (38 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) - 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) - One-Way Metric Applicability Statement [draft-ietf-ippm-owmetric-as-01] (8 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) - 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) - Advanced Unidirectional Route Assessment (AURA) [draft-ietf-ippm-route-10] (27 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 Optional Extensions [draft-ietf-ippm-stamp-option-tlv-09] (32 pages) - Simple Two-way Active Measurement Protocol (STAMP) Data Model [draft-ietf-ippm-stamp-yang-06] (35 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) - TReno Bulk Transfer Capacity [draft-ietf-ippm-treno-btc-03] (5 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) Data Model [draft-ietf-ippm-twamp-yang-13] (68 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) - 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) - 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) Requests for Comments: BCP108: IP Performance Metrics (IPPM) Metrics Registry (14 pages) BCP176: IP Performance Metrics (IPPM) Standard Advancement Testing (37 pages) RFC2330: Framework for IP Performance Metrics (40 pages) * Updates RFC7312 * Updates RFC8468 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) 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) RFC8889: Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring (23 pages) STD81: A One-Way Delay Metric for IP Performance Metrics (IPPM) (27 pages) STD82: A One-Way Loss Metric for IP Performance Metrics (IPPM) (22 pages) IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2019-11-20 Current Status: Active Chairs: Tero Kivinen Yoav Nir Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Dec 2019 - The internal address failure indication in IKEv2 to IESG May 2020 - G-DOI for IKEv2 to IESG May 2020 - Postquantum cryptography document for IKEv2 to IESG Aug 2020 - The security labels support for IKEv2 to IESG Aug 2020 - TCP-encapsulation guidelines document to IESG Nov 2020 - Traffic Flow Confidentiality document to IESG Jun 2021 - The ESP on contrained network to IESG Jun 2021 - Signature algorithm negotiation for IKEv2 to IESG Internet-Drafts: - IKEv2 Notification Codes for IPv4/IPv6 Coexistence [draft-boucadair-ipsecme-ipv6-ipv4-codes-03] (6 pages) - Postquantum Preshared Keys for IKEv2 [draft-fluhrer-qr-ikev2-04] (11 pages) - IP Traffic Flow Security [draft-hopps-ipsecme-iptfs-01] (25 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) - 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-01] (59 pages) - A TCP transport for the Internet Key Exchange [draft-ietf-ipsecme-ike-tcp-01] (9 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation [draft-ietf-ipsecme-ikev2-fragmentation-10] (20 pages) - Intermediate Exchange in the IKEv2 Protocol [draft-ietf-ipsecme-ikev2-intermediate-05] (11 pages) - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-ipv6-config-03] (32 pages) - Multiple Key Exchanges in IKEv2 [draft-ietf-ipsecme-ikev2-multiple-ke-01] (23 pages) - The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-null-auth-07] (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) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2bis-11] (138 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) - IP Traffic Flow Security [draft-ietf-ipsecme-iptfs-02] (26 pages) - IKEv2 Notification Status Types for IPv4/IPv6 Coexistence [draft-ietf-ipsecme-ipv6-ipv4-codes-05] (7 pages) - Labeled IPsec Traffic Selector support for IKEv2 [draft-ietf-ipsecme-labeled-ipsec-03] (8 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) - 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) - 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) - 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) - Intermediate Exchange in the IKEv2 Protocol [draft-smyslov-ipsecme-ikev2-aux-02] (10 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 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) RFC8229: TCP Encapsulation of IKE and IPsec Packets (25 pages) RFC8247: Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) (19 pages) 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) STD79: Internet Key Exchange Protocol Version 2 (IKEv2) (142 pages) IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Carlos J. Bernardos Russ Housley Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: https://mailarchive.ietf.org/arch/browse/its/ Description of Working Group: Automobiles and vehicles of all types are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are some of the new features expected in automobiles to hit the roads from now to year 2020. Today, there are several deployed Vehicle-to-Internet technologies (V2Internet) that make use of embedded Internet modules, or an occupant's cellular smartphone: mirrorlink, carplay, android auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) Communications are used for wireless exchange of critical safety and operational data between vehicles and roadway infrastructure, intended primarily to avoid motor vehicle crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used for short-range communications between vehicles to exchange vehicle information such as vehicle speed, heading and braking status. This group will work on V2V and V2I use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems. These vehicular networks are characterized by dynamically changing network topologies and connectivity. V2V and V2I communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for Dedicated short-range communications (DSRC). Several of these link-layers already provide support for IPv6. However, IPv6 on 802.11-OCB is yet to be fully defined. Some aspects of the IPv6 over 802.11-OCB work have been already defined at IEEE 1609 and the specification produced by this working group is expected be compatible with these aspects. This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode. Once this document is completed, it will also be reviewed by the 6man working group. This group will work on an informational document that will explain the state of the art in the field and describe the use cases that will use IPv6 in order to focus the work of the group. The group will also work on informational document that describes the problem statement and the associated security and privacy considerations. The working group will decide at a future point whether these informational documents need to be published separately as RFCs or if they maybe combined. The group will try to reuse relevant technologies for Internet of Things (IoT) and infrastructure mobility that have been developed in other IETF and IRTF groups. The WG will pay particular attention to the privacy characteristics of solution it develops in order to minimize unwanted tracking opportunities. The group will closely coordinate with IEEE 802.11. The IETF has also established a formal liason relationship with ISO/TC204 in connection with the work to be performed by this working group. The work produced by this group may also be of interest to other SDOs such as ETSI TC ITS, 3GPP, and government organizations such as the NHTSA. No formal co-ordination is anticipated with these groups at this point but work done in these SDOs may end up becoming relevant to the WG deliverables in the future. Goals and Milestones: Oct 2017 - Submit "ITS General Problem Area" to IESG May 2018 - Submit "Problem Statement" to IESG Done - Draft for "IPv6 over 802.11-OCB" adopted by WG Done - Draft for "ITS General Problem Area" adopted by WG Done - Draft for "Problem Statement" adopted by WG Done - Publish "IPv6 over 802.11-OCB" Internet-Drafts: - Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 [draft-ietf-ipwave-ipv6-over-80211ocb-52] (29 pages) - Problem Statement for IP Wireless Access in Vehicular Environments [draft-ietf-ipwave-problem-statement-00] (19 pages) - IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases [draft-ietf-ipwave-vehicular-networking-19] (39 pages) - Survey on IP-based Vehicular Networking for Intelligent Transportation Systems [draft-ietf-ipwave-vehicular-networking-survey-00] (37 pages) - Problem Statement for IP Wireless Access in Vehicular Environments [draft-jeong-ipwave-problem-statement-00] (18 pages) - Survey on IP-based Vehicular Networking for Intelligent Transportation Systems [draft-jeong-ipwave-vehicular-networking-survey-03] (34 pages) - Transmission of IPv6 Packets over IEEE 802.11 Outside the Context of a Basic Service Set (OCB) [draft-petrescu-ipv6-over-80211p-06] (40 pages) Requests for Comments: RFC8691: Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 (29 pages) JSON Mail Access Protocol (jmap) -------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bron Gondwana Jim Fenton Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: jmap@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Description of Working Group: The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, beginning with calendars and contacts. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. The contact work will begin with a JSON format for contact data based upon the work begun in draft-stepanek-jscontact, and in consultation with other users of contact data within the IETF and outside to build an extensible format. Where possible, this format will retain the ability to convert backwards and forwards to RFC6350 vCard format. This format will then be used as the basis of JMAP object types for contacts. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over WSS (WebSocket over TLS, RFC 6455). Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - JSON formats for representing contacts and groups of contacts (JSContact) - JMAP access to addressbooks using the JSContact format - Accessing JMAP over Websockets - Handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - Other extensions which the working group considers related to email and compatible with the constraints listed above Also within scope for this working group are informational documents for converting between JMAP data representation and other formats already in wide use which can be used to specify the same underlying data. Goals and Milestones: Aug 2020 - Submit JMAP Quotas document to the IESG Aug 2020 - Submit JMAP S/MIME signature validation document to the IESG Aug 2020 - Adopt a document for creating Blobs via JMAP method call Aug 2020 - Adopt a document for managing Sieve via JMAP Oct 2020 - Adopt a document for S/MIME key management and server side signing/encryption Oct 2020 - Adopt a document defining JMAP access to addressbooks Nov 2020 - Submit JMAP Calendars document to the IESG Nov 2020 - Submit document for Blobs via JMAP to the IESG Dec 2020 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Dec 2020 - Submit JSON Contact document to IESG Dec 2020 - Submit Sieve document to the IESG Done - Adopt a document for a JSON Contact format (after recharter) Done - Submit Message Disposition Notification document to the IESG Done - Adopt a document defining mappings between VCARD and JSContact Internet-Drafts: - JMAP for Calendars [draft-ietf-jmap-calendars-04] (45 pages) - The JSON Meta Application Protocol (JMAP) [draft-ietf-jmap-core-17] (90 pages) - JSContact: A JSON representation of contact data [draft-ietf-jmap-jscontact-02] (17 pages) - JSContact: Converting from and to vCard [draft-ietf-jmap-jscontact-vcard-01] (39 pages) - The JSON Meta Application Protocol (JMAP) for Mail [draft-ietf-jmap-mail-16] (108 pages) - Handling Message Disposition Notification with JMAP [draft-ietf-jmap-mdn-15] (13 pages) - JMAP for Quotas [draft-ietf-jmap-quotas-01] (10 pages) - JMAP for Sieve Scripts [draft-ietf-jmap-sieve-01] (20 pages) - S/MIME signature verification extension to JMAP [draft-ietf-jmap-smime-02] (8 pages) - A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket [draft-ietf-jmap-websocket-07] (13 pages) Requests for Comments: RFC8620: The JSON Meta Application Protocol (JMAP) (90 pages) RFC8621: The JSON Meta Application Protocol (JMAP) for Mail (108 pages) RFC8887: A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket (13 pages) JSON Path (jsonpath) -------------------- Charter Last Modified: 2020-10-23 Current Status: Active Chair: Tim Bray Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: jsonpath@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jsonpath Archive: https://mailarchive.ietf.org/arch/browse/jsonpath/ Description of Working Group: JSONPath is a syntax, originally based on the XML "XPath" design, which selects fields and values from a JSON document. It is used in a variety of applications which rely on JSON message formats. JSONPath was originally described by Stefan Goessner [1] but has never had an official specification of any kind, and the 39+ implementations, while mostly compatible, differ in certain behaviors. Note that while JSON Pointer (RFC 6901) is already standardised, it is designed to provide a reference to a single, specific part of a JSON document, whereas JSONPath provides the ability to query a document and potentially return multiple values. The WG will develop a standards-track JSONPath specification that is technically sound and complete, based on the common semantics and other aspects of existing implementations. Where there are differences, the working group will analyze those differences and make choices that rough consensus considers technically best, with an aim toward minimizing disruption among the different JSONPath implementations. Possible input documents are: * https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ * https://jsonpath-standard.github.io/internet-draft/ [1] https://goessner.net/articles/JsonPath/ Goals and Milestones: Jun 2021 - Standards Track document defining JSON Path to the IESG Internet-Drafts: No Requests for Comments Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2019-08-28 Current Status: Active Chair: Robbie Harwood Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Mar 2013 - draft-ietf-krb-wg-pkinit-alg-agility to IESG Mar 2013 - draft-ietf-kitten-sasl-oauth to IESG Apr 2013 - draft-ietf-krb-wg-iakerb to IESG Apr 2013 - draft-ietf-kitten-sasl-saml-ec to IESG May 2013 - draft-ietf-kitten-gssapi-extensions-iana to IESG May 2013 - draft-ietf-krb-wg-cammac 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 one or more items for GSS-API cred management Jul 2013 - Adopt work on better error reporting in the GSS-API 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 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) - 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) - 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) - 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) - 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) - SPAKE Pre-Authentication [draft-ietf-kitten-krb-spake-preauth-09] (37 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) - Best practices for password hashing and storage [draft-ietf-kitten-password-storage-00] (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-19] (34 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-00] (5 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) - 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) Lightweight Authenticated Key Exchange (lake) --------------------------------------------- Charter Last Modified: 2020-10-01 Current Status: Active Chairs: Mališa Vučinić Stephen Farrell Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: Problem Constrained environments using OSCORE in network environments such as NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key exchange (LAKE) that enables forward security. 'Lightweight' refers to: * resource consumption, measured by number of round-trips to complete, bytes on the wire, wall-clock time to complete, or power consumption * the amount of new code required on end systems which already have an OSCORE stack but the LAKE must still provide the security properties expected of IETF protocols, e.g., providing confidentiality protection, integrity protection, and authentication with strong work factor. Goals This working group is intended to be a narrowly focused activity intended to produce at most one LAKE for OSCORE usage and close. The working group will collaborate and coordinate with other IETF WGs such as ACE, CORE, 6TISCH, LPWAN, and LWIG to understand and validate the requirements and solution. draft-selander-ace-cose-ecdhe is a candidate starting point for the LAKE produced by the WG. Any work available from TLS or other WGs that satisfies the determined requirements will also be evaluated for suitability, but does not preclude the WG from freely selecting its preferred LAKE for OSCORE. Program of Work The deliverables of this WG are: 1. Design requirements of the lightweight authenticated key exchange protocol for OSCORE (this draft will not be published as an RFC but will be used to drive WG consensus on the deliverable (2)) 2. Specify a lightweight authenticated key exchange protocol suitable for use in constrained environments using OSCORE Goals and Milestones: Sep 2020 - solution document to IESG (if needed) Done - WGLC on requirements document Done - Adopt solution document or defer to existing external solution document Internet-Drafts: - Ephemeral Diffie-Hellman Over COSE (EDHOC) [draft-ietf-lake-edhoc-01] (58 pages) - Requirements for a Lightweight AKE for OSCORE [draft-ietf-lake-reqs-04] (25 pages) - Requirements for a Lightweight AKE for OSCORE [draft-selander-lake-reqs-04] (19 pages) No Requests for Comments Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Russ Housley Tim Hollebeek Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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. 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: Nov 2019 - Adopt a draft for short-lived certificate conventions Dec 2019 - Adopt a draft for header protection conventions Dec 2019 - Adopt a draft for CMP updates Dec 2019 - Adopt a draft for Lightweight CMP profile Nov 2020 - Short-lived certificate conventions sent to IESG for BCP publication Nov 2020 - CMP updates sent to IESG for standards track publication Nov 2020 - Lightweight CMP profile sent to IESG for informational publication Mar 2021 - Header protection conventions sent to IESG for standards track publication Internet-Drafts: - DNS Certification Authority Authorization (CAA) Resource Record [draft-hoffman-andrews-caa-simplification-03] (19 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-housley-lamps-cms-update-alg-id-protect-00] (8 pages) - Clarifications for Elliptic Curve Cryptography Subject Public Key Information [draft-ietf-lamps-5480-ku-clarifications-03] (3 pages) - CMP Algorithms [draft-ietf-lamps-cmp-algorithms-00] (13 pages) - CMP Updates [draft-ietf-lamps-cmp-updates-05] (48 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 Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-mix-with-psk-07] (31 pages) - Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) [draft-ietf-lamps-cms-shakes-18] (16 pages) - Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection [draft-ietf-lamps-cms-update-alg-id-protect-05] (8 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 S/MIME [draft-ietf-lamps-header-protection-00] (27 pages) - Problem Statement and Requirements for Header Protection [draft-ietf-lamps-header-protection-requirements-01] (24 pages) - Lightweight CMP Profile [draft-ietf-lamps-lightweight-cmp-profile-03] (81 pages) - OCSP Nonce Extension [draft-ietf-lamps-ocsp-nonce-05] (6 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) - 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) - DNS Certification Authority Authorization (CAA) Resource Record [draft-ietf-lamps-rfc6844bis-07] (17 pages) - Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 [draft-ietf-lamps-rfc7030est-clarify-10] (14 pages) - Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 [draft-richardson-lamps-rfc7030est-clarify-05] (10 pages) - Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information [draft-turner-5480-ku-clarifications-01] (3 pages) Requests for Comments: RFC8398: Internationalized Email Addresses in X.509 Certificates (12 pages) RFC8399: Internationalization Updates to RFC 5280 (9 pages) 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) Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2019-03-29 Current Status: Active Chairs: Joel M. Halpern Luigi Iannone Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Padma Pillay-Esnault Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Description of Working Group: The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The scope of the LISP technology is potentially applicable to have a large span, including unicast and multicast overlays at Layer 2 as well as at Layer 3, encompassing NAT traversal, VPNs, and supporting mobility as a general feature, independently of whether it is a mobile user or a migrating Virtual Machine (VM). Hence, the LISP technology is applicable in both Data Centers and public Internet environments. The LISP WG is chartered to continue work on the LISP base protocol and produce standard-track documents. In order to produce a coherent set of documents, the first (and high priority) work item of the LISP Working Group is to develop a standard-track solution based on the completed Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs and doing the necessary enhancements to support a base set of standards track RFCs. The group will review the current set of Working Group documents to identify potential standards-track documents and do the necessary enhancements to support standards-track. In parallel with the previous main work item, the LISP WG will work on the items listed below: - Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH (Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Groups such as NVO3 and SFC. - Alternative Mapping System Design: By extending LISP with new multi-protocols support, it becomes necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models, independent mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol). - Mobility: Some LISP deployment scenarios include mobile nodes (in mobile environments) or Virtual Machines (VMs in data centers), hence, support needs to be provided in order to achieve seamless connectivity. This work item may benefit from experience of other Working Groups like DMM (Distributed Mobility Management) or NVO3 (for VM migration). - Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. This may need discussion with other Working Groups related to multicast solutions (e.g. PIM). - Data-Plane Encryption: In some scenarios, it may be desirable to encrypt LISP encapsulated traffic. In this case, the data-plane encryption mechanism itself and support for control-plane security material exchange needs to be specified. Any solution proposed in this work item has to be reviewed by security experts. - NAT-Traversal: Support for NAT-traversal solution in deployments where LISP tunnel routers are separated from correspondent tunnel routers by a NAT (e.g., LISP mobile node). - Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components of standards-track documents. Similar to the main work item, documents for these work items will as well target standard-track unless the document is of a different maturity level (e.g., Informational or Experimental). In the latter case, the Working Group will evaluate the maturity level and propose a recommended track for the document. Collaboration with other working groups, as stated in the different work items (e.g., PIM, NVO3, DMM, SFC), is important to ensure to have technologies that work smoothly together. The LISP Working Group is chartered to work on the LISP technology. It may use technologies developed in other working groups, but if it identifies needs for extensions or modifications, those extensions and modifications will be addressed in the working groups that developed those technologies. The LISP Working Group may provide feedback to other working groups based on experience gained while using their solutions. Goals and Milestones: Aug 2016 - Submit a LISP control-plane security mechanism document to the IESG for consideration as Experimental Apr 2017 - Submit a LISP unicast data-plane specification (6830bis) document to the IESG for consideration as Proposed Standard Apr 2017 - Submit a LISP multicast data-plane specification (6831bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP control-plane specification (6833bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP interworking specification (6832bis) document to the IESG for consideration as Proposed Standard Jul 2017 - Submit a LISP Mobility document to the IESG for consideration as Proposed Standard Internet-Drafts: - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-boucadair-lisp-rfc8113bis-01] (5 pages) - An Architectural Perspective on the LISP Location-Identity Separation System [draft-chiappa-lisp-architecture-01] (19 pages) - An Introduction to the LISP Location-Identity Separation System [draft-chiappa-lisp-introduction-01] (29 pages) - LISP Configuration YANG Model [draft-ermagan-lisp-yang-01] (80 pages) - LISP Data-Plane Confidentiality [draft-farinacci-lisp-crypto-01] (10 pages) - LISP Control-Plane ECDSA Authentication and Authorization [draft-farinacci-lisp-ecdsa-auth-03] (17 pages) - LISP EID Anonymity [draft-farinacci-lisp-eid-anonymity-02] (9 pages) - LISP Geo-Coordinate Use-Cases [draft-farinacci-lisp-geo-10] (12 pages) - LISP Canonical Address Format (LCAF) [draft-farinacci-lisp-lcaf-10] (29 pages) - LISP Distinguished Name Encoding [draft-farinacci-lisp-name-encoding-10] (6 pages) - LISP Predictive RLOCs [draft-farinacci-lisp-predictive-rlocs-02] (13 pages) - LISP Traffic Engineering Use-Cases [draft-farinacci-lisp-te-12] (18 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-iannone-6834bis-00] (19 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-24] (75 pages) - Locator/ID Separation Protocol (LISP) Map-Versioning [draft-ietf-lisp-6834bis-07] (18 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-04] (17 pages) - LISP EID Anonymity [draft-ietf-lisp-eid-anonymity-09] (11 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-06] (26 pages) - LISP Generic Protocol Extension [draft-ietf-lisp-gpe-19] (16 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-13] (27 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) - 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-08] (24 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) - Network-Hexagons: H3-LISP GeoState & Mobility Network [draft-ietf-lisp-nexagon-06] (19 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-06] (15 pages) - Publish/Subscribe Functionality for LISP [draft-ietf-lisp-pubsub-06] (12 pages) - The Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-rfc6830bis-35] (47 pages) - Locator/ID Separation Protocol (LISP) Control-Plane [draft-ietf-lisp-rfc6833bis-29] (60 pages) - Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations [draft-ietf-lisp-rfc8113bis-03] (6 pages) - LISP-Security (LISP-SEC) [draft-ietf-lisp-sec-21] (27 pages) - Signal-Free Locator/ID Separation Protocol (LISP) Multicast [draft-ietf-lisp-signal-free-multicast-09] (21 pages) - LISP Traffic Engineering Use-Cases [draft-ietf-lisp-te-07] (18 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-07] (5 pages) - LISP Virtual Private Networks (VPNs) [draft-ietf-lisp-vpn-06] (17 pages) - LISP YANG Model [draft-ietf-lisp-yang-14] (79 pages) - LISP Mobile Node [draft-meyer-lisp-mn-16] (22 pages) - LISP Virtual Private Networks (VPNs) [draft-moreno-lisp-vpn-00] (16 pages) - LISP L2/L3 EID Mobility Using a Unified Control Plane [draft-portoles-lisp-eid-mobility-02] (23 pages) - Publish/Subscribe Functionality for LISP [draft-rodrigueznatal-lisp-pubsub-02] (10 pages) - Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00] (5 pages) - LISP Impact [draft-saucez-lisp-impact-07] (15 pages) Requests for Comments: RFC6830: The Locator/ID Separation Protocol (LISP) (75 pages) * Updates RFC8113 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) RFC6834: Locator/ID Separation Protocol (LISP) Map-Versioning (21 pages) 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) 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) RFC8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast (21 pages) IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Alexander Pelov Pascal Thubert Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Éric Vyncke Mailing Lists: General Discussion: lp-wan@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lp-wan Archive: https://mailarchive.ietf.org/arch/browse/lp-wan/ Description of Working Group: A new generation of wireless technologies has emerged under the generic name of Low-Power Wide-Area (LPWA), with a number of common characteristics, which make these technologies unique and disruptive for Internet of Things applications. Those common traits include an optimized radio modulation, a star topology, frame sizes in the order of tens of bytes transmitted a few times per day at ultra-low speeds and sometimes variable MTUs, and, though downstream may be supported, a mostly upstream transmission pattern that allows the devices to spend most of their time in low- energy deep-sleep mode. This enables a range of several kilometers and a long battery lifetime, possibly ten years operating on a single coin-cell. This also enables simple and scalable deployments with low-cost devices and thin infrastructures. Those benefits come at a price: the layer 2 frame formats are optimized and specific to each individual technology. There is no network layer and the application is often hard wired to the layer 2 frame format, leading to siloed deployments that must be managed, secured and operated individually. Migrating from one LPWA technology to another implies rebuilding the whole chain. There is a need to allow an integration of different LPWAN technologies in order to couple them with their related ecosystems. This will guarantee the inter-working by introducing a network layer, and enable common components for management and security, as well as shared application profiles. The IETF can contribute by providing IPv6 connectivity, and propose technologies to secure the operations and manage the devices and their gateways. The Working Group will focus on enabling IPv6 connectivity over the following selection of Low-Power Wide-Area technologies: SIGFOX, LoRa, WI-SUN and NB-IOT. These technologies will be used as the baseline technologies for future work. These technologies present similar characteristics of rare and widely unbalanced over-the-air transmissions, with little capability to alter the frame formats to accommodate this work, which makes it so that existing IETF work (6lo) cannot be trivially applied. The Working Group will leverage cross-participation with the associated set of stakeholders, including users and SDOs working on the baseline technologies, to ensure that the work taking place corresponds to real demands and that the proposed solutions are indeed applicable. The group has produced documents providing an overview of the baseline LPWA technologies (RFC8376) as well as a document specifying a Generic Framework for Static Context Header Compression and Fragmentation (SCHC), which provides both a header compression mechanism and an optional fragmentation mechanism (RFC8724). The group will continue to produce new standards track work to optimize IPv6-based communications to the end devices. The group will: 1. Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols. 2. Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline technologies. 3. Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs. 4. Produce a Standards Track document to enable  operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping). Goals and Milestones: May 2020 - Perform SCHC Maintenance, including enabling SCHC mechanisms for Upper layer Protocols Dec 2020 - Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline technologies Feb 2021 - Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs Jul 2021 - Produce a Standards Track document to enable operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping) Internet-Drafts: - LPWAN Static Context Header Compression (SCHC) for CoAP [draft-ietf-lpwan-coap-static-context-hc-16] (31 pages) - SCHC: Generic Framework for Static Context Header Compression and Fragmentation [draft-ietf-lpwan-ipv6-static-context-hc-24] (71 pages) - Low-Power Wide Area Network (LPWAN) Overview [draft-ietf-lpwan-overview-10] (43 pages) - Static Context Header Compression (SCHC) over LoRaWAN [draft-ietf-lpwan-schc-over-lorawan-12] (27 pages) - SCHC over NB-IoT [draft-ietf-lpwan-schc-over-nbiot-03] (23 pages) - SCHC over Sigfox LPWAN [draft-ietf-lpwan-schc-over-sigfox-03] (13 pages) - Data Model for Static Context Header Compression (SCHC) [draft-ietf-lpwan-schc-yang-data-model-03] (42 pages) Requests for Comments: RFC8376: Low-Power Wide Area Network (LPWAN) Overview (43 pages) RFC8724: SCHC: Generic Framework for Static Context Header Compression and Fragmentation (71 pages) Link State Routing (lsr) ------------------------ Charter Last Modified: 2018-11-01 Current Status: Active Chairs: Acee Lindem Christian Hopps Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Secretary: Yingzhen Qu Mailing Lists: General Discussion: lsr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsr Archive: https://mailarchive.ietf.org/arch/browse/lsr/ Description of Working Group: The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of the link-state interior gateway routing protocols (IGPs) - specifically IS-IS, OSPFv2, and OSPFv3. The LSR Working Group was formed by merging the isis and ospf WGs and assigning all their existing adopted work at the time of chartering to LSR. IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR-WG’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR-WG will interact with other standards bodies that have responsibility for standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for example TRILL work) as needed. OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director. In addition to ongoing maintenance, the following topics are specific work-items for the WG. 1) Improve OSPF support for IPv6 and create at least parity with IPv4 functionality by adding OSPFv3 extensions using the OSPFv3 Extended LSAs. 2) Extensions needed for Segment Routing and associated architectural changes 3) YANG models for the management of IS-IS, OSPFv2, and OSPFv3 and extensions 4) Extensions for source-destination routing 5) Improvements to flooding (and other behaviors) to better support dense meshed network topologies, such as are commonly used in data centers. The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, PCE, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs and is compatible with IS-IS and/or OSPF from functional, architectural and performance point of views. LSR-WG will coordinate with CCAMP, TEAS, and BIER on their extensions to the LSR IGPs as applicable to LSR protocol operation and scale. LSR-WG should coordinate with other WGs as needed. Goals and Milestones: Jul 2018 - OSPF YANG Model to IESG Jul 2018 - ISIS YANG model to IESG Jul 2018 - IS-IS Reverse Metric to IESG Jul 2018 - IS-IS Segment Routing MSD to IESG Nov 2018 - OSPFv3 SR to IESG Nov 2018 - OSPFv2 Attribute Agility Mar 2019 - OSPF Segment Routing YANG Model Mar 2019 - IS-IS Segment Routing SR YANG Model Jul 2019 - OSPFv3 Dual Stack (single instance) Internet-Drafts: - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-acee-lsr-ospf-yang-augmentation-v1-01] (23 pages) - YANG Model for OSPFv3 Extended LSAs [draft-acee-lsr-ospfv3-extended-lsa-yang-06] (30 pages) - IPv6 Source/Destination Routing using IS-IS [draft-baker-ipv6-isis-dst-src-routing-07] (12 pages) - ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-chen-lsr-isis-rfc5316bis-02] (20 pages) - Invalid TLV Handling in IS-IS [draft-ginsberg-lsr-isis-invalid-tlv-03] (8 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] (8 pages) - IS-IS Routing with Reverse Metric [draft-ietf-isis-reverse-metric-17] (15 pages) - IS-IS Extensions for Segment Routing [draft-ietf-isis-segment-routing-extensions-25] (28 pages) - Signaling Maximum SID Depth (MSD) Using IS-IS [draft-ietf-isis-segment-routing-msd-19] (10 pages) - YANG Data Model for IS-IS Segment Routing [draft-ietf-isis-sr-yang-08] (25 pages) - IS-IS Application-Specific Link Attributes [draft-ietf-isis-te-app-19] (20 pages) - YANG Data Model for IS-IS Protocol [draft-ietf-isis-yang-isis-cfg-42] (118 pages) - Dynamic Flooding on Dense Graphs [draft-ietf-lsr-dynamic-flooding-07] (47 pages) - IGP Flexible Algorithm [draft-ietf-lsr-flex-algo-13] (37 pages) - Flooding Topology Minimum Degree Algorithm [draft-ietf-lsr-flooding-topo-min-degree-00] (12 pages) - Area Proxy for IS-IS [draft-ietf-lsr-isis-area-proxy-04] (20 pages) - IS-IS Extended Hierarchy [draft-ietf-lsr-isis-extended-hierarchy-02] (19 pages) - IS-IS Flood Reflection [draft-ietf-lsr-isis-flood-reflection-01] (17 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 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 Extension to Support Segment Routing over IPv6 Dataplane [draft-ietf-lsr-isis-srv6-extensions-11] (25 pages) - IS-IS Topology-Transparent Zone [draft-ietf-lsr-isis-ttz-01] (21 pages) - OSPF Strict-Mode for BFD [draft-ietf-lsr-ospf-bfd-strict-mode-01] (10 pages) - OSPF Prefix Originator Extensions [draft-ietf-lsr-ospf-prefix-originator-07] (9 pages) - OSPF Reverse Metric [draft-ietf-lsr-ospf-reverse-metric-01] (12 pages) - OSPF YANG Model Augmentations for Additional Features - Version 1 [draft-ietf-lsr-ospf-yang-augmentation-v1-02] (30 pages) - YANG Model for OSPFv3 Extended LSAs [draft-ietf-lsr-ospfv3-extended-lsa-yang-07] (29 pages) - OSPFv3 Extensions for SRv6 [draft-ietf-lsr-ospfv3-srv6-extensions-01] (23 pages) - IGP extension for PCEP security capability support in the PCE discovery [draft-ietf-lsr-pce-discovery-security-support-04] (10 pages) - YANG Module for IS-IS Reverse Metric [draft-ietf-lsr-yang-isis-reverse-metric-01] (15 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] (9 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) - YANG Data Model for OSPF SR (Segment Routing) Protocol [draft-ietf-ospf-sr-yang-12] (25 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 OSPF Protocol [draft-ietf-ospf-yang-29] (132 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) - IS-IS Flood Reflection [draft-przygienda-lsr-flood-reflection-01] (17 pages) Requests for Comments: RFC8476: Signaling Maximum SID Depth (MSD) Using OSPF (11 pages) RFC8491: Signaling Maximum SID Depth (MSD) Using IS-IS (10 pages) RFC8500: IS-IS Routing with Reverse Metric (15 pages) RFC8510: OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement (8 pages) RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions (21 pages) RFC8666: OSPFv3 Extensions for Segment Routing (18 pages) RFC8667: IS-IS Extensions for Segment Routing (28 pages) RFC8687: OSPF Routing with Cross-Address Family Traffic Engineering Tunnels (8 pages) RFC8706: Restart Signaling for IS-IS (22 pages) RFC8770: Host Router Support for OSPFv2 (8 pages) RFC8918: Invalid TLV Handling in IS-IS (8 pages) RFC8919: IS-IS Application-Specific Link Attributes (20 pages) RFC8920: OSPF Application-Specific Link Attributes (19 pages) Link State Vector Routing (lsvr) -------------------------------- Charter Last Modified: 2018-02-23 Current Status: Active Chairs: Gunter Van de Velde Victor Kuarsingh Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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-07] (14 pages) - Shortest Path Routing Extensions for BGP Protocol [draft-ietf-lsvr-bgp-spf-11] (23 pages) - Layer 3 Discovery and Liveness [draft-ietf-lsvr-l3dl-06] (35 pages) - Layer 3 Discovery and Liveness Signing [draft-ietf-lsvr-l3dl-signing-00] (9 pages) - L3DL Upper Layer Protocol Configuration [draft-ietf-lsvr-l3dl-ulpc-00] (8 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 Light-Weight Implementation Guidance (lwig) ------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Mohit Sethi Zhen Cao Internet Area Directors: Erik Kline Éric Vyncke Internet Area Advisor: Erik Kline Mailing Lists: General Discussion: lwip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lwip Archive: https://mailarchive.ietf.org/arch/browse/lwip/ Description of Working Group: Communications technology is being embedded into our environment. Different types of devices in our buildings, vehicles, equipment and other objects have a need to communicate. It is expected that most of these devices will employ the Internet Protocol suite. However, there is a lot of variation in the capabilities between different types of devices, and it is not always easy to embed all the necessary features. The Light-Weight Implementation Guidance (LWIG) Working Group focuses on helping the implementors of the smallest devices. The goal is to be able to build minimal yet interoperable IP-capable devices for the most constrained environments. Building a small implementation does not have to be hard. Many small devices use stripped down versions of general purpose operating systems and their TCP/IP stacks. However, there are implementations that go even further in minimization and can exist in as few as a couple of kilobytes of code, as on some devices this level of optimization is necessary. Technical and cost considerations may limit the computing power, battery capacity, available memory, or communications bandwidth that can be provided. To overcome these limitations the implementors have to employ the right hardware and software mechanisms. For instance, certain types of memory management or even fixed memory allocation may be required. It is also useful to understand what is necessary from the point of view of the communications protocols and the application employing them. For instance, a device that only acts as a client or only requires one connection can simplify its TCP implementation. The purpose of the LWIG working group is to collect experiences from implementors of IP stacks in constrained devices. The group shall focus only on techniques that have been used in actual implementations and do not impact interoperability with other devices. The techniques shall also not affect conformance to the relevant specifications. The output of this work is a document that describes implementation techniques for reducing complexity, memory footprint, or power usage. The topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF protocols. This document will be helpful for the implementors of new devices or for the implementors of new general-purpose small IP stacks. It is also expected that the document increases our knowledge of what existing small implementations do, and helps in the further optimization of the existing implementations. On areas where the considerations for small implementations have already been documented the group shall make an effort to refer to those documents instead of developing its own. Generic hardware design advice and software implementation techniques are outside the scope of this work, as such expertise is not within the IETF domain. Protocol implementation experience, however, is within the IETF domain. The group shall also not develop any new protocols or protocol behavior modifications beyond what is already allowed by existing RFCs, because it is important to ensure that different types of devices can work together. The group shall not develop assumptions or profiles about the operating environment of the devices, because, in general, it is not possible to guarantee any special configuration. Finally, while implementation techniques relating to security mechanisms are within scope, mere removal of security functionality from a protocol is not an acceptable recommendation. Given that the group works on both IP and transport layer protocols it is necessary to ensure that expertise in both aspects is present in the group. Participation from the implementors of existing small IP stacks is also required. Goals and Milestones: Nov 2018 - Submit the CoAP implementation document to the IESG for publication as an Informational RFC Nov 2018 - Submit the TCP over constrained networks guidance document to the IESG for publication as an Informational RFC Nov 2018 - Submit the minimal ESP guidance document to the IESG for publication as an Informational RFC Done - Submit the terminology document to the IESG for publication as an Informational RFC Done - Submit the implementation guidance document to the IESG for publication as an Informational RFC Done - Submit the minimal IKEv2 implementation document to the IESG for publication as an Informational RFC Done - Submit the energy efficient implementation guidance document to the IESG for publication as an Informational RFC Done - Submit the lightweight crypto implementation document to the IESG for publication as an Informational RFC Internet-Drafts: - Virtual reassembly buffers in 6LoWPAN [draft-bormann-lwig-6lowpan-virtual-reassembly-00] (5 pages) - TCP over Constrained-Node Networks [draft-gomez-lwig-tcp-constrained-node-networks-03] (17 pages) - Virtual reassembly buffers in 6LoWPAN [draft-ietf-lwig-6lowpan-virtual-reassembly-02] (6 pages) - Building Power-Efficient CoAP Devices for Cellular Networks [draft-ietf-lwig-cellular-06] (16 pages) - CoAP Implementation Guidance [draft-ietf-lwig-coap-06] (31 pages) - Practical Considerations and Implementation Experiences in Securing Smart Object Networks [draft-ietf-lwig-crypto-sensors-06] (33 pages) - Alternative Elliptic Curve Representations [draft-ietf-lwig-curve-representations-12] (119 pages) - Energy-Efficient Features of Internet of Things Protocols [draft-ietf-lwig-energy-efficient-08] (24 pages) - Guidance for Light-Weight Implementations of the Internet Protocol Suite [draft-ietf-lwig-guidance-03] (34 pages) - Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation [draft-ietf-lwig-ikev2-minimal-05] (41 pages) - Minimal ESP [draft-ietf-lwig-minimal-esp-00] (13 pages) - Neighbor Management Policy for 6LoWPAN [draft-ietf-lwig-nbr-mgmt-policy-03] (20 pages) - Comparison of CoAP Security Protocols [draft-ietf-lwig-security-protocol-comparison-04] (40 pages) - TCP Usage Guidance in the Internet of Things (IoT) [draft-ietf-lwig-tcp-constrained-node-networks-11] (30 pages) - Terminology for Constrained-Node Networks [draft-ietf-lwig-terminology-07] (17 pages) - A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks [draft-ietf-lwig-tls-minimal-01] (15 pages) - Neighbor Management Policy for 6LoWPAN [draft-jadhav-lwig-nbr-mgmt-policy-01] (18 pages) - Minimal ESP [draft-mglt-lwig-minimal-esp-07] (13 pages) Requests for Comments: RFC7228: Terminology for Constrained-Node Networks (17 pages) RFC7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation (41 pages) RFC8352: Energy-Efficient Features of Internet of Things Protocols (24 pages) RFC8387: Practical Considerations and Implementation Experiences in Securing Smart Object Networks (33 pages) Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2019-11-20 Current Status: Active Chair: Ronald in 't Velt Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Mailing Lists: General Discussion: manet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/manet Archive: https://mailarchive.ietf.org/arch/browse/manet/ Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing applications within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. The WG will put special attention on the standardization of a bidirectional, dynamic link exchange protocol (DLEP) between the router and the modem. The MANET WG will coordinate with other Working Groups, such as the pim WG for multicast support, the Routing Area WG (rtgwg), OSPF WG and Babel WG on the general use of DLEP, as well as the IPPM WG on topics related to traffic classification. The MANET WG is responsible for the maintenance of OLSRv2 [RFC 7181], NHDP [RFC 6130] and the Generalized MANET Packet/Message Format [RFC5444], and their extensions. Work Items: - Develop a dynamic link exchange protocol (DLEP). - DLEP extension to provide a credit-windowing scheme for destination-specific flow control. - DLEP extensions for reporting statistics by traffic classification. - Multicast MANET protocol framework based on Simplified Multicast Forwarding [RFC 6621] for scoped forwarding within MANET networks. As part of this framework the WG will produce a well defined MANET multicast forwarding information base (FIB). - Document outlining challenges and best practices for deploying and managing MANET networks. Goals and Milestones: Nov 2016 - MANET Management Document (Informational) Nov 2016 - DLEP Credit Windowing Extensions (Standards Track) Nov 2016 - DLEP (Standards Track) Jul 2017 - DLEP traffic extensions (Standards Track) Nov 2017 - Multicast FIB (Standards Track) Internet-Drafts: - Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) [draft-clausen-manet-olsrv2-sec-threats-01] (24 pages) - Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format [draft-clausen-manet-rfc5444-usage-00] (17 pages) - Link Identifier Extension to DLEP [draft-dlep-lid-02] (7 pages) - The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks (ADMR) [draft-ietf-manet-admr-01] (63 pages) - Ad hoc Multicast Routing protocol utilizing Increasing id-numberS (AMRIS) Functional Specification [draft-ietf-manet-amris-spec-00] (23 pages) - Ad hoc On-Demand Distance Vector (AODV) Routing [draft-ietf-manet-aodv-13] (37 pages) - Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing [draft-ietf-manet-aodvv2-16] (84 pages) - MANET Routing Protocol Applicability Statement [draft-ietf-manet-appl-00] (3 pages) - IP Flooding in Ad hoc Mobile Networks [draft-ietf-manet-bcast-00] (0 pages) - Cluster Based Routing Protocol(CBRP) Functional Specification [draft-ietf-manet-cbrp-spec-01] (27 pages) - Core Extraction Distributed Ad hoc Routing (CEDAR) Specification [draft-ietf-manet-cedar-spec-00] (29 pages) - Credit Windowing extension for DLEP [draft-ietf-manet-credit-window-07] (13 pages) - Differential Destination Multicast (DDM) Specification [draft-ietf-manet-ddm-00] (21 pages) - Dynamic Link Exchange Protocol (DLEP) [draft-ietf-manet-dlep-29] (82 pages) - DLEP Credit-Based Flow Control Messages and Data Items [draft-ietf-manet-dlep-credit-flow-control-06] (18 pages) - DLEP DiffServ Aware Credit Window Extension [draft-ietf-manet-dlep-da-credit-extension-09] (6 pages) - Dynamic Link Exchange Protocol (DLEP) Latency Range Extension [draft-ietf-manet-dlep-latency-extension-05] (5 pages) - Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension [draft-ietf-manet-dlep-lid-extension-06] (9 pages) - Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension [draft-ietf-manet-dlep-multi-hop-extension-07] (10 pages) - Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension [draft-ietf-manet-dlep-pause-extension-08] (12 pages) - DLEP Traffic Classification Data Item [draft-ietf-manet-dlep-traffic-classification-03] (13 pages) - The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 [draft-ietf-manet-dsr-10] (107 pages) - Flow State in the Dynamic Source Routing Protocol for Mobile Ad Hoc Networks [draft-ietf-manet-dsrflow-00] (30 pages) - Dynamic MANET On-demand (AODVv2) Routing [draft-ietf-manet-dymo-26] (60 pages) - Definition of Managed Objects for the DYMO Manet Routing Protocol [draft-ietf-manet-dymo-mib-04] (41 pages) - Fisheye State Routing Protocol (FSR) for Ad Hoc Networks [draft-ietf-manet-fsr-03] (17 pages) - IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols [draft-ietf-manet-iana-07] (5 pages) - Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols [draft-ietf-manet-ibs-05] (17 pages) - An Internet MANET Encapsulation Protocol (IMEP) Specification [draft-ietf-manet-imep-spec-01] (37 pages) - INSIGNIA [draft-ietf-manet-insignia-01] (22 pages) - Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations [draft-ietf-manet-issues-02] (12 pages) - Jitter Considerations in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-jitter-04] (12 pages) - Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks [draft-ietf-manet-lanmar-05] (21 pages) - Long-lived Ad Hoc Routing based on the Concept of Associativity [draft-ietf-manet-longlived-adhoc-routing-00] (18 pages) - Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing [draft-ietf-manet-maodv-00] (24 pages) - Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-15] (88 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-nhdp-mib-19] (67 pages) - Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-nhdp-olsrv2-sec-05] (15 pages) - Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs [draft-ietf-manet-nhdp-olsrv2-tlv-extension-05] (16 pages) - An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-optimization-04] (9 pages) - Using Integrity Check Values and Timestamps For Router Admittance in NHDP [draft-ietf-manet-nhdp-sec-02] (12 pages) - Security Threats for the Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-sec-threats-06] (20 pages) - On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks [draft-ietf-manet-odmrp-04] (29 pages) - Optimized Link State Routing Protocol (OLSR) [draft-ietf-manet-olsr-11] (75 pages) - The Optimized Link State Routing Protocol Version 2 [draft-ietf-manet-olsrv2-19] (115 pages) - Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-dat-metric-12] (21 pages) - Snapshot of OLSRv2-Routed MANET Management [draft-ietf-manet-olsrv2-management-snapshot-03] (14 pages) - Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale [draft-ietf-manet-olsrv2-metrics-rationale-04] (25 pages) - Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 [draft-ietf-manet-olsrv2-mib-12] (86 pages) - Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-multipath-15] (26 pages) - Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-multitopology-07] (23 pages) - Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-rmpr-optimization-01] (5 pages) - Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) [draft-ietf-manet-olsrv2-sec-threats-04] (26 pages) - Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format [draft-ietf-manet-packetbb-17] (60 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-packetbb-sec-09] (21 pages) - Relative Distance Micro-discovery Ad Hoc Routing (RDMAR) Protocol [draft-ietf-manet-rdmar-00] (15 pages) - Definition of Managed Objects for Performance Reporting [draft-ietf-manet-report-mib-04] (35 pages) - Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 [draft-ietf-manet-rfc5444-usage-07] (29 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-rfc6622-bis-06] (31 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-rfc6779bis-07] (72 pages) - A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks [draft-ietf-manet-simple-mbcast-01] (11 pages) - Simplified Multicast Forwarding [draft-ietf-manet-smf-14] (55 pages) - Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process [draft-ietf-manet-smf-mib-13] (65 pages) - Security Threats to Simplified Multicast Forwarding (SMF) [draft-ietf-manet-smf-sec-threats-06] (15 pages) - SOURCE TREE ADAPTIVE ROUTING (STAR) PROTOCOL [draft-ietf-manet-star-00] (26 pages) - Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) [draft-ietf-manet-tbrpf-11] (46 pages) - Mobile Ad Hoc Networking Terminology [draft-ietf-manet-term-01] (9 pages) - Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-timetlv-08] (14 pages) - TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format [draft-ietf-manet-tlv-naming-05] (15 pages) - Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification [draft-ietf-manet-tora-spec-04] (23 pages) - The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks [draft-ietf-manet-zone-brp-02] (13 pages) - The Intrazone Routing Protocol (IARP) for Ad Hoc Networks [draft-ietf-manet-zone-iarp-02] (11 pages) - The Interzone Routing Protocol (IERP) for Ad Hoc Networks [draft-ietf-manet-zone-ierp-02] (14 pages) - The Zone Routing Protocol (ZRP) for Ad Hoc Networks [draft-ietf-manet-zone-zrp-04] (11 pages) - AMRoute: Adhoc Multicast Routing Protocol [draft-talpade-manet-amroute-00] (24 pages) Requests for Comments: RFC2501: Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (12 pages) RFC3561: Ad hoc On-Demand Distance Vector (AODV) Routing (37 pages) RFC3626: Optimized Link State Routing Protocol (OLSR) (75 pages) RFC3684: Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (46 pages) 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 RFC7188 * Updates RFC7183 * 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 RFC7188 * Updates RFC7187 * Updates RFC7183 * 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: 2020-09-16 Current Status: Active Chairs: Christopher A. Wood Eric Kinnear Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke 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. In contrast, HTTP/3 is a viable candidate protocol for proxying arbitrary traffic, as in a single connection it provides secure connectivity, multiplexed streams, address migration, and a unified congestion controller. An HTTP/3 datagram construct built on top of QUIC datagram frames would provide for unreliable data transmission and enable transporting UDP and other unreliable flows via a proxy. Moreover, it would not introduce potentially redundant or unnecessary recovery mechanisms. Lastly, HTTP supports an established request/response semantic that can set up and configure flows for different services. 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 HTTPS connection. These mechanism(s) are collectively called MASQUE. The group will specify HTTP and/or HTTP/3 extensions to enable this functionality. The group will focus on a limited set of client-initiated services: (1) UDP CONNECT and (2) IP proxying. Server-initiated services are out of scope. The working group will first deliver a protocol solution for UDP CONNECT and a requirements document for IP proxying. Once both are complete, the working group will focus on a protocol solution for IP proxying. The working group will consider fallback to versions of HTTPS that operate over TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE, and may issue recommendations accordingly. New congestion control and loss recovery algorithms are out of scope. Multicast support is out of scope. However, the group may specify extension points that would enable future work on multicast. Specifying proxy server discovery mechanisms is also out of scope. However, the group may consider features, such as proxy server identifiers, that aid future discovery mechanisms. 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 TSVWG on congestion control and loss recovery considerations, and intarea for IP Proxying. Goals and Milestones: - Submit a standards track UDP CONNECT document - Submit an informational IP Proxying over MASQUE document Internet-Drafts: - Requirements for a MASQUE Protocol to Proxy IP Traffic [draft-cms-masque-ip-proxy-reqs-01] (10 pages) - The CONNECT-UDP HTTP Method [draft-ietf-masque-connect-udp-00] (8 pages) - Requirements for a MASQUE Protocol to Proxy IP Traffic [draft-ietf-masque-ip-proxy-reqs-00] (10 pages) - The CONNECT-UDP HTTP Method [draft-schinazi-masque-connect-udp-00] (7 pages) No Requests for Comments MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2017-03-29 Current Status: Active Chairs: Greg Shepherd Leonard Giuliano Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Tech Advisor: Scott Bradner Mailing Lists: General Discussion: mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: https://mailarchive.ietf.org/arch/browse/mboned/ Description of Working Group: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet, inter-domain and single domain. This activity will include, but not be limited to: - Document deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Analyze the need for IPv4 - IPv6 multicast transition solutions - Develop tools, extend protocols and provide operational and implementation advice that assists in multicast administration, diagnostics, troubleshooting and deployment between/within native and non-native environments. - Development of routing and group membership protocols is out of scope. This working group may develop requirements and assist in review and feedback of documents in other working groups responsible for such protocols. Goals and Milestones: Jan 2014 - Submit Mtracev2 to IESG for Proposed Standards Mar 2014 - Work with TSV area to submit multicast transport guidelines for congestion control Mar 2014 - Submit Overview of Multicast in the Data Center to IESG for Informational Internet-Drafts: - IPv6 Multicast Address With Embedded IPv4 Multicast Address [draft-ietf-mboned-64-multicast-address-format-06] (12 pages) - Overview of the Internet Multicast Addressing Architecture [draft-ietf-mboned-addrarch-07] (14 pages) - Lightweight Multicast Address Discovery Problem Space [draft-ietf-mboned-addrdisc-problems-02] (11 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-admin-ip-space-05] (8 pages) - Asymmetric Manifest Based Integrity [draft-ietf-mboned-ambi-00] (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-00] (15 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-00] (17 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-12] (27 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 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 YANG Data Model [draft-ietf-mboned-multicast-yang-model-03] (35 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) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171-update-00] (9 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171bis-08] (11 pages) - Overview of the Internet Multicast Routing Architecture [draft-ietf-mboned-routingarch-12] (25 pages) - Scoped Address Discovery Protocol (SADP) [draft-ietf-mboned-sadp-02] (14 pages) - Requirements for IP Multicast Session Announcement [draft-ietf-mboned-session-announcement-req-03] (14 pages) - The Use of SNTP as a Multicast Heartbeat [draft-ietf-mboned-sntp-heart-00] (8 pages) - Source-Specific Protocol Independent Multicast in 232/8 [draft-ietf-mboned-ssm232-09] (7 pages) - Multicast Ping Protocol [draft-ietf-mboned-ssmping-09] (24 pages) - Static Allocations in 233/8 [draft-ietf-mboned-static-allocation-00] (5 pages) - IPv4-IPv6 Multicast: Problem Statement and Use Cases [draft-ietf-mboned-v4v6-mcast-ps-04] (20 pages) - Asymmetric Manifest Based Integrity [draft-jholland-mboned-ambi-05] (22 pages) - Circuit Breaker Assisted Congestion Control [draft-jholland-mboned-cbacc-01] (15 pages) - Discovery Of Restconf Metadata for Source-specific multicast [draft-jholland-mboned-dorms-02] (17 pages) - Multicasting Applications Across Inter-Domain Peering Points [draft-tarapore-mboned-multicast-cdni-07] (27 pages) Requests for Comments: BCP120: Source-Specific Protocol Independent Multicast in 232/8 (7 pages) BCP121: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (14 pages) BCP213: Use of Multicast across Inter-domain Peering Points (44 pages) BCP229: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast (14 pages) BCP23: Administratively Scoped IP Multicast (8 pages) BCP51: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) BCP53: GLOP Addressing in 233/8 (5 pages) RFC2365: Administratively Scoped IP Multicast (8 pages) RFC2588: IP Multicast and Firewalls (12 pages) RFC2770: GLOP Addressing in 233/8 (5 pages) * Obsoletes RFC3180 RFC2776: Multicast-Scope Zone Announcement Protocol (MZAP) (27 pages) RFC3138: Extended Assignments in 233/8 (4 pages) * Obsoletes RFC5771 RFC3170: IP Multicast Applications: Challenges and Solutions (28 pages) RFC3171: IANA Guidelines for IPv4 Multicast Address Assignments (8 pages) * Obsoletes RFC5771 RFC3180: GLOP Addressing in 233/8 (5 pages) RFC3446: Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) (7 pages) RFC3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (18 pages) * Updates RFC7371 RFC4608: Source-Specific Protocol Independent Multicast in 232/8 (7 pages) RFC4609: Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements (23 pages) RFC4611: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (14 pages) RFC4624: Multicast Source Discovery Protocol (MSDP) MIB (32 pages) RFC5110: Overview of the Internet Multicast Routing Architecture (25 pages) RFC5132: IP Multicast MIB (59 pages) RFC5771: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) RFC5790: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols (17 pages) RFC6034: Unicast-Prefix-Based IPv4 Multicast Addresses (5 pages) RFC6308: Overview of the Internet Multicast Addressing Architecture (14 pages) RFC6450: Multicast Ping Protocol (24 pages) RFC6676: Multicast Addresses for Documentation (7 pages) RFC7450: Automatic Multicast Tunneling (82 pages) * Updates RFC8777 RFC8313: Use of Multicast across Inter-domain Peering Points (44 pages) RFC8487: Mtrace Version 2: Traceroute Facility for IP Multicast (41 pages) RFC8777: DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery (33 pages) RFC8815: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast (14 pages) Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Last Modified: 2020-05-05 Current Status: Active Chairs: Nancy Cam-Winget Takeshi Takahashi Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Murray Kucherawy Secretary: David Waltermire Mailing Lists: General Discussion: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: https://mailarchive.ietf.org/arch/browse/mile/ Description of Working Group: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third-party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The MILE WG is focused on two areas: standardizing a data format for representing incident and indicator data, and standardizing how application-level protocols such as HTTPS and XMPP become substrates for sharing the structured data. With respect to the data format, the working group has adopted the Incident Object Description Exchange Format (IODEF, RFC 7970) as one exchange format and will continue to: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience. Use by the Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs). In addition, the Multinational Alliance for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified and continue to develop data representations relevant to their use cases that may compliment/extend IODEF. - Provide guidance on the implementation and use of IODEF to facilitate interoperability. Though the working group also adopted Real-time Inter-network Defense (RID, RFC 6545) as further enabling information exchange of security policy, its transport mechanism, based on the Simple Object Access Protocol (SOAP), led to the second focus for MILE: adopting more modern transport through the adoption of a RESTful interface through ROLIE (Resource-oriented lightweight information exchange, RFC 8322) and the adoption of a publish-subscribe model through XMPP-Grid (draft-ietf-mile-xmpp-grid). The MILE WG will continue to: - Update and enhance these application-level substrate protocols to optimize their performance and representations. More explicitly, documenting how ROLIE can transport JSON representations. - Define and document how these application-level substrate protocols can also be used to support other security information exchange formats. For example, documenting how ROLIE can transport STIX (Structured Threat Information Expression) data. As STIX is a expression format defined by the OASIS consortium, the working group will maintain a relationship with OASIS to ensure proper use, compatibility and interoperability when using STIX. Goals and Milestones: Apr 2019 - Submit a draft on RESTful indicator exchange for CSIRT usage as an Informational RFC Apr 2019 - Submit a draft on JSON bindings of IODEF to the IESG for publication as a Standards Track RFC Apr 2019 - Submit a draft on ROLIE vulnerability extension as an Informational RFC Done - Submit a draft on XMPP Protocol Extensions for Use with IODEF Internet-Drafts: - XMPP Protocol Extensions for Use with IODEF [draft-appala-mile-xmpp-grid-00] (45 pages) - Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) [draft-ietf-mile-enum-reference-format-14] (10 pages) - GRC Report Exchange [draft-ietf-mile-grc-exchange-01] (68 pages) - Management Incident Lightweight Exchange (MILE) Implementation Report [draft-ietf-mile-implementreport-10] (16 pages) - Incident Object Description Exchange Format Usage Guidance [draft-ietf-mile-iodef-guidance-11] (33 pages) - Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry [draft-ietf-mile-iodef-xmlreg-01] (3 pages) - JSON Binding of the Incident Object Description Exchange Format [draft-ietf-mile-jsoniodef-14] (88 pages) - The Incident Object Description Exchange Format Version 2 [draft-ietf-mile-rfc5070-bis-26] (172 pages) - Real-time Inter-network Defense (RID) [draft-ietf-mile-rfc6045-bis-11] (84 pages) - Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [draft-ietf-mile-rfc6046-bis-09] (8 pages) - Resource-Oriented Lightweight Information Exchange (ROLIE) [draft-ietf-mile-rolie-16] (43 pages) - Definition of ROLIE CSIRT Extension [draft-ietf-mile-rolie-csirt-06] (16 pages) - Definition of the ROLIE Vulnerability Extension [draft-ietf-mile-rolie-vuln-03] (8 pages) - An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information [draft-ietf-mile-sci-13] (28 pages) - Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) [draft-ietf-mile-template-05] (12 pages) - Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange [draft-ietf-mile-xmpp-grid-11] (28 pages) Requests for Comments: RFC6545: Real-time Inter-network Defense (RID) (84 pages) RFC6546: Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS (8 pages) RFC6684: Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) (12 pages) RFC6685: Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry (3 pages) * Obsoletes RFC7970 RFC7203: An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information (28 pages) RFC7495: Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) (10 pages) RFC7970: The Incident Object Description Exchange Format Version 2 (172 pages) RFC8134: Management Incident Lightweight Exchange (MILE) Implementation Report (16 pages) RFC8274: Incident Object Description Exchange Format Usage Guidance (33 pages) RFC8322: Resource-Oriented Lightweight Information Exchange (ROLIE) (43 pages) RFC8600: Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange (28 pages) RFC8727: JSON Binding of the Incident Object Description Exchange Format (88 pages) Messaging Layer Security (mls) ------------------------------ Charter Last Modified: 2019-01-14 Current Status: Active Chairs: Nick Sullivan Sean Turner Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk 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: May 2018 - Initial working group documents for architecture and key management Sep 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational Jun 2019 - Submit key management protocol to IESG as Proposed Standard Sep 2019 - 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-05] (19 pages) - The Messaging Layer Security (MLS) Federation [draft-ietf-mls-federation-00] (8 pages) - The Messaging Layer Security (MLS) Protocol [draft-ietf-mls-protocol-09] (73 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) No Requests for Comments Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Bo Burman Flemming Andreasen Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: mmusic@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mmusic Archive: https://mailarchive.ietf.org/arch/browse/mmusic/ Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was originally chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployment. Currently, the group is focused on using and negotiating media streams with the Session Description Protocol (SDP), which is used as a common protocol to express media and session descriptions. The group also maintains the Real-time Streaming Protocol (RTSP) specifications. The group has revised these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVTCORE, CLUE, ICE, and RTCWEB). In particular, the many uses of SDP have led to requests for numerous extensions as well as a recognition of several limitations in the original protocol design. Today, the SDP protocol is widely deployed and continues to see extensions being defined. The current aims of the working group include the following: - Provide SDP signaling support for the Interactive Connectivity Establishment (ICE) protocol and its extensions. These were originally defined in MMUSIC, but are now handled by the ICE WG. - To support the establishment of multi-party multimedia sessions for RTCWEB based implementations, MMUSIC provides SDP signaling support for a number of extensions required by RTCWEB. The MMUSIC WG will seek a balanced trade-off between general applicability of such extensions versus RTCWEB specific usage. - Various other extensions to SDP may be pursued to remedy the most urgent of SDP's shortcomings. These include updates to the SDP specification itself and missing IANA registrations. - With the exception of the items listed above, only extensions within the existing SDP framework will be done. - Maintain the specification of the (revised) Real Time Streaming Protocol (RTSP) as needed. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVTCORE, CLUE, ICE, RTCWEB and SIPCORE, as well as others where appropriate. Goals and Milestones: Done - Submit a framework for SDP attributes when multiplexing as Proposed Standard Done - Submit IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles as Proposed Standard Done - Submit SDP extension for cross session stream identification as Proposed Standard Done - Submit Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP as Proposed Standard Done - Submit SCTP-Based Media Transport in SDP as Proposed Standard. Done - Using the SDP Offer/Answer Mechanism for DTLS Done - Submit RTP Payload Format Constraints as Proposed Standard Done - Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard Done - Submit SIP usage for Trickle ICE as Proposed Standard Done - Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard Done - Submit revised SDP specification to IETF as Proposed Standard Done - Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard Done - Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard Done - Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Proposed Standard Done - Submit T.140 Real-time Text Conversation over WebRTC Data Channels as Proposed Standard Done - Submit SDP Negotiation of MSRP over Data Channels as Proposed Standard Internet-Drafts: - T.140 Real-time Text Conversation over WebRTC Data Channels [draft-holmberg-mmusic-t140-usage-data-channel-02] (16 pages) - Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile [draft-hutton-mmusic-opportunistic-negotiation-00] (6 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-4572-update-13] (18 pages) - Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism [draft-ietf-mmusic-agree-00] (29 pages) - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-anat-02] (7 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-comedia-tls-06] (17 pages) - The Internet Multimedia Conferencing Architecture [draft-ietf-mmusic-confarch-03] (28 pages) - Connection-Establishment Preconditions in the Session Initiation Protocol (SIP) [draft-ietf-mmusic-connection-precon-01] (8 pages) - Connectivity Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-connectivity-precon-07] (17 pages) - SDP-based Data Channel Negotiation [draft-ietf-mmusic-data-channel-sdpneg-28] (40 pages) - Signaling Media Decoding Dependency in the Session Description Protocol (SDP) [draft-ietf-mmusic-decoding-dependency-08] (18 pages) - Duplication Delay Attribute in the Session Description Protocol [draft-ietf-mmusic-delayed-duplication-03] (11 pages) - Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) [draft-ietf-mmusic-dtls-sdp-32] (27 pages) - Duplication Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-duplication-grouping-04] (10 pages) - Forward Error Correction Grouping Semantics in Session Description Protocol [draft-ietf-mmusic-fec-grouping-05] (6 pages) - Grouping of Media Lines in the Session Description Protocol (SDP) [draft-ietf-mmusic-fid-06] (11 pages) - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer [draft-ietf-mmusic-file-transfer-mech-11] (50 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols [draft-ietf-mmusic-ice-19] (117 pages) - ICE Multihomed and IPv4/IPv6 Dual Stack Fairness [draft-ietf-mmusic-ice-dualstack-fairness-02] (10 pages) - IANA Registry for Interactive Connectivity Establishment (ICE) Options [draft-ietf-mmusic-ice-options-registry-02] (5 pages) - Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-sip-sdp-39] (43 pages) - TCP Candidates with Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-tcp-16] (29 pages) - Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-image-attributes-11] (23 pages) - A Framework for the Usage of Internet Media Guides (IMGs) [draft-ietf-mmusic-img-framework-09] (22 pages) - Requirements for Internet Media Guides (IMGs) [draft-ietf-mmusic-img-req-08] (23 pages) - Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-kmgmt-ext-15] (30 pages) - Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication [draft-ietf-mmusic-latching-08] (16 pages) - An Mbus Profile for Call Control [draft-ietf-mmusic-mbus-call-control-00] (37 pages) - The Message Bus: Guidelines for Application Profile Writers [draft-ietf-mmusic-mbus-guidelines-00] (49 pages) - Requirements for Local Conference Control [draft-ietf-mmusic-mbus-req-00] (10 pages) - A Message Bus for Local Coordination [draft-ietf-mmusic-mbus-transport-06] (39 pages) - Using Multicast DNS to protect privacy when exposing ICE candidates [draft-ietf-mmusic-mdns-ice-candidates-00] (18 pages) - An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback [draft-ietf-mmusic-media-loopback-27] (33 pages) - Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path [draft-ietf-mmusic-media-path-middleboxes-07] (20 pages) - WebRTC MediaStream Identification in the Session Description Protocol [draft-ietf-mmusic-msid-17] (19 pages) - MSRP over Data Channels [draft-ietf-mmusic-msrp-usage-data-channel-24] (20 pages) - Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP [draft-ietf-mmusic-mux-exclusive-12] (14 pages) - Short term NAT requirements for UDP based peer-to-peer applications [draft-ietf-mmusic-natreq4udp-00] (6 pages) - Session Description Protocol (SDP) Offer/Answer Examples [draft-ietf-mmusic-offer-answer-examples-06] (24 pages) - Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile [draft-ietf-mmusic-opportunistic-negotiation-01] (7 pages) - SDP attribute to signal parallax [draft-ietf-mmusic-parallax-attribute-00] (15 pages) - Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles [draft-ietf-mmusic-proto-iana-registration-06] (7 pages) - Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) [draft-ietf-mmusic-qos-identification-03] (9 pages) - Mapping of Media Streams to Resource Reservation Flows [draft-ietf-mmusic-reservation-flows-01] (6 pages) - Real-Time Streaming Protocol Version 2.0 [draft-ietf-mmusic-rfc2326bis-40] (318 pages) - The Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-rfc3388bis-04] (21 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-rfc4566bis-37] (63 pages) - Forward Error Correction Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-rfc4756bis-10] (14 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal [draft-ietf-mmusic-rfc5245bis-05] (91 pages) - RTP Payload Format Restrictions [draft-ietf-mmusic-rid-15] (28 pages) - Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-08] (92 pages) - RTSP Announce Method [draft-ietf-mmusic-rtsp-announce-01] (0 pages) - A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-22] (33 pages) - Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-evaluation-16] (46 pages) - SAP: Session Announcement Protocol [draft-ietf-mmusic-sap-00] (14 pages) - SAP Security Using Public Key Algorithms [draft-ietf-mmusic-sap-sec-04] (18 pages) - Session Announcement Protocol [draft-ietf-mmusic-sap-v2-06] (18 pages) - Simple Conference Control Protocol [draft-ietf-mmusic-sccp-01] (24 pages) - Simple Conference Invitation Protocol [draft-ietf-mmusic-scip-00] (18 pages) - Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. [draft-ietf-mmusic-sctp-sdp-26] (26 pages) - Session Description Protocol (SDP) Security Descriptions for Media Streams [draft-ietf-mmusic-sdescriptions-12] (44 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-06] (42 pages) - Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections [draft-ietf-mmusic-sdp-atm-05] (110 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-mmusic-sdp-bfcp-03] (12 pages) - Negotiating Media Multiplexing Using the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bundle-negotiation-54] (69 pages) - A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bwparam-06] (22 pages) - Session Description Protocol (SDP) Capability Negotiation [draft-ietf-mmusic-sdp-capability-negotiation-13] (77 pages) - SDP Capability Negotiation: Requirements and Review of Existing Work [draft-ietf-mmusic-sdp-capability-negotiation-reqts-01] (23 pages) - TCP-Based Media Transport in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-comedia-10] (15 pages) - Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) [draft-ietf-mmusic-sdp-cs-23] (39 pages) - Describing session directories in SDP [draft-ietf-mmusic-sdp-directory-type-02] (0 pages) - Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-sdp-dtls-00] (8 pages) - Offer/Answer Considerations for G.723 Annex A and G.729 Annex B [draft-ietf-mmusic-sdp-g273-g729-00] (8 pages) - Offer/Answer Considerations for G723 Annex A and G729 Annex B [draft-ietf-mmusic-sdp-g723-g729-06] (8 pages) - Implementation Status Of SDP [draft-ietf-mmusic-sdp-implem-00] (18 pages) - Support for IPv6 in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-ipv6-03] (5 pages) - Session Description Protocol (SDP) Media Capabilities Negotiation [draft-ietf-mmusic-sdp-media-capabilities-17] (55 pages) - The Session Description Protocol (SDP) Content Attribute [draft-ietf-mmusic-sdp-media-content-06] (11 pages) - The Session Description Protocol (SDP) Label Attribute [draft-ietf-mmusic-sdp-media-label-01] (8 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-misc-cap-00] (17 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-miscellaneous-caps-07] (22 pages) - A Framework for SDP Attributes when Multiplexing [draft-ietf-mmusic-sdp-mux-attributes-19] (97 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-new-26] (49 pages) - An Offer/Answer Model with Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-offer-answer-02] (25 pages) - Establishing QoS and Security Preconditions for SDP Sessions [draft-ietf-mmusic-sdp-qos-00] (13 pages) - Using Simulcast in SDP and RTP Sessions [draft-ietf-mmusic-sdp-simulcast-14] (41 pages) - Source-Specific Media Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-source-attributes-02] (18 pages) - Session Description Protocol (SDP) Source Filters [draft-ietf-mmusic-sdp-srcfilter-10] (14 pages) - SDP Extensions for Fax over IP Using T.38 [draft-ietf-mmusic-sdp-t38-00] (4 pages) - TCP-Based Media Transport in SDP [draft-ietf-mmusic-sdp-tcpmedia-00] (9 pages) - Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-uks-07] (19 pages) - Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp4nat-05] (8 pages) - Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-08] (61 pages) - Requirements for Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-req-01] (24 pages) - SDPng Transition [draft-ietf-mmusic-sdpng-trans-04] (15 pages) - Security Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-securityprecondition-04] (16 pages) - Signal 3D format [draft-ietf-mmusic-signal-3d-format-00] (27 pages) - SIP: Session Initiation Protocol [draft-ietf-mmusic-sip-12] (151 pages) - Reliability of Provisional Responses in SIP [draft-ietf-mmusic-sip-100rel-01] (12 pages) - SIP Caller Preferences and Callee Capabilities [draft-ietf-mmusic-sip-caller-00] (16 pages) - SIP Call Control Services [draft-ietf-mmusic-sip-cc-01] (34 pages) - The SIP INFO Method [draft-ietf-mmusic-sip-info-method-01] (6 pages) - The SIP ISUP/MIME type [draft-ietf-mmusic-sip-isup-mime-00] (4 pages) - The multipart/sip-id media type [draft-ietf-mmusic-sip-multipart-00] (4 pages) - SIP Security Using Public Key Algorithms [draft-ietf-mmusic-sip-sec-00] (24 pages) - SIP Session Timer [draft-ietf-mmusic-sip-session-timer-02] (12 pages) - SIP URL Scheme [draft-ietf-mmusic-sip-url-00] (3 pages) - A real-time stream control protocol (RTSP') [draft-ietf-mmusic-stream-00] (25 pages) - T.140 Real-time Text Conversation over WebRTC Data Channels [draft-ietf-mmusic-t140-usage-data-channel-14] (19 pages) - The Session Description Protocol (SDP) 'trafficclass' Attribute [draft-ietf-mmusic-traffic-class-for-sdp-05] (29 pages) - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol [draft-ietf-mmusic-trickle-ice-02] (25 pages) - A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) [draft-ietf-mmusic-trickle-ice-sip-18] (47 pages) - UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-udptl-dtls-10] (23 pages) Requests for Comments: RFC2326: Real Time Streaming Protocol (RTSP) (92 pages) * Obsoletes RFC7826 RFC2327: SDP: Session Description Protocol (42 pages) * Obsoletes RFC4566 * Updates RFC3266 RFC2543: SIP: Session Initiation Protocol (151 pages) * Obsoletes RFC3261 * Obsoletes RFC3262 * Obsoletes RFC3263 * Obsoletes RFC3264 * Obsoletes RFC3265 RFC2974: Session Announcement Protocol (18 pages) RFC3108: Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections (110 pages) RFC3259: A Message Bus for Local Coordination (39 pages) RFC3264: An Offer/Answer Model with Session Description Protocol (SDP) (25 pages) * Updates RFC6157 RFC3266: Support for IPv6 in Session Description Protocol (SDP) (5 pages) * Obsoletes RFC4566 RFC3388: Grouping of Media Lines in the Session Description Protocol (SDP) (11 pages) * Obsoletes RFC5888 RFC3524: Mapping of Media Streams to Resource Reservation Flows (6 pages) RFC3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) (8 pages) RFC3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (22 pages) RFC4091: The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (7 pages) * Obsoletes RFC5245 RFC4145: TCP-Based Media Transport in the Session Description Protocol (SDP) (15 pages) * Updates RFC4572 RFC4317: Session Description Protocol (SDP) Offer/Answer Examples (24 pages) RFC4435: A Framework for the Usage of Internet Media Guides (IMGs) (22 pages) RFC4473: Requirements for Internet Media Guides (IMGs) (23 pages) RFC4566: SDP: Session Description Protocol (49 pages) RFC4567: Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) (30 pages) RFC4568: Session Description Protocol (SDP) Security Descriptions for Media Streams (44 pages) RFC4570: Session Description Protocol (SDP) Source Filters (14 pages) RFC4572: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (17 pages) * Obsoletes RFC8122 RFC4574: The Session Description Protocol (SDP) Label Attribute (8 pages) RFC4583: Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (12 pages) RFC4756: Forward Error Correction Grouping Semantics in Session Description Protocol (6 pages) * Obsoletes RFC5956 RFC4796: The Session Description Protocol (SDP) Content Attribute (11 pages) RFC5027: Security Preconditions for Session Description Protocol (SDP) Media Streams (16 pages) RFC5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols (117 pages) * Updates RFC6336 * Obsoletes RFC8445 RFC5432: Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) (9 pages) RFC5547: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer (50 pages) RFC5576: Source-Specific Media Attributes in the Session Description Protocol (SDP) (18 pages) RFC5583: Signaling Media Decoding Dependency in the Session Description Protocol (SDP) (18 pages) RFC5888: The Session Description Protocol (SDP) Grouping Framework (21 pages) RFC5898: Connectivity Preconditions for Session Description Protocol (SDP) Media Streams (17 pages) RFC5939: Session Description Protocol (SDP) Capability Negotiation (77 pages) * Updates RFC6871 RFC5956: Forward Error Correction Grouping Semantics in the Session Description Protocol (14 pages) RFC6236: Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) (23 pages) RFC6336: IANA Registry for Interactive Connectivity Establishment (ICE) Options (5 pages) RFC6544: TCP Candidates with Interactive Connectivity Establishment (ICE) (29 pages) RFC6849: An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback (33 pages) RFC6871: Session Description Protocol (SDP) Media Capabilities Negotiation (55 pages) RFC7006: Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) (22 pages) RFC7104: Duplication Grouping Semantics in the Session Description Protocol (10 pages) RFC7195: Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) (39 pages) RFC7197: Duplication Delay Attribute in the Session Description Protocol (11 pages) RFC7261: Offer/Answer Considerations for G723 Annex A and G729 Annex B (8 pages) RFC7345: UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) (23 pages) RFC7362: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication (16 pages) RFC7604: Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) (46 pages) RFC7825: A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) (33 pages) RFC7826: Real-Time Streaming Protocol Version 2.0 (318 pages) RFC7850: Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles (7 pages) RFC8122: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (18 pages) Media OPerationS (mops) ----------------------- Charter Last Modified: 2020-04-21 Current Status: Active Chairs: Kyle Rose Leslie Daigle Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Éric Vyncke Tech Advisors: Glenn Deen Warren Kumari Mailing Lists: General Discussion: mops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mops Archive: https://mailarchive.ietf.org/arch/browse/mops/ Description of Working Group: Internet-wide and within-domain IP-delivered media is widespread, leading to significant technology development across industries not traditionally thought of as Internet technology developers or operators, as well as considerable quantities of traffic on local and transit networks. The focus of MOPS is on identifying areas where existing protocols and/or networks are challenged by updated requirements. MOPS will solicit input on media-related operational issues and practices; existing and proposed technologies related to the deployment, engineering, and operation of media streaming and manipulation protocols and procedures in the global Internet (inter-domain) and within-domain networking. In the context of this working group, media is considered to include the transport of video, audio, objects and any combination thereof, possibly non-sequentially. The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats. MOPS provides a venue for both video industry and Internet engineering experts to engage in discussion of video technology’s requirements of networking standards, as well as proposals for new uses of IP technology in video. Where new protocols are needed, MOPS will help identify candidate venues for their development. The goals of MOPS include documenting existing protocol and operational issues with media on the Internet, and identifying requirements for potential IETF work. The general process of elaboration through documentation will be for issues to be identified (on the mailing list) and presentations made at WG meetings. When topics merit more coherent documentation, MOPS will adopt working group documents to capture the information in Internet-Drafts. If the working group consensus is that the material of the Internet-Draft is generally useful for archival purposes, the WG will seek publication of the work items as RFCs. At any point — from early discussion of topics, through later documentation stages — MOPS may identify a more appropriate WG for the matter and/or document, and dispatch it. With that in mind, MOPS will: 1/ Solicit regular updates from other media technology developing consortia/standards bodies working with IETF-developed protocols. 2/ Solicit input from network operators and users to identify operational issues with media delivery in and across networks, and determine solutions or workarounds to those issues. 3/ Solicit discussion and documentation of the issues and opportunities in media acquisition and delivery, and of the resulting protocols and technologies developed outside the IETF. 4/ Document operational requirements for media acquisition (for example, from cameras and recording devices) and delivery. 5/ Develop operational information to aid in operation of media technologies in the global Internet. These activities should document media operational experience, including global Internet, inter-domain and within-domain operations. In all cases of working with other organizations mentioned above, MOPS will work with existing liaison managers where the IETF has them, and informal connections with other organizations otherwise. If new formal liaison relationships are required, MOPS will work with the IAB to help establish them. Media operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) remain the responsibility of the groups or areas responsible for those protocols or technologies. However, the MOPS Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to MOPS operational and deployment problems. There must be a continuing expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. The IESG is establishing this working group on an experimental basis and intends to review it, for rechartering to continue or else closure, in 2 years. Goals and Milestones: Feb 2020 - Draft of edge network operational considerations for streaming media Feb 2020 - Initial draft operational considerations for low latency streaming video applications Mar 2020 - Draft documenting Streaming Video Alliance (SVA) reliance on IETF protocols Mar 2020 - Draft documenting Society of Motion Picture and Television Engineers (SMPTE) protocol reliance on IETF protocols Jul 2020 - Last-call document on Streaming Video Alliance (SVA) reliance on IETF protocols (including explicit outreach to SVA) Jul 2020 - Last-call document on Society of Motion Picture and Television Engineers (SMPTE) protocol reliance on IETF protocols (including explicit outreach to SMPTE) Jul 2020 - Revised draft of edge network operational considerations for streaming media Jul 2020 - Revised draft operational considerations for low latency streaming video applications Nov 2020 - Last-call document on edge network considerations for streaming media Nov 2020 - Last-call document on operational considerations for low latency streaming video applications Nov 2020 - Develop work items specific to media acquisition and delivery Nov 2021 - IESG to decide whether continue, re-charter or close MOPS WG Internet-Drafts: - Operational Considerations for Streaming Media [draft-ietf-mops-streaming-opcons-02] (13 pages) No Requests for Comments Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2019-05-24 Current Status: Active Chairs: Loa Andersson Nicolai Leymann Tarek Saad Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Tech Advisor: George Swallow Secretary: Mach Chen Mailing Lists: General Discussion: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: https://mailarchive.ietf.org/arch/browse/mpls/ Description of Working Group: The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) for MPLS systems including the necessary management objects expressed as YANG models or MIB modules. The current WG focus areas and work items are: - Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs, in coordination with other working groups that work in overlapping areas including the BESS, BFD, CCAMP, OPSAWG, PALS, SPRING, and TEAS working groups. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE for packet networks, and LSP Ping to meet new requirements. - Document MPLS-specific aspects of traffic engineering including for multi-areas/multi-AS scenarios in cooperation with the TEAS working group. - Coordinate the work on RSVP-TE with CCAMP and TEAS. In the cases where there is an overlap, generic parts will be done by the TEAS working group, MPLS data plane specific parts will be done by the MPLS working group, and support for any other specific data planes will be done by the CCAMP working group. The TEAS working group acts as the hub for coordinating this work, and the MPLS working group will track agreements about work to be done in this working group through milestones in this charter. - Define data models for MPLS working group related solutions. YANG models and MIB modules may be considered. Coordinate with the LIME and NETMOD working groups for core YANG models. - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications. - Define the necessary extensions for MPLS key protocols for dual- stack and IPv6-only networks. - Document current implementation practices for MPLS load sharing. - Document mechanisms for securing MPLS protocols and data plane. - Document mechanisms for adding multi-topology support to existing MPLS protocols. - Define the necessary protection protocols and scenarios for transport profile MPLS applications - Document use cases for MPLS protocols. Goals and Milestones: Mar 2015 - Submit draft-ietf-mpls-tp-oam-id-mib for publication May 2015 - Submit draft-ietf-mpls-lsp-ping-relay-reply for publication May 2015 - Submit draft-ietf-mpls-mldp-node-protection for publication May 2015 - Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion May 2015 - ++ Progress draft-ietf-mpls-seamless-mcast to publication May 2015 - ++ Progress draft-ietf-mpls-ldp-ipv6 for publication to publication May 2015 - ++ Progress draft-ietf-mpls-ldp-ip-pw-capability to publication Jun 2015 - Submit draft-ietf-mpls-seamless-mpls for publication Jun 2015 - Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication Jun 2015 - Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication Jun 2015 - Submit draft-ietf-mpls-entropy-lsp-ping for publication Jun 2015 - ++ Progress draft-ietf-mpls-proxy-lsp-ping to publication Jun 2015 - ++ Progress draft-ietf-mpls-oam-ipv6-rao to publication Jun 2015 - ++ Progress draft-ietf-mpls-in-udp to publication Jul 2015 - Submit draft-ietf-mpls-te-express-path Aug 2015 - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Aug 2015 - Submit draft-ietf-mpls-tp-linear-protection-mib Aug 2015 - Submit draft-ietf-mpls-ldp-mrt for publication Aug 2015 - Submit draft-ietf-mpls-lsp-ping-lag-multipath for publication Done - Submit documents from original MPLS effort to IESG Done - Framework for IP multicast over label-switched paths ready for advancement. Done - LDP fault tolerance specification ready for advancement to Proposed Standard. Done - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), 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 Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Done - Submit draft-ietf-mpls-ldp-gtsm for publication Done - Submit draft-ietf-mpls-tp-itu-t-identifiers for publication Done - Submit draft-ietf-mpls-entropy-label 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-mldp-in-band-signaling for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-tp-ring-protection for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-gach-adv for publication Done - Submit draft-ietf-mpls-retire-ach-tlv 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-ldp-dod for publication Done - Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication Done - Submit draft-ietf-mpls-targeted-mldp for publication Done - Submit draft-ietf-mpls-tp-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-ldp-hello-crypto-auth for publication Done - Submit draft-ietf-mpls-extended-admin-group for publication Done - Submit draft-ietf-mpls-forwardig 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-smp-requirements for publication Done - Submit draft-ietf-mpls-deprecate-bgp-entropy-label for publication Done - Submit draft-ietf-mpls-mldp-in-band-wildcard-encoding for publication Done - Submit draft-ietf-mpls-pim-sm-over-mldp Done - Submit draft-ietf-mpls-tp-te-mib for publication Done - Submit draft-ietf-mpls-p2mp-loose-path-reopt for publicatiion Done - Submit draft-ietf-mpls-ipv6-only-gap for publication Done - Submit draft-ietf-mpls-ldp-ipv6 for publication Done - Submit draft-ietf-mpls-seamless-mcast for publication Done - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Done - Submit draft-ietf-mpls-in-udp for publication Done - Submit draft-ietf-mpls-proxy-lsp-ping fpr 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-registry for publication Done - Submit draft-ietf-mpls-oam-ipv6-rao for publication Internet-Drafts: - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) [draft-akiya-mpls-entropy-lsp-ping-04] (21 pages) - Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces [draft-akiya-mpls-lsp-ping-lag-multipath-05] (27 pages) - Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification [draft-akiya-mpls-lsp-ping-reply-mode-simple-03] (11 pages) - Updating the IANA MPLS LSP Ping Parameters [draft-andersson-mpls-lsp-ping-registries-update-02] (12 pages) - Updates to RFC 4379 IANA section [draft-andersson-mpls-lsp-ping-upd-00] (4 pages) - 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) - 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-08] (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) - 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) - MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology [draft-cheng-mpls-tp-shared-ring-protection-06] (46 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) - 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) - 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] (30 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-bfd-directed-15] (9 pages) - Graceful Restart Mechanism for BGP with MPLS [draft-ietf-mpls-bgp-mpls-restart-05] (10 pages) - Carrying Label Information in BGP-4 [draft-ietf-mpls-bgp4-mpls-05] (8 pages) - Link Bundling in MPLS Traffic Engineering (TE) [draft-ietf-mpls-bundle-06] (12 pages) - Link Bundling Management Information Base [draft-ietf-mpls-bundle-mib-04] (52 pages) - Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field [draft-ietf-mpls-cosfield-def-08] (9 pages) - Constraint-Based LSP Setup using LDP [draft-ietf-mpls-cr-ldp-06] (42 pages) - Applicability Statement for CR-LDP [draft-ietf-mpls-crldp-applic-01] (7 pages) - Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) [draft-ietf-mpls-crldp-unnum-10] (8 pages) - LSP Modification Using CR-LDP [draft-ietf-mpls-crlsp-modify-03] (11 pages) - Deprecation of BGP Entropy Label Capability Attribute [draft-ietf-mpls-deprecate-bgp-entropy-label-02] (4 pages) - Multi-Protocol Label Switching (MPLS) Support of Differentiated Services [draft-ietf-mpls-diff-ext-09] (64 pages) - Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-ext-01] (12 pages) - Requirements for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-reqts-00] (13 pages) - Avoiding Equal Cost Multipath Treatment in MPLS Networks [draft-ietf-mpls-ecmp-bcp-03] (8 pages) - A Proposal to Incorporate ECN in MPLS [draft-ietf-mpls-ecn-00] (9 pages) - MPLS Egress Protection Framework [draft-ietf-mpls-egress-protection-framework-07] (25 pages) - The Use of Entropy Labels in MPLS Forwarding [draft-ietf-mpls-entropy-label-06] (25 pages) - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) [draft-ietf-mpls-entropy-lsp-ping-05] (23 pages) - Removing a Restriction on the use of MPLS Explicit NULL [draft-ietf-mpls-explicit-null-02] (7 pages) - Component Link Recording and Resource Control for TE Links [draft-ietf-mpls-explicit-resource-control-bundle-10] (13 pages) - Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) [draft-ietf-mpls-extended-admin-group-07] (7 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute [draft-ietf-mpls-fastreroute-mib-21] (53 pages) - MPLS Flow Identification Considerations [draft-ietf-mpls-flow-ident-07] (11 pages) - MPLS Forwarding Compliance and Performance Requirements [draft-ietf-mpls-forwarding-09] (59 pages) - Use of Label Switching on Frame Relay Networks Specification [draft-ietf-mpls-fr-06] (24 pages) - A Framework for MPLS [draft-ietf-mpls-framework-05] (69 pages) - Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) [draft-ietf-mpls-ftn-mib-09] (42 pages) - MPLS Generic Associated Channel (G-ACh) Advertisement Protocol [draft-ietf-mpls-gach-adv-08] (23 pages) - The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol [draft-ietf-mpls-git-uus-04] (25 pages) - PathErr Message Triggered MPLS and GMPLS LSP Reroutes [draft-ietf-mpls-gmpls-lsp-reroute-06] (12 pages) - MPLS/IP Header Compression [draft-ietf-mpls-hdr-comp-00] (14 pages) - MPLS/IP Header Compression over PPP [draft-ietf-mpls-hdr-comp-over-ppp-00] (10 pages) - Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object [draft-ietf-mpls-iana-rsvp-session-flags-01] (5 pages) - ICMP Extensions for Multiprotocol Label Switching [draft-ietf-mpls-icmp-08] (8 pages) - LDP IGP Synchronization [draft-ietf-mpls-igp-sync-01] (8 pages) - Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) [draft-ietf-mpls-in-ip-or-gre-08] (14 pages) - Encapsulating MPLS in UDP [draft-ietf-mpls-in-udp-11] (19 pages) - Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment [draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01] (17 pages) - Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios [draft-ietf-mpls-interas-lspping-00] (18 pages) - Label Edge Router Forwarding of IPv4 Option Packets [draft-ietf-mpls-ip-options-07] (9 pages) - Gap Analysis for Operating IPv6-Only MPLS Networks [draft-ietf-mpls-ipv6-only-gap-04] (28 pages) - Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 [draft-ietf-mpls-ipv6-pw-lsp-ping-04] (8 pages) - MPLS Label Stack Encoding [draft-ietf-mpls-label-encaps-08] (23 pages) - Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition [draft-ietf-mpls-lc-if-mib-08] (22 pages) - LDP Specification [draft-ietf-mpls-ldp-11] (132 pages) - LDP Applicability [draft-ietf-mpls-ldp-applic-02] (7 pages) - Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) [draft-ietf-mpls-ldp-applicability-label-adv-03] (8 pages) - LDP Capabilities [draft-ietf-mpls-ldp-capabilities-04] (12 pages) - LDP Downstream-on-Demand in Seamless MPLS [draft-ietf-mpls-ldp-dod-09] (35 pages) - LDP DoD Graceful Restart [draft-ietf-mpls-ldp-dod-restart-00] (18 pages) - Signaling LDP Label Advertisement Completion [draft-ietf-mpls-ldp-end-of-lib-04] (9 pages) - Experience with the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-experience-00] (7 pages) - Fault Tolerance for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-ft-06] (52 pages) - The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-gtsm-09] (8 pages) - LDP Hello Cryptographic Authentication [draft-ietf-mpls-ldp-hello-crypto-auth-10] (14 pages) - Label Distribution Protocol (LDP) Internet Assigned Numbers Authority (IANA) Considerations Update [draft-ietf-mpls-ldp-iana-01] (5 pages) - LDP IGP Synchronization [draft-ietf-mpls-ldp-igp-sync-04] (7 pages) - LDP IGP Synchronization for Broadcast Networks [draft-ietf-mpls-ldp-igp-sync-bcast-06] (9 pages) - LDP Extension for Inter-Area Label Switched Paths (LSPs) [draft-ietf-mpls-ldp-interarea-04] (12 pages) - Controlling State Advertisements of Non-negotiated LDP Applications [draft-ietf-mpls-ldp-ip-pw-capability-09] (15 pages) - Updates to LDP for IPv6 [draft-ietf-mpls-ldp-ipv6-17] (24 pages) - Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-mib-14] (106 pages) - YANG Data Model for MPLS LDP and mLDP [draft-ietf-mpls-ldp-mldp-yang-00] (115 pages) - LDP Extensions to Support Maximally Redundant Trees [draft-ietf-mpls-ldp-mrt-07] (21 pages) - Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol [draft-ietf-mpls-ldp-mtu-extensions-03] (9 pages) - LDP Extensions for Multi-Topology [draft-ietf-mpls-ldp-multi-topology-12] (20 pages) - LDP Extensions for Optical User Network Interface (O-UNI) Signaling [draft-ietf-mpls-ldp-optical-uni-01] (26 pages) - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-ldp-p2mp-15] (39 pages) - Graceful Restart Mechanism for Label Distribution Protocol [draft-ietf-mpls-ldp-restart-06] (12 pages) - Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-restart-applic-01] (16 pages) - LDP Extensions for RMR [draft-ietf-mpls-ldp-rmr-extensions-03] (13 pages) - LDP State Machine [draft-ietf-mpls-ldp-state-04] (78 pages) - The Label Distribution Protocol (LDP) Implementation Survey Results [draft-ietf-mpls-ldp-survey2002-00] (23 pages) - Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) [draft-ietf-mpls-ldp-typed-wildcard-07] (10 pages) - MPLS Upstream Label Assignment for LDP [draft-ietf-mpls-ldp-upstream-10] (13 pages) - YANG Data Model for MPLS LDP [draft-ietf-mpls-ldp-yang-09] (93 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) - OSPFv3 CodePoint for MPLS LSP Ping [draft-ietf-mpls-lsp-ping-ospfv3-codepoint-02] (6 pages) - Updating the IANA MPLS LSP Ping Parameters [draft-ietf-mpls-lsp-ping-registries-update-05] (33 pages) - IANA Registries for LSP Ping Code Points [draft-ietf-mpls-lsp-ping-registry-03] (7 pages) - Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping [draft-ietf-mpls-lsp-ping-relay-reply-11] (18 pages) - Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification [draft-ietf-mpls-lsp-ping-reply-mode-simple-05] (17 pages) - Definition of Time to Live TLV for LSP-Ping Mechanisms [draft-ietf-mpls-lsp-ping-ttl-tlv-10] (8 pages) - Multi Protocol Label Switching Label Distribution Protocol Query Message Description [draft-ietf-mpls-lsp-query-09] (19 pages) - Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [draft-ietf-mpls-lsr-mib-14] (60 pages) - Label Switching Router Self-Test [draft-ietf-mpls-lsr-self-test-07] (15 pages) - Connectivity Verification for Multicast Label Switched Paths [draft-ietf-mpls-mcast-cv-00] (13 pages) - Multiprotocol Label Switching (MPLS) Management Overview [draft-ietf-mpls-mgmt-overview-09] (32 pages) - LDP Extensions for Hub and Spoke Multipoint Label Switched Path [draft-ietf-mpls-mldp-hsmp-06] (15 pages) - Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-in-band-signaling-08] (12 pages) - Multipoint LDP (mLDP) In-Band Signaling with Wildcards [draft-ietf-mpls-mldp-in-band-wildcard-encoding-03] (16 pages) - Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-mib-05] (40 pages) - 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-07] (69 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) - 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) - Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping [draft-ietf-mpls-p2mp-lsp-ping-18] (28 pages) - Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks [draft-ietf-mpls-p2mp-oam-reqs-01] (14 pages) - Requirements for Point to Multipoint Traffic Engineered MPLS LSPs [draft-ietf-mpls-p2mp-requirement-04] (34 pages) - Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-p2mp-sig-requirement-04] (30 pages) - P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels [draft-ietf-mpls-p2mp-te-bypass-02] (14 pages) - Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module [draft-ietf-mpls-p2mp-te-mib-09] (62 pages) - Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) [draft-ietf-mpls-pim-sm-over-mldp-03] (11 pages) - MPLS Performance Measurement UDP Return Path [draft-ietf-mpls-pm-udp-return-00] (8 pages) - Proxy MPLS Echo Request [draft-ietf-mpls-proxy-lsp-ping-05] (28 pages) - Updates to MPLS Transport Profile Linear Protection [draft-ietf-mpls-psc-updates-06] (11 pages) - Framework for Multi-Protocol Label Switching (MPLS)-based Recovery [draft-ietf-mpls-recovery-frmwrk-08] (40 pages) - Proxy LSP Ping [draft-ietf-mpls-remote-lsp-ping-03] (19 pages) - Residence Time Measurement in MPLS Networks [draft-ietf-mpls-residence-time-15] (30 pages) - Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel [draft-ietf-mpls-retire-ach-tlv-03] (5 pages) - Return Path Specified Label Switched Path (LSP) Ping [draft-ietf-mpls-return-path-specified-lsp-ping-15] (21 pages) - LDP Specification [draft-ietf-mpls-rfc3036bis-04] (135 pages) - Using BGP to Bind MPLS Labels to Address Prefixes [draft-ietf-mpls-rfc3107bis-04] (23 pages) - Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures [draft-ietf-mpls-rfc4379bis-09] (78 pages) - RFC6374 Synonymous Flow Labels [draft-ietf-mpls-rfc6374-sfl-07] (20 pages) - Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane [draft-ietf-mpls-rfc6374-sr-00] (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-07] (25 pages) - Resilient MPLS Rings [draft-ietf-mpls-rmr-13] (20 pages) - Resilient MPLS Rings and Multicast [draft-ietf-mpls-rmr-multicast-00] (7 pages) - Use of Label Switching With RSVP [draft-ietf-mpls-rsvp-00] (13 pages) - Fast Reroute Extensions to RSVP-TE for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-fastreroute-07] (38 pages) - RSVP-TE: Extensions to RSVP for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-tunnel-09] (61 pages) - Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane [draft-ietf-mpls-rsvp-shared-labels-09] (24 pages) - Hub and Spoke Multipoint Label Switched Path Tunnels [draft-ietf-mpls-rsvp-te-hsmp-lsp-01] (8 pages) - Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths [draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09] (10 pages) - Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-mpls-rsvp-te-p2mp-07] (53 pages) - Applicability Statement for Extensions to RSVP for LSP-Tunnels [draft-ietf-mpls-rsvp-tunnel-applicability-02] (8 pages) - Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvp-unnum-08] (9 pages) - MPLS Upstream Label Assignment for RSVP-TE [draft-ietf-mpls-rsvp-upstream-05] (10 pages) - 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) - 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] (10 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-04] (8 pages) - Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels [draft-ietf-mpls-spring-entropy-label-12] (22 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes [draft-ietf-mpls-spring-lsp-ping-13] (25 pages) - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes [draft-ietf-mpls-sr-epe-oam-00] (17 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-11] (18 pages) - RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels [draft-ietf-mpls-summary-frr-rsvpte-09] (18 pages) - Using LDP Multipoint Extensions on Targeted LDP Sessions [draft-ietf-mpls-targeted-mldp-04] (9 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-ietf-mpls-tc-mib-10] (20 pages) - Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions [draft-ietf-mpls-te-express-path-00] (10 pages) - Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol [draft-ietf-mpls-te-feed-06] (13 pages) - 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) - Traffic Engineering Link Management Information Base [draft-ietf-mpls-telink-mib-07] (54 pages) - MPLS-TP 1toN Protection [draft-ietf-mpls-tp-1ton-protection-02] (36 pages) - Definition of ACH TLV Structure [draft-ietf-mpls-tp-ach-tlv-02] (9 pages) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ietf-mpls-tp-aps-updates-04] (9 pages) - Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile [draft-ietf-mpls-tp-bfd-cc-cv-00] (12 pages) - Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [draft-ietf-mpls-tp-cc-cv-rdi-06] (21 pages) - Indication of Client Failure in MPLS-TP [draft-ietf-mpls-tp-csf-02] (12 pages) - MPLS Transport Profile Data Plane Architecture [draft-ietf-mpls-tp-data-plane-04] (15 pages) - MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing [draft-ietf-mpls-tp-ethernet-addressing-08] (9 pages) - MPLS Fault Management Operations, Administration, and Maintenance (OAM) [draft-ietf-mpls-tp-fault-07] (17 pages) - A Framework for MPLS in Transport Networks [draft-ietf-mpls-tp-framework-12] (56 pages) - An In-Band Data Communication Network For the MPLS Transport Profile [draft-ietf-mpls-tp-gach-dcn-06] (8 pages) - MPLS Generic Associated Channel [draft-ietf-mpls-tp-gach-gal-06] (19 pages) - MPLS Transport Profile (MPLS-TP) Identifiers [draft-ietf-mpls-tp-identifiers-07] (17 pages) - MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions [draft-ietf-mpls-tp-itu-t-identifiers-08] (12 pages) - MPLS Transport Profile Lock Instruct and Loopback Functions [draft-ietf-mpls-tp-li-lb-08] (12 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection [draft-ietf-mpls-tp-linear-protection-09] (45 pages) - MPLS Transport Profile Linear Protection MIB [draft-ietf-mpls-tp-linear-protection-mib-12] (48 pages) - Packet Loss and Delay Measurement for the MPLS Transport Profile [draft-ietf-mpls-tp-loss-delay-00] (30 pages) - A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks [draft-ietf-mpls-tp-loss-delay-profile-04] (5 pages) - LSP-Ping and BFD encapsulation over ACH [draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01] (9 pages) - Use Cases and Requirements for MPLS-TP multi-failure protection [draft-ietf-mpls-tp-mfp-use-case-and-requirements-03] (9 pages) - Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview [draft-ietf-mpls-tp-mib-management-overview-08] (29 pages) - Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) [draft-ietf-mpls-tp-mip-mep-map-09] (11 pages) - Network Management Framework for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-framework-05] (18 pages) - Network Management Requirements for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-req-06] (24 pages) - An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-analysis-09] (21 pages) - Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-framework-11] (62 pages) - MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) [draft-ietf-mpls-tp-oam-id-mib-11] (36 pages) - Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks [draft-ietf-mpls-tp-oam-requirements-06] (17 pages) - MPLS On-Demand Connectivity Verification and Route Tracing [draft-ietf-mpls-tp-on-demand-cv-07] (22 pages) - A Framework for Point-to-Multipoint MPLS in Transport Networks [draft-ietf-mpls-tp-p2mp-framework-06] (12 pages) - IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process [draft-ietf-mpls-tp-process-05] (23 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators [draft-ietf-mpls-tp-psc-itu-04] (40 pages) - Requirements of an MPLS Transport Profile [draft-ietf-mpls-tp-requirements-10] (31 pages) - Applicability of MPLS Transport Profile for Ring Topologies [draft-ietf-mpls-tp-ring-protection-06] (30 pages) - A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations [draft-ietf-mpls-tp-rosetta-stone-13] (21 pages) - MPLS Transport Profile (MPLS-TP) Security Framework [draft-ietf-mpls-tp-security-framework-09] (15 pages) - MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology [draft-ietf-mpls-tp-shared-ring-protection-06] (56 pages) - MPLS Transport Profile (MPLS-TP) Survivability Framework [draft-ietf-mpls-tp-survive-fwk-06] (56 pages) - MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-tp-te-mib-11] (62 pages) - Requirements for Hitless MPLS Path Segment Monitoring [draft-ietf-mpls-tp-temporal-hitless-psm-14] (16 pages) - MPLS Transport Profile User-to-Network and Network-to-Network Interfaces [draft-ietf-mpls-tp-uni-nni-03] (6 pages) - MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design [draft-ietf-mpls-tp-use-cases-and-design-08] (16 pages) - Requirements for Traffic Engineering Over MPLS [draft-ietf-mpls-traffic-eng-01] (29 pages) - Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks [draft-ietf-mpls-ttl-04] (10 pages) - MPLS Upstream Label Assignment and Context-Specific Label Space [draft-ietf-mpls-upstream-label-07] (13 pages) - VCID Notification over ATM link for LDP [draft-ietf-mpls-vcid-atm-05] (19 pages) - LDP Specification [draft-ijln-mpls-rfc5036bis-04] (141 pages) - 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-08] (12 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) - Management Information Base for MPLS LDP Multi Topology [draft-li-mpls-ldp-mt-mib-06] (29 pages) - Proxy MPLS Echo Request [draft-lim-mpls-proxy-lsp-ping-03] (24 pages) - MPLS Capability set [draft-loa-mpls-cap-set-01] (7 pages) - MPLS Encapsulation for SFC NSH [draft-malis-mpls-sfc-encapsulation-03] (7 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-manral-mpls-rfc3811bis-04] (24 pages) - Bidirectional Forwarding Detection (BFD) Directed Return Path [draft-mirsky-mpls-bfd-directed-04] (10 pages) - BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP [draft-mirsky-mpls-p2mp-bfd-11] (10 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-00] (37 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-00] (17 pages) - Extended Administrative Groups in MPLS-TE [draft-osborne-mpls-extended-admin-groups-03] (6 pages) - Updates to PSC [draft-osborne-mpls-psc-updates-03] (8 pages) - "MPLS LSP Ping TLVs and sub-TLVs registry" [draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02] (17 pages) - Targeted LDP Hello Reduction [draft-pdutta-mpls-tldp-hello-reduce-04] (8 pages) - 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) - Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode [draft-ryoo-mpls-tp-aps-updates-03] (7 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's Requirements [draft-ryoogray-mpls-tp-psc-itu-01] (31 pages) - A YANG Data Model for MPLS Base [draft-saad-mpls-base-yang-00] (10 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) - 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 Node Protection [draft-wijnands-mpls-mldp-node-protection-04] (16 pages) - SR-MPLS over IP [draft-xu-mpls-sr-over-ip-01] (16 pages) - Unified Source Routing Instructions using MPLS Label Stack [draft-xu-mpls-unified-source-routing-instruction-04] (14 pages) - P2MP Based mLDP Node Protection Mechanisms for mLDP LSP [draft-zhao-mpls-mldp-protections-05] (19 pages) - YANG Data Model for LSP-Ping [draft-zheng-mpls-lsp-ping-yang-cfg-10] (29 pages) - Resilient MPLS Rings and Multicast [draft-zzhang-mpls-rmr-multicast-03] (7 pages) Requests for Comments: BCP128: Avoiding Equal Cost Multipath Treatment in MPLS Networks (8 pages) RFC2702: Requirements for Traffic Engineering Over MPLS (29 pages) RFC3031: Multiprotocol Label Switching Architecture (61 pages) * Updates RFC6178 * Updates RFC6790 RFC3032: MPLS Label Stack Encoding (23 pages) * Updates RFC3443 * Updates RFC4182 * Updates RFC5332 * Updates RFC3270 * Updates RFC5129 * Updates RFC5462 * Updates RFC5586 * Updates RFC7274 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 RFC7274 * Updates RFC7214 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 RFC7324 * Updates RFC7271 * Updates RFC7214 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) 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 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 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) 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) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Kent Watsen Mahesh Jethanandani Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: https://mailarchive.ietf.org/arch/browse/netconf/ Description of Working Group: The NETCONF Working Group, previously named after the NETCONF protocol, now renamed as the NETwork CONFiguration Working Group, is responsible for the development and maintenance of protocols such as NETCONF and RESTCONF for YANG data model-driven management (for the purposes of, for example, configuration, monitoring, telemetry, and zero-touch), their transports and encodings, defining data models necessary to support the protocols, and defining mechanisms supporting the operational deployment of systems using the protocols. The NETCONF protocol is data modeling language independent, but YANG (RFC 7950) is the recommended NETCONF data modeling language, which introduces advanced language features for configuration management. The NETCONF WG is currently responsible for: a) The network management protocol NETCONF (RFC 6241). This effort entails periodically updating the NETCONF related specifications to address new requirements as they arise. b) The network management protocol RESTCONF (RFC 8040). This effort entails periodically updating the RESTCONF related specifications to address new requirements as they arise. c) The transports and encodings used by the data model-driven protocols. d) The data models and mechanisms related to network management protocols. Specifically, data models enabling the configuration and/or monitoring of the protocols themselves. Other examples include data models for configuring access controls or discovering server metadata. e) The data models for subscriptions to data, and protocol bindings for pushing subscribed data to clients, for the purpose of monitoring and telemetry. f) The mechanisms enabling devices zero-touch provisioning and the related call home functions. The NETCONF working group consults with the NETMOD working group to ensure that new requirements are understood and can be met by the YANG data modeling language (RFC 7950) developed within that working group. Goals and Milestones: Sep 2018 - WGLC for advanced Notification/Subscription Specifications Sep 2018 - WGLC for YANG Push Sep 2018 - WGLC for RESTCONF and HTTP Transport for Event Notifications Sep 2018 - WGLC for NETCONF Support for Event Notifications Sep 2018 - WGLC for YANG Notification Headers and Bundles Dec 2018 - WGLC for System-level Keystore Mechanism Dec 2018 - WGLC for Server and Client Configuration Models for NETCONF and RESTCONF Dec 2018 - WGLC for Client and Server Configuration Models for SSH and TLS Dec 2018 - Submit draft-ietf-netconf-udp-pub-channel to IESG for publication (as Standards Track) Done - WGLC for NMDA NETCONF Done - WGLC for NMDA RESTCONF Done - WGLC for YANG Library bis (as Standards Track) Done - WGLC for Zero-touch Configuration Mechanism Internet-Drafts: - RESTCONF Update to Support the NMDA [draft-dsdt-netconf-restconf-nmda-00] (6 pages) - NETCONF Model for NMDA [draft-dsdt-nmda-netconf-01] (13 pages) - Network Configuration Protocol (NETCONF) [draft-ietf-netconf-4741bis-10] (113 pages) - Network Configuration Protocol (NETCONF) Access Control Model [draft-ietf-netconf-access-control-07] (49 pages) - Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [draft-ietf-netconf-beep-10] (10 pages) - NETCONF Call Home and RESTCONF Call Home [draft-ietf-netconf-call-home-17] (13 pages) - YANG Data Types and Groupings for Cryptography [draft-ietf-netconf-crypto-types-18] (56 pages) - Subscription to Distributed Notifications [draft-ietf-netconf-distributed-notif-00] (19 pages) - YANG Groupings for HTTP Clients and HTTP Servers [draft-ietf-netconf-http-client-server-05] (31 pages) - An HTTPS-based Transport for Configured Subscriptions [draft-ietf-netconf-https-notif-05] (27 pages) - A YANG Data Model for a Keystore [draft-ietf-netconf-keystore-20] (52 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (28 pages) - NETCONF Client and Server Models [draft-ietf-netconf-netconf-client-server-21] (58 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 for describing System Capabilities and Yang-Push Notification Capabilities [draft-ietf-netconf-notification-capabilities-13] (26 pages) - Notification Message Headers and Bundles [draft-ietf-netconf-notification-messages-08] (23 pages) - Partial Lock Remote Procedure Call (RPC) for NETCONF [draft-ietf-netconf-partial-lock-11] (23 pages) - NETCONF Configuration Protocol [draft-ietf-netconf-prot-12] (95 pages) - RESTCONF Protocol [draft-ietf-netconf-restconf-18] (137 pages) - RESTCONF Client and Server Models [draft-ietf-netconf-restconf-client-server-21] (55 pages) - RESTCONF Collection Resource [draft-ietf-netconf-restconf-collection-00] (17 pages) - Dynamic Subscription to YANG Events and Datastores over RESTCONF [draft-ietf-netconf-restconf-notif-15] (23 pages) - NETCONF Call Home using SSH [draft-ietf-netconf-reverse-ssh-06] (11 pages) - Using the NETCONF Protocol over Secure Shell (SSH) [draft-ietf-netconf-rfc4742bis-08] (11 pages) - RFC4743 and RFC4744 to Historic status [draft-ietf-netconf-rfc4743-rfc4744-to-historic-00] (4 pages) - Subscribing to Event Notifications [draft-ietf-netconf-rfc5277bis-01] (46 pages) - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication [draft-ietf-netconf-rfc5539bis-10] (11 pages) - Network Configuration Access Control Model [draft-ietf-netconf-rfc6536bis-09] (58 pages) - YANG Library [draft-ietf-netconf-rfc7895bis-07] (32 pages) - NETCONF Server and RESTCONF Server Configuration Models [draft-ietf-netconf-server-model-09] (74 pages) - Using NETCONF over the Simple Object Access Protocol (SOAP) [draft-ietf-netconf-soap-08] (20 pages) - Using the NETCONF Configuration Protocol over Secure SHell (SSH) [draft-ietf-netconf-ssh-06] (10 pages) - YANG Groupings for SSH Clients and SSH Servers [draft-ietf-netconf-ssh-client-server-22] (62 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-00] (29 pages) - YANG Groupings for TCP Clients and TCP Servers [draft-ietf-netconf-tcp-client-server-08] (32 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-22] (59 pages) - A YANG Data Model for a Truststore [draft-ietf-netconf-trust-anchors-13] (39 pages) - UDP-based Transport for Configured Subscriptions [draft-ietf-netconf-udp-notif-00] (15 pages) - UDP based Publication Channel for Streaming Telemetry [draft-ietf-netconf-udp-pub-channel-05] (21 pages) - With-defaults Capability for NETCONF [draft-ietf-netconf-with-defaults-14] (26 pages) - YANG Module Library [draft-ietf-netconf-yang-library-06] (13 pages) - YANG Patch Media Type [draft-ietf-netconf-yang-patch-14] (39 pages) - Subscription to YANG Notifications for Datastore Updates [draft-ietf-netconf-yang-push-25] (58 pages) - Secure Zero Touch Provisioning (SZTP) [draft-ietf-netconf-zerotouch-29] (87 pages) - YANG Library [draft-nmdsdt-netconf-rfc7895bis-01] (23 pages) Requests for Comments: RFC4741: NETCONF Configuration Protocol (95 pages) * Obsoletes RFC6241 RFC4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) (10 pages) * Obsoletes RFC6242 RFC4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (20 pages) RFC4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (10 pages) 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) STD91: Network Configuration Access Control Model (58 pages) Network Modeling (netmod) ------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Joel Jaeggli Kent Watsen Lou Berger Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netmod Archive: https://mailarchive.ietf.org/arch/browse/netmod/ Description of Working Group: The Network Modeling (NETMOD) working group is responsible for the YANG data modeling language, which can be used to specify network management data models that are transported over such protocols as NETCONF and RESTCONF, and guidelines for developing YANG models. The NETMOD working group addresses general topics related to the use of the YANG language and YANG models, for example, the mapping of YANG modeled data into various encodings. Finally, the NETMOD working group also defines core YANG models used as basic YANG building blocks, and YANG models that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG may include work on YANG modules device profiles that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG is responsible for: a) Maintaining the data modeling language YANG. This effort entails periodically updating the specification to address new requirements as they arise. b) Maintaining the guidelines for developing YANG models. This effort is primarily driven by updates made to the YANG specification. c) Maintaining a conceptual framework in which YANG models are used. This effort entails describing the generic context that in YANG exists and how certain YANG statements interact in that context. An example of this is YANG's relationship with datastores. d) Maintaining encodings for YANG modeled data. This effort entails updating encodings already defined by the NETMOD working group (XML and JSON) to accommodate changes to the YANG specification, and defining new YANG encodings that are needed, and yet do not fall under the charter of any other active IETF working group. e) Maintaining YANG models used as basic YANG building blocks. This effort entails updating existing YANG models (ietf-yang-types and ietf-inet-types) as needed, as well as defining additional core YANG data models when necessary. f) Defining and maintaining YANG models that do not fall under the charter of any other active IETF working group. The NETMOD working group consults with the NETCONF working group to ensure that new requirements are understood and can be met by the protocols (e.g., NETCONF and RESTCONF) developed within that working group. The NETMOD working group does not serve as a review team for YANG modules developed by other working groups. Instead, the YANG doctors, [1] as organized by the OPS area director responsible for network management, will act as advisors for other working groups and provide YANG reviews for the OPS area directors. [1] http://www.ietf.org/iesg/directorate/yang-doctors.html Goals and Milestones: May 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG for publication (as Informational) May 2017 - Submit draft-ietf-netmod-syslog-model to IESG for publication (as Standards Track) Jul 2017 - Submit draft-ietf-netmod-rfc6087bis to IESG for publication (as Informational) Nov 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for publication (as Standards Track) Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for publication (as Informational) Jan 2018 - Submit draft-ietf-netmod-entity to IESG for publication (as Standards Track) Jan 2018 - Submit draft-ietf-netmod-acl-model to IESG for publication (as Standards Track) Internet-Drafts: - YANG Data Extensions [draft-bierman-netmod-yang-data-ext-01] (10 pages) - A YANG Data Model for Interface Management [draft-bjorklund-netmod-rfc7223bis-00] (47 pages) - A YANG Data Model for IP Management [draft-bjorklund-netmod-rfc7277bis-00] (32 pages) - 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 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-05] (25 pages) - IANA Address Family Numbers and Subsequent Address Family Identifiers YANG Module [draft-ietf-netmod-iana-afn-safi-00] (20 pages) - IANA Interface Type YANG Module [draft-ietf-netmod-iana-if-type-10] (37 pages) - IANA Timezone Database YANG Module [draft-ietf-netmod-iana-timezones-03] (40 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-interfaces-cfg-16] (39 pages) - Common Interface Extension YANG Data Models [draft-ietf-netmod-intf-ext-yang-10] (34 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] (18 pages) - Comparison of NMDA datastores [draft-ietf-netmod-nmda-diff-07] (19 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-04] (48 pages) - A YANG Data Model for Interface Management [draft-ietf-netmod-rfc7223bis-03] (49 pages) - A YANG Data Model for IP Management [draft-ietf-netmod-rfc7277bis-03] (34 pages) - A YANG Data Model for Routing Management (NMDA Version) [draft-ietf-netmod-rfc8022bis-11] (80 pages) - A YANG Data Model for Routing Management [draft-ietf-netmod-routing-cfg-25] (64 pages) - YANG Schema Mount [draft-ietf-netmod-schema-mount-12] (28 pages) - Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules [draft-ietf-netmod-smi-yang-05] (36 pages) - A YANG Data Model for SNMP Configuration [draft-ietf-netmod-snmp-cfg-08] (88 pages) - Sub-interface VLAN YANG Data Models [draft-ietf-netmod-sub-intf-vlan-model-07] (36 pages) - A YANG Data Model for Syslog Configuration [draft-ietf-netmod-syslog-model-26] (31 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) - YANG Instance Data File Format [draft-ietf-netmod-yang-instance-file-format-12] (28 pages) - JSON Encoding of Data Modeled with YANG [draft-ietf-netmod-yang-json-10] (20 pages) - Defining and Using Metadata with YANG [draft-ietf-netmod-yang-metadata-07] (21 pages) - YANG Module Classification [draft-ietf-netmod-yang-model-classification-08] (11 pages) - Updated YANG Module Revision Handling [draft-ietf-netmod-yang-module-versioning-01] (35 pages) - YANG Packages [draft-ietf-netmod-yang-packages-00] (56 pages) - YANG Schema Comparison [draft-ietf-netmod-yang-schema-comparison-00] (13 pages) - YANG Semantic Versioning [draft-ietf-netmod-yang-semver-01] (20 pages) - YANG Versioning Solution Overview [draft-ietf-netmod-yang-solutions-00] (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-03] (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) - 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) Requests for Comments: BCP215: YANG Tree Diagrams (13 pages) BCP216: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (63 pages) RFC6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) (173 pages) RFC6021: Common YANG Data Types (26 pages) * Obsoletes RFC6991 RFC6087: Guidelines for Authors and Reviewers of YANG Data Model Documents (26 pages) * Obsoletes RFC8407 RFC6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content (100 pages) * Updates RFC7952 RFC6244: An Architecture for Network Management Using NETCONF and YANG (30 pages) RFC6643: Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules (36 pages) RFC6991: Common YANG Data Types (30 pages) RFC7223: A YANG Data Model for Interface Management (39 pages) * Obsoletes RFC8343 RFC7224: IANA Interface Type YANG Module (37 pages) RFC7277: A YANG Data Model for IP Management (30 pages) * Obsoletes RFC8344 RFC7317: A YANG Data Model for System Management (35 pages) RFC7407: A YANG Data Model for SNMP Configuration (88 pages) RFC7950: The YANG 1.1 Data Modeling Language (217 pages) * Updates RFC8342 * Updates RFC8526 RFC7951: JSON Encoding of Data Modeled with YANG (20 pages) RFC7952: Defining and Using Metadata with YANG (21 pages) RFC8022: A YANG Data Model for Routing Management (64 pages) * Obsoletes RFC8349 RFC8199: YANG Module Classification (11 pages) RFC8340: YANG Tree Diagrams (13 pages) * Updates RFC8791 RFC8342: Network Management Datastore Architecture (NMDA) (44 pages) RFC8343: A YANG Data Model for Interface Management (49 pages) RFC8344: A YANG Data Model for IP Management (34 pages) RFC8348: A YANG Data Model for Hardware Management (60 pages) RFC8349: A YANG Data Model for Routing Management (NMDA Version) (80 pages) RFC8407: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models (63 pages) 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) Network File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2019-11-21 Current Status: Active Chairs: Brian Pawlowski David Noveck Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund 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: Mar 2021 - Request publication of RDMA Extensions for Enhanced Memory Placement Jul 2021 - Submit final document describing use of NVMe in accessing a pNFS SCSI Layout (as Proposed Standard) Dec 2021 - Submit final document defining RPC-over-RDMA Version 2 (as Proposed Standard) Internet-Drafts: - 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-00] (15 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) - 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) - 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) - Requirements for NFSv4.2 [draft-ietf-nfsv4-minorversion-2-requirements-00] (10 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 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) Remote Direct Memory Access (RDMA) Problem Statement [draft-ietf-nfsv4-nfs-rdma-problem-statement-08] (15 pages) - Network File System (NFS) Upper-Layer Binding To RPC-Over-RDMA Version 2 [draft-ietf-nfsv4-nfs-ulb-v2-03] (18 pages) - Network File System (NFS) Direct Data Placement [draft-ietf-nfsv4-nfsdirect-08] (10 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) - 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) - NFSv4.0 Migration: Specification Update [draft-ietf-nfsv4-rfc3530-migration-update-08] (55 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) - 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) - RPC-over-RDMA Version One Implementation Experience [draft-ietf-nfsv4-rfc5666-implementation-experience-03] (50 pages) - Remote Direct Memory Access Transport for Remote Procedure Call Version 1 [draft-ietf-nfsv4-rfc5666bis-11] (55 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) - Towards Remote Procedure Call Encryption By Default [draft-ietf-nfsv4-rpc-tls-09] (26 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-03] (88 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) - Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout [draft-ietf-nfsv4-scsi-layout-10] (30 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) 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) STD67: XDR: External Data Representation Standard (27 pages) Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2020-03-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: The Network Time Protocol (NTP) is widely deployed and used in the Internet. However, the standardization status of this protocol has lagged in the IETF. RFC 1305 (NTP version 3) was published in March 1992 and remains unchanged and at Draft Standard status. RFC 1305 represents the majority of full NTP implementations deployed today. RFC 2030 (SNTP version 4) was published as an Informational RFC in October 1996 as a lightweight version of NTP for deployments not requiring the full functionality of NTP. SNTP now represents the majority of both NTP traffic and NTP implementation issues on the Internet. A good deal of work has been produced in the NTP community updating both NTPv3 and SNTPv4. This work is ongoing and available through the collaborative development effort in the NTP community, but it has not been reflected back into the NTP specifications. The goal of this working group is to document NTPv4 based on the extensive work of the NTP community and to advance the standardization status of NTP. It is an explicit goal of this effort to have NTPv4 interoperate with the deployed base avoiding any backwards-incompatible changes. A number of topics have been raised as potential work items for an update to NTP including support for IPv6, security considerations including authentication, automatic configuration including possible requirements for DHCP, and algorithm improvements. This working group will focus first on delivering NTPv4 and will defer additional development efforts until after the delivery of NTPv4. Support for IPv6 and defining mechanisms for securing NTP transactions is considered part of the core NTPv4 functionality. Potential further modifications and additions to the NTP protocol will be documented for possible further work beyond the initial NTPv4 effort. The working group will initially focus on the following deliverables: 1. NTPv4 Scope and Requirements Document (documenting the scope of the NTPv4 update and identifying issues deferred for future work). 2. NTPv4 Protocol Specification (documenting the protocol on the wire) 3. NTPv4 Architecture and Algorithms Specification (documenting the architecture, mathematical algorithms, and behavior of NTP servers and clients) 4. NTPv4 MIB (provision for management and monitoring of NTP via SNMP) Goals and Milestones: Feb 2016 - WGLC for Network Time Security Feb 2016 - WGLC for Using the Network Time Security Specification to Secure the Network Time Protocol Feb 2016 - WGLC Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS) Apr 2016 - Publish UDP Checksum Complement in the Network Time Protocol (NTP) Apr 2016 - Publish The Network Time Protocol Version 4 (NTPv4) Extension Fields Apr 2016 - WGLC Network Time Protocol Best Current Practices Done - NTP BOF at IETF 61 Done - NTP WG Charter Approved Done - Draft of Scope and Requirements Document Done - Draft of NTP Protocol Specification Done - Draft of MIB Specification Done - Draft of NTP Algorithms Specification Done - Draft of NTP Autokey Specification - Informational RFC Done - WG Last Call NTP Protocol Specification Done - WG Last Call NTP MIB Specification Done - Draft of NTP Control Protocol - Informational RFC Done - WG Last Call NTP Autokey Specification - Informational RFC Done - WG Last Call NTP Control Protocol - Informational RFC Internet-Drafts: - On Implementing Time [draft-aanchal-time-implementation-guidance-02] (9 pages) - Message Authentication Codes for the Network Time Protocol [draft-aanchal4-ntp-mac-03] (12 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) - Port Randomization in the Network Time Protocol Version 4 [draft-gont-ntp-port-randomization-04] (10 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-00] (6 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 Version 4 [draft-ietf-ntp-chronos-01] (11 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-04] (13 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-10] (22 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) - Guidelines for Defining Packet Timestamps [draft-ietf-ntp-packet-timestamps-09] (17 pages) - Port Randomization in the Network Time Protocol Version 4 [draft-ietf-ntp-port-randomization-06] (10 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-03] (20 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-09] (54 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 Best Current Practices [draft-reilly-ntp-bcp-02] (18 pages) - Roughtime [draft-roughtime-aanchal-04] (17 pages) - A Secure Selection and Filtering Mechanism for the Network Time Protocol Version 4 [draft-schiff-ntp-chronos-03] (8 pages) - Network Time Protocol Extended Information Extension Field [draft-stenn-ntp-extended-information-04] (5 pages) - Network Time Protocol Version 4 (NTPv4) Extension Fields [draft-stenn-ntp-extension-fields-09] (13 pages) - Network Time Protocol I-Do Extension Field [draft-stenn-ntp-i-do-06] (7 pages) - Network Time Protocol IPv6 REFID Hash [draft-stenn-ntp-ipv6-refid-hash-00] (4 pages) - Network Time Protocol Last Extension Field [draft-stenn-ntp-last-extension-00] (4 pages) - Network Time Protocol Leap Smear REFID [draft-stenn-ntp-leap-smear-refid-02] (5 pages) - Network Time Protocol MAC/Last Extension Fields [draft-stenn-ntp-mac-last-ef-04] (8 pages) - Network Time Protocol Suggested REFID Extension Field [draft-stenn-ntp-suggest-refid-05] (7 pages) Requests for Comments: BCP223: Network Time Protocol Best Current Practices (26 pages) RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (110 pages) * Updates RFC7822 * Updates RFC8573 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) Network Virtualization Overlays (nvo3) -------------------------------------- Charter Last Modified: 2018-05-21 Current Status: Active Chairs: Matthew Bocci Sam Aldrin Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Tech Advisor: Ron Bonica Secretary: Li Yizhou 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 Solutions Submitted to IESG Mar 2020 - Security Requirements 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 - Architecture submitted for IESG review Done - Use Cases 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) - NVO3 Data Plane Requirements [draft-ietf-nvo3-dataplane-requirements-03] (18 pages) - NVO3 Encapsulation Considerations [draft-ietf-nvo3-encap-05] (19 pages) - Applicability of EVPN to NVO3 Networks [draft-ietf-nvo3-evpn-applicability-02] (26 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] (37 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) - Network-related VM Mobility Issues [draft-ietf-nvo3-vm-mobility-issues-03] (11 pages) - Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks [draft-ietf-nvo3-vmm-16] (17 pages) - Generic Protocol Extension for VXLAN (VXLAN-GPE) [draft-ietf-nvo3-vxlan-gpe-10] (22 pages) - Base YANG Data Model for NVO3 Protocols [draft-ietf-nvo3-yang-cfg-03] (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) Web Authorization Protocol (oauth) ---------------------------------- Charter Last Modified: 2019-03-30 Current Status: Active Chairs: Hannes Tschofenig Rifaat Shekh-Yusef Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw 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: Apr 2017 - Submit 'OAuth 2.0 Device Flow' to the IESG May 2017 - Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard Jul 2017 - Submit 'OAuth 2.0 Mix-Up Mitigation'to the IESG Jul 2017 - Submit 'OAuth 2.0 Security: Closing Open Redirectors in OAuth' to the IESG Jul 2017 - Submit 'OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution' to the IESG Jul 2017 - Submit 'A Method for Signing HTTP Requests for OAuth' to IESG Done - Submit 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture' to the IESG Done - Submit 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' 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 Internet-Drafts: - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [draft-ietf-oauth-access-token-jwt-10] (20 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) - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-01] (21 pages) - OAuth 2.0 for Browser-Based Apps [draft-ietf-oauth-browser-based-apps-07] (21 pages) - OAuth 2.0 Security: Closing Open Redirectors in OAuth [draft-ietf-oauth-closing-redirectors-00] (7 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 Demonstration of Proof-of-Possession at the Application Layer (DPoP) [draft-ietf-oauth-dpop-01] (22 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 2.0 Incremental Authorization [draft-ietf-oauth-incremental-authz-04] (11 pages) - OAuth 2.0 Token Introspection [draft-ietf-oauth-introspection-11] (17 pages) - JSON Web Token (JWT) [draft-ietf-oauth-json-web-token-32] (30 pages) - The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) [draft-ietf-oauth-jwsreq-30] (35 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-10] (20 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-04] (21 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-03] (35 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 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) - OAuth 2.0 Security Best Current Practice [draft-ietf-oauth-security-topics-16] (50 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) - 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) - 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-00] (85 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: BCP212: OAuth 2.0 for Native Apps (21 pages) BCP225: JSON Web Token Best Current Practices (13 pages) RFC6749: The OAuth 2.0 Authorization Framework (76 pages) * Updates RFC8252 RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (18 pages) 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) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2020-09-11 Current Status: Active Chairs: Henk Birkholz Joe Clarke Tianran Zhou Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Robert Wilton Mailing Lists: General Discussion: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: https://mailarchive.ietf.org/arch/browse/opsawg/ Description of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Templates and tools for Operations and Management Area Documents (B) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). (C) The RFC 5066 "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" has transitioned to the IEEE 802.3. However, as agreed with the IEEE, the IF-CAP- STACK-MIB MIB module (from RFC5066) is generic by nature and should continue to be supported by the IETF. The WG will develop a document extracting the IF-CAP-STACK-MIB from RFC5066, emphasizing the generic nature of this module, and obsolete RFC5066. (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with the corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions (mailing lists, reviews), and clarifications on the intellectual property considerations. Goals and Milestones: Oct 2012 - Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft Mar 2013 - Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational Done - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft Done - 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 - WGLC for the 'SNMP Engine ID Discovery' 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) - Survey of Possibilities for the Automated Configuration of Large IP Networks [draft-ietf-opsawg-automated-network-configuration-05] (23 pages) - Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-alt-tunnel-12] (29 pages) - CAPWAP Extension for 802.11n and Power/channel Autoconfiguration [draft-ietf-opsawg-capwap-extension-06] (17 pages) - IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-opsawg-capwap-hybridmac-08] (13 pages) - Management of Networks with Constrained Devices: Problem Statement and Requirements [draft-ietf-opsawg-coman-probstate-reqs-05] (44 pages) - Management of Networks with Constrained Devices: Use Cases [draft-ietf-opsawg-coman-use-cases-05] (26 pages) - A Template for Internet Drafts Containing Data Models [draft-ietf-opsawg-data-model-doc-template-00] (24 pages) - On Firewalls in Internet Security [draft-ietf-opsawg-firewalls-01] (10 pages) - HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-06] (14 pages) - HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 [draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05] (14 pages) - Export of BGP Community Information in IP Flow Information Export (IPFIX) [draft-ietf-opsawg-ipfix-bgp-community-12] (18 pages) - A Layer 2 VPN Network YANG Model [draft-ietf-opsawg-l2nm-00] (93 pages) - A Layer 3 VPN Network YANG Model [draft-ietf-opsawg-l3sm-l3nm-05] (105 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] (47 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) - Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices [draft-ietf-opsawg-mud-tls-02] (32 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-05] (37 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Tools [draft-ietf-opsawg-oam-overview-16] (53 pages) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-09] (35 pages) - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB [draft-ietf-opsawg-rfc5066bis-07] (6 pages) - Secure Device Install [draft-ietf-opsawg-sdi-13] (16 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) - Yang data model for TACACS+ [draft-ietf-opsawg-tacacs-yang-08] (16 pages) - Management Information Base for Virtual Machines Controlled by a Hypervisor [draft-ietf-opsawg-vmm-mib-04] (52 pages) - A Layer 2/3 VPN Common YANG Model [draft-ietf-opsawg-vpn-common-01] (41 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) Requests for Comments: BCP161: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) RFC5343: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) RFC5674: Alarms in Syslog (7 pages) RFC5675: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (15 pages) RFC5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (22 pages) RFC5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (35 pages) RFC5935: Expressing SNMP SMI Datatypes in XML Schema Definition Language (14 pages) RFC6291: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) RFC6340: Textual Conventions for the Representation of Floating-Point Numbers (7 pages) RFC6632: An Overview of the IETF Network Management Standards (85 pages) RFC7124: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB (6 pages) RFC7276: An Overview of Operations, Administration, and Maintenance (OAM) Tools (53 pages) RFC7289: Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs (20 pages) RFC7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks (29 pages) RFC7448: MIB Transfer from the IETF to the IEEE 802.3 WG (7 pages) RFC7494: IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) (13 pages) RFC7547: Management of Networks with Constrained Devices: Problem Statement and Requirements (44 pages) RFC7548: Management of Networks with Constrained Devices: Use Cases (26 pages) RFC7630: HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 (14 pages) * Obsoletes RFC7860 RFC7666: Management Information Base for Virtual Machines Controlled by a Hypervisor (52 pages) RFC7860: HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 (14 pages) RFC8309: Service Models Explained (23 pages) RFC8350: Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) (29 pages) RFC8512: A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) (94 pages) RFC8520: Manufacturer Usage Description Specification (60 pages) RFC8549: Export of BGP Community Information in IP Flow Information Export (IPFIX) (18 pages) RFC8886: Secure Device Install (16 pages) RFC8907: The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol (41 pages) STD78: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2019-04-05 Current Status: Active Chairs: Jen Linkova Ron Bonica Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Warren Kumari Mailing Lists: General Discussion: opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec Archive: https://mailarchive.ietf.org/arch/browse/opsec/ Description of Working Group: Goals: The OPSEC WG will document operational issues and best current practices with regard to network security. In particular, the working group will clarify the rationale of supporting current operational practice, addressing gaps in currently understood best practices and clarifying liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG includes the protection and secure operation of the forwarding, control and management planes. Documentation of operational issues, revision of existing operational security practices documents and proposals for new approaches to operational challenges related to network security are in scope. Method: The work will result in the publication of informational or BCP RFCs. Taxonomy or problem statement documents may provide a basis for such documents. Informational or Best Current Practices Documents For each topic addressed, the working group will produce a document that captures common practices related to secure network operation. This will be primarily based on operational experience. A document might convey: * a threat or threats to be addressed * current practices for addressing the threat * protocols, tools and technologies extant at the time of writing that are used to address the threat * the possibility that a solution does not exist within existing tools or technologies Taxonomy and Problem Statement Documents These are documents that describe the scope of particular operational security challenges or problem spaces without necessarily coming to conclusions or proposing solutions. Such a document might be the precursor to an informational or best current practices document. While the principal input of the working group is operational experience and needs, the output should be directed towards providing guidance to the operators community, other working groups that develop protocols or the protocol development community. Non-Goals: The OPSEC WG is will not write or modify protocols. New protocol work must be addressed through a working group chartered for that work, or via one of the individual submission processes. The OPSEC WG may take on documents related to the practices of using such work. Goals and Milestones: Dec 2012 - WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Dec 2012 - WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Dec 2012 - WG Adoption of 'Network Reconnaissance in IPv6 Networks' document Dec 2012 - WG Adoption of 'BGP operations and security' document Jan 2013 - WG Last Call for 'Operational Security Considerations for IPv6 Networks' document Jan 2013 - WG Last Call for 'Recommendations for filtering ICMP messages' document Jan 2013 - WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document Jan 2013 - WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document Mar 2013 - WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG Mar 2013 - Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG Mar 2013 - Submit 'Operational Security Considerations for IPv6 Networks' document to IESG Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG May 2013 - Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG Jul 2013 - WG Last Call for 'BGP operations and security' document Jul 2013 - WG Last Call for 'Network Reconnaissance in IPv6 Networks' document Jul 2013 - WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Jul 2013 - WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Sep 2013 - Submit 'BGP operations and security' document to IESG Sep 2013 - Submit 'Network Reconnaissance in IPv6 Networks' document to IESG Sep 2013 - Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG Done - Complete Charter Done - First draft of Framework Document as Internet Draft Done - First draft of Standards Survey Document as Internet Draft Done - First draft of Packet Filtering Capabilities Done - First draft of Event Logging Capabilities Done - First draft of Network Operator Current Security Practices Done - First draft of In-Band management capabilities Done - First draft of Out-of-Band management capabilities Done - First draft of Configuration and Management Interface Capabilities Done - Submit Network Operator Current Security Practices to IESG Internet-Drafts: - BGP Operations and Security [draft-ietf-opsec-bgp-security-07] (26 pages) - Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) [draft-ietf-opsec-blackhole-urpf-04] (15 pages) - Operational Security Current Practices in Internet Service Provider Environments [draft-ietf-opsec-current-practices-07] (37 pages) - DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers [draft-ietf-opsec-dhcpv6-shield-08] (12 pages) - Security Best Practices Efforts and Documents [draft-ietf-opsec-efforts-20] (41 pages) - Filtering and Rate Limiting Capabilities for IP Network Infrastructure [draft-ietf-opsec-filter-caps-09] (30 pages) - Framework for Operational Security Capabilities for IP Network Infrastructure [draft-ietf-opsec-framework-05] (29 pages) - Recommendations for filtering ICMP messages [draft-ietf-opsec-icmp-filtering-04] (58 pages) - Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-04] (11 pages) - Service Provider Infrastructure Security [draft-ietf-opsec-infrastructure-security-01] (17 pages) - Recommendations on Filtering of IPv4 Packets Containing IPv4 Options [draft-ietf-opsec-ip-options-filtering-07] (36 pages) - Security Assessment of the Internet Protocol Version 4 [draft-ietf-opsec-ip-security-07] (75 pages) - Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers [draft-ietf-opsec-ipv6-eh-filtering-06] (36 pages) - Network Reconnaissance in IPv6 Networks [draft-ietf-opsec-ipv6-host-scanning-08] (38 pages) - Security Implications of IPv6 on IPv4 Networks [draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07] (19 pages) - Security Assessment of Neighbor Discovery (ND) for IPv6 [draft-ietf-opsec-ipv6-nd-security-00] (62 pages) - Using Only Link-Local Addressing inside an IPv6 Network [draft-ietf-opsec-lla-only-11] (10 pages) - Logging Capabilities for IP Network Infrastructure [draft-ietf-opsec-logging-caps-04] (35 pages) - Miscellaneous Capabilities for IP Network Infrastructure [draft-ietf-opsec-misc-cap-00] (21 pages) - Network Management Access Security Capabilities [draft-ietf-opsec-nmasc-00] (13 pages) - Impact of TLS 1.3 to Operational Network Security Practices [draft-ietf-opsec-ns-impact-03] (18 pages) - Protecting the Router Control Plane [draft-ietf-opsec-protect-control-plane-06] (25 pages) - Routing Control Plane Security Capabilities [draft-ietf-opsec-routing-capabilities-03] (20 pages) - Issues with Existing Cryptographic Protection Methods for Routing Protocols [draft-ietf-opsec-routing-protocols-crypto-issues-07] (21 pages) - Enhanced Feasible-Path Unicast Reverse Path Forwarding [draft-ietf-opsec-urpf-improvements-04] (17 pages) - Operational Security Considerations for IPv6 Networks [draft-ietf-opsec-v6-21] (52 pages) - Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks [draft-ietf-opsec-vpn-leakages-06] (12 pages) - Enhanced Feasible-Path Unicast Reverse Path Filtering [draft-sriram-opsec-urpf-improvements-03] (15 pages) Requests for Comments: BCP186: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages) BCP194: BGP Operations and Security (26 pages) BCP199: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages) RFC4778: Operational Security Current Practices in Internet Service Provider Environments (37 pages) RFC5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) (15 pages) RFC6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols (21 pages) RFC6094: Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols (11 pages) RFC6192: Protecting the Router Control Plane (25 pages) RFC6274: Security Assessment of the Internet Protocol Version 4 (75 pages) RFC7123: Security Implications of IPv6 on IPv4 Networks (19 pages) RFC7126: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options (36 pages) RFC7359: Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks (12 pages) RFC7404: Using Only Link-Local Addressing inside an IPv6 Network (10 pages) RFC7454: BGP Operations and Security (26 pages) RFC7610: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers (12 pages) RFC7707: Network Reconnaissance in IPv6 Networks (38 pages) RFC8704: Enhanced Feasible-Path Unicast Reverse Path Forwarding (17 pages) Pseudowire And LDP-enabled Services (pals) ------------------------------------------ Charter Last Modified: 2018-05-11 Current Status: Active Chairs: Andrew G. Malis Stewart Bryant Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Dave Sinicrope Mailing Lists: General Discussion: pals@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pals Archive: https://mailarchive.ietf.org/arch/browse/pals/ Description of Working Group: Many services that run in the Internet are facilitated in MPLS networks by the Label Distribution Protocol (LDP) and/or are established over pseudowires that emulate point-to-point or point-to-multipoint links and provide communication connectivity that is perceived by its users as an unshared link or circuit of an emulated Layer-1, Layer-2, or Layer-3 service type. Layer-2 Virtual Private Networks (L2VPNs) are one such service that provides an emulation of a "native" service over a packet switched network that is adequately faithful to, but may not be entirely indistinguishable from, the native service itself. The Pseudowire And LDP-enabled Services (PALS) working group is chartered to define, specify, and extend network services based on pseudowires and/or signaled using LDP. In particular, the working group will work on the following services: - All types of MPLS-based and L2TPv3-based pseudowire services including point-to-point and point-to-multipoint pseudowires, single segment and multi-segment pseudowires, single and multi-domain pseudowires, and signaled and statically provisioned pseudowires. - All types of dynamic or static provider-provisioned L2VPNs that operate over pseudowires or that are enabled over MPLS networks using LDP as a control plane mechanism. - IP-only L2VPN solutions (for IP-only services over a packet switched network). The working group may also suggest new services to be supported by LDP or pseudowires and these may be added to the working group charter subject to re-chartering. The working group is also responsible for the maintenance and development of pseudowires formerly carried out by the PWE3 working group The PALS working group will not define any mechanisms that exert control over the underlying packet switched network. When necessary it may, however, recommend or require the use of existing QoS and path control mechanisms between the edge nodes that provide the connectivity to the services. The working group may work on: - New pseudowire encapsulations or types for services emulated over IETF-specified Packet Switched Networks. - Operations, Administration, and Management (OAM) for pseudowires including interworking of OAM for pseudowires and native services, and OAM for other services worked on by PALS (including L2VPNs). But new techniques should be shared with the BFD and MPLS working groups to ensure consistency with existing OAM techniques, and with the LIME working group to provide for consistency of operation. - Protocol extensions for LDP in support of new pseudowire function and new services, but all protocol extensions must be reviewed by the MPLS working group which is responsible for the consistency and stability of LDP. - Mechanisms to enhance pseudowire and L2VPN functionality by including security, protection and restoration, congestion avoidance, and load balancing across parallel packet switched tunnels. - Mechanisms to permit optimization of multicast data traffic within an L2VPN. - Enhancements to increase the scalability of the control plane and data plane of L2VPN solutions and application of L2VPN solutions in the data center, the latter in coordination with the NVO3 working group - L2VPN discovery and membership mechanisms that utilize pseudowire control and management procedures. - Data models for modeling, managing, and operating the services worked on by the PALS working group using SMI or YANG. The PALS working group will not work on L2VPNs enabled using BGP, and where L2VPNs that are within the scope of the PALS working group use BGP to add functionality (for example for discovery of membership of a VPN) this work will be coordinated with the BESS working group. This also includes work on particular types of L2VPNs that support both LDP and BGP signaling, such as VPLS. Any contention between these working groups on the placement of such work will be resolved by the chairs. The PALS working group will coordinate closely with the MPLS working group for all work involving LDP and the MPLS data plane. It will also coordinate with the MPLS working group in developing shared security, and with the BFD and MPLS working groups on OAM solutions. Where extensions to pseudowires are needed to support time or frequency transfer, this work will be done by the PALS working group in consultation with the TICTOC working group. L2TP specifics of L2TPv3-based pseudowires will continue to be the responsibility of the L2TPEXT working group. Goals and Milestones: Jun 2016 - Submit LDP-VPLS for Ethernet Broadcast and Multicast to the IESG Jun 2017 - Submit L2VPN applicability statement for data center applications to the IESG Done - Submit PW Congestion Considerations to the IESG Done - Submit STP Application of ICCP to the IESG Done - Submit Pseudowire Redundancy on S-PE to the IESG Done - Submit Unified Control Channel for PWs to the IESG Done - Submit MAC Address Withdrawal over Static Pseudowire to the IESG Done - Submit S-PE resilience for statically provisioned MS-PWs to the IESG Done - Submit LDP extensions for PW Binding to LSP Tunnels to the IESG Done - Submit 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 Work transferred to the BESS working group - Submit YANG data model for SS-PWs and MS-PWs to the IESG Internet-Drafts: - Use of Ethernet Control Word RECOMMENDED [draft-bryant-pals-ethernet-cw-01] (8 pages) - Seamless BFD for VCCV [draft-gp-pals-seamless-vccv-01] (10 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-l2vpn-ldp-vpls-broadcast-exten-08] (19 pages) - MAC Address Withdrawal over Static Pseudowire [draft-ietf-l2vpn-mpls-tp-mac-wd-00] (8 pages) - Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pe-etree-11] (26 pages) - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-l2vpn-vpls-pim-snooping-07] (39 pages) - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-04] (13 pages) - Pseudowire Congestion Considerations [draft-ietf-pals-congcons-02] (27 pages) - Pseudowire (PW) Endpoint Fast Failure Protection [draft-ietf-pals-endpoint-fast-protection-05] (43 pages) - Recommendation to Use the Ethernet Control Word [draft-ietf-pals-ethernet-cw-07] (9 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-pals-ldp-vpls-broadcast-exten-01] (19 pages) - Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS [draft-ietf-pals-mc-pon-05] (16 pages) - Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection [draft-ietf-pals-mpls-tp-dual-homing-coordination-06] (17 pages) - Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires [draft-ietf-pals-mpls-tp-dual-homing-protection-06] (11 pages) - Media Access Control (MAC) Address Withdrawal over Static Pseudowire [draft-ietf-pals-mpls-tp-mac-wd-03] (10 pages) - LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pals-mpls-tp-oam-config-03] (30 pages) - LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels [draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09] (16 pages) - Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires [draft-ietf-pals-ms-pw-protection-04] (9 pages) - Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP [draft-ietf-pals-p2mp-pw-04] (20 pages) - Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms [draft-ietf-pals-p2mp-pw-lsp-ping-05] (10 pages) - Pseudowire Redundancy on the Switching Provider Edge (S-PE) [draft-ietf-pals-redundancy-spe-03] (9 pages) - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) [draft-ietf-pals-rfc4447bis-05] (35 pages) - Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) [draft-ietf-pals-seamless-vccv-03] (11 pages) - MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs [draft-ietf-pals-status-reduction-05] (20 pages) - Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator [draft-ietf-pals-vccv-for-gal-06] (9 pages) - Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) [draft-ietf-pals-vpls-pim-snooping-06] (43 pages) - Pseudowire Congestion Considerations [draft-ietf-pwe3-congcons-02] (22 pages) - PW Endpoint Fast Failure Protection [draft-ietf-pwe3-endpoint-fast-protection-02] (29 pages) - Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) [draft-ietf-pwe3-iccp-stp-05] (25 pages) - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pwe3-mpls-tp-oam-config-01] (23 pages) - LDP extensions for Pseudowire Binding to LSP Tunnels [draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-03] (15 pages) - Pseudowire Redundancy on S-PE [draft-ietf-pwe3-redundancy-spe-03] (8 pages) - Pseudowire Setup and Maintenance using the Label Distribution Protocol [draft-ietf-pwe3-rfc4447bis-03] (32 pages) - A Unified Control Channel for Pseudowires [draft-ietf-pwe3-vccv-for-gal-02] (9 pages) - Definition of P2MP PW TLV for LSP-Ping Mechanisms [draft-jain-pwe3-p2mp-pw-lsp-ping-03] (8 pages) Requests for Comments: RFC7708: Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator (9 pages) RFC7727: Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) (25 pages) RFC7769: Media Access Control (MAC) Address Withdrawal over Static Pseudowire (10 pages) RFC7771: Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires (9 pages) RFC7795: Pseudowire Redundancy on the Switching Provider Edge (S-PE) (9 pages) RFC7796: Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) (26 pages) RFC7885: Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) (11 pages) RFC7893: Pseudowire Congestion Considerations (27 pages) RFC7965: LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels (16 pages) RFC8024: Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS (16 pages) RFC8077: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) RFC8104: Pseudowire (PW) Endpoint Fast Failure Protection (43 pages) RFC8184: Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires (11 pages) RFC8185: Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection (17 pages) RFC8220: Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) (43 pages) RFC8237: MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs (20 pages) RFC8338: Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP (20 pages) RFC8339: Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms (10 pages) RFC8469: Recommendation to Use the Ethernet Control Word (9 pages) STD84: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) Path Computation Element (pce) ------------------------------ Charter Last Modified: 2019-09-11 Current Status: Active Chairs: Dhruv Dhody Julien Meuric Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Secretary: Hariharan Ananthakrishnan Mailing Lists: General Discussion: pce@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/pce Archive: https://mailarchive.ietf.org/arch/browse/pce/ Description of Working Group: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may not be physically located on each head-end LSR. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. The PCE WG works on the application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between Path Computation Clients (PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g., RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS protocols specified in the CCAMP and TEAS WGs. Work Items: - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP path computation models involving PCEs. This includes the case of computing the paths of intra- and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. - Definition of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where receiving PCC/PCE chooses to not follow the recommendation. Goals and Milestones: Feb 2015 - Evaluate WG progress, recharter or close Done - Submit first draft of PCE architecture document Done - Submit first draft of PCE discovery requirements and protocol extensions documents Done - Submit first draft of the PCE communication protocol requirements Done - Submit first draft of the definition of objective metrics Done - Submit first draft of the PCE communication protocol specification Done - Submit PCE architecture specification to the IESG to be considered as Informational RFC Done - Submit first draft of the MIB module for the PCE protocol Done - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done - Submit first draft of the PCE P2MP communication requirements Done - Submit first draft of the PCE P2MP PCEP protocol extensions Done - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done - Submit applicability and metrics documents to the IESG Done - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Done - Submit inter-area/AS applicability statement to the IESG as an informational RFC Done - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Done - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Done - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Done - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Done - Submit the stateful PCE document(s) to the IESG Internet-Drafts: - Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup [draft-ali-pce-remote-initiated-gmpls-lsp-03] (9 pages) - PCEP extension to support Segment Routing Policy Candidate Paths [draft-barth-pce-segment-routing-policy-cp-06] (20 pages) - Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP) [draft-dhody-pce-pcep-exp-codepoints-03] (6 pages) - PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE [draft-dhody-pce-stateful-pce-auto-bandwidth-09] (25 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) - 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) - PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) [draft-ietf-pce-association-bidir-08] (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 (PCE) Communication Protocol (PCEP) extension for associating Policies and Label Switched Paths (LSPs) [draft-ietf-pce-association-policy-13] (17 pages) - Carrying Binding Label/Segment-ID in PCE-based Networks. [draft-ietf-pce-binding-label-sid-03] (16 pages) - A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-brpc-09] (18 pages) - Path Computation Element (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (21 pages) - Definitions of Managed Objects for Path Computation Element Discovery [draft-ietf-pce-disc-mib-04] (24 pages) - IGP protocol extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-igp-02] (37 pages) - IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-isis-08] (17 pages) - OSPF Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-ospf-08] (20 pages) - Requirements for Path Computation Element (PCE) Discovery [draft-ietf-pce-discovery-reqs-05] (19 pages) - Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol [draft-ietf-pce-dste-02] (9 pages) - Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications [draft-ietf-pce-enhanced-errors-08] (23 pages) - PCEP Extension for Flexible Grid Networks [draft-ietf-pce-flexible-grid-04] (19 pages) - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization [draft-ietf-pce-global-concurrent-optimization-10] (26 pages) - Requirements for GMPLS Applications of PCE [draft-ietf-pce-gmpls-aps-req-09] (12 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS [draft-ietf-pce-gmpls-pcep-extensions-16] (38 pages) - Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture [draft-ietf-pce-hierarchy-extensions-11] (27 pages) - The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS [draft-ietf-pce-hierarchy-fwk-05] (33 pages) - Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-area-as-applicability-08] (24 pages) - 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) - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) [draft-ietf-pce-interas-pcecp-reqs-06] (14 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) - 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) - 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) - 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 (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model [draft-ietf-pce-pce-initiated-lsp-11] (20 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 (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-19] (87 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) - PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs [draft-ietf-pce-pcep-extension-for-pce-controller-07] (35 pages) - PCEP Extension for Native IP Network [draft-ietf-pce-pcep-extension-native-ip-09] (24 pages) - PCEP Extension for Flow Specification [draft-ietf-pce-pcep-flowspec-11] (37 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) - 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) - 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) - Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks [draft-ietf-pce-pcep-stateful-pce-gmpls-13] (19 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-14] (113 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) - 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) - PCEP Extensions for Segment Routing leveraging the IPv6 data plane [draft-ietf-pce-segment-routing-ipv6-06] (22 pages) - PCEP extension to support Segment Routing Policy Candidate Paths [draft-ietf-pce-segment-routing-policy-cp-01] (20 pages) - PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths [draft-ietf-pce-sr-bidir-path-03] (18 pages) - Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) [draft-ietf-pce-sr-path-segment-01] (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) - 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) - PCEP Extensions for LSP scheduling with stateful PCE [draft-ietf-pce-stateful-pce-lsp-scheduling-27] (26 pages) - Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-pce-stateful-pce-p2mp-13] (33 pages) - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE [draft-ietf-pce-stateful-sync-optimizations-10] (26 pages) - 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 LSPs and Virtual Networks [draft-ietf-pce-vn-association-03] (14 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) - Extensions to the Path Computation Element Protocol (PCEP) for residual path bandwidth support [draft-lazzeri-pce-residual-bw-01] (16 pages) - PCEP Extension for Flexible Grid Networks [draft-lee-pce-flexible-grid-03] (20 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 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) - 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) - 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) 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) RFC5089: IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (17 pages) RFC5376: Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) (14 pages) RFC5394: Policy-Enabled Path Computation Framework (36 pages) RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP) (87 pages) * Updates RFC7896 * Updates RFC8253 * Updates RFC8356 RFC5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths (18 pages) RFC5455: Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol (9 pages) RFC5520: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism (19 pages) RFC5521: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions (16 pages) RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (23 pages) RFC5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization (26 pages) RFC5623: Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (34 pages) RFC5671: Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) (15 pages) RFC5862: Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE (11 pages) RFC5886: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture (26 pages) RFC6006: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (33 pages) * Obsoletes RFC8306 RFC6007: Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations (18 pages) RFC6123: Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts (13 pages) RFC6457: PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (12 pages) RFC6805: The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS (33 pages) RFC7025: Requirements for GMPLS Applications of PCE (12 pages) RFC7150: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (12 pages) * Obsoletes RFC7470 RFC7334: PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths (25 pages) RFC7399: Unanswered Questions in the Path Computation Element Architecture (29 pages) RFC7420: Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module (65 pages) RFC7449: Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (12 pages) RFC7470: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol (14 pages) RFC7896: Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) (5 pages) RFC7897: Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) (35 pages) RFC8051: Applicability of a Stateful Path Computation Element (PCE) (24 pages) RFC8231: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE (57 pages) * Updates RFC8786 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) 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) Privacy Enhanced RTP Conferencing (perc) ---------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Nils Ohlmeier Suhas Nandakumar Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Murray Kucherawy Mailing Lists: General Discussion: perc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/perc Archive: https://mailarchive.ietf.org/arch/browse/perc/ Description of Working Group: RTP-based real-time multi-party interactive media conferencing is in widespread use today. Many of the deployments use one or more centrally located media distribution devices that perform selective forwarding of mixed-media streams received from the participating endpoints. The media transport protocol commonly used is RTP (RFC3550). There are various signaling systems used to establish these multi-party conferences. These conferences require security to ensure that the RTP media and related metadata of the conference is kept private and only available to the set of invited participants and other devices trusted by those participants with their media. At the same time, multi-party media conferences need source authentication and integrity checks to protect against modifications, insertions, and replay attacks. Media distribution devices supporting these conferences may also perform RTP header changes, and they often consume and create RTCP messages for efficient media handling. To date, deployment models for these multi-party media distribution devices do not enable the devices to perform their functions without having keys to decrypt the participants' media, primarily using Secure RTP (RFC3711) to provide session security. This trust model has limitations and prevents or hampers deployment of secure RTP conferencing in a multitude of cases, including outsourcing, legal requirements on confidentiality, and utilization of virtualized servers. Thus, a new architectural model and related specifications are needed, with a focused effort from the RTP and Security communities. WG Objectives This WG will work on a solution that enables centralized SRTP-based conferencing, where the central device distributing the media is not required to be trusted with the keys to decrypt the participants' media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. The meta information provided to the central device is to be limited to the minimal required for it to perform its function to preserve the conference participants privacy. Further, it is desired that a solution still provides replay protection, so that the media distribution devices cannot replay previous parts of the media. The solution must also provide security for each hop between endpoints and multi-party media distribution devices and between multi-party media distribution devices. The RTCP messages and RTP header extensions required for the media distribution device to perform the selective media forwarding may require both source authentication and integrity as well as confidentiality. The solution may also consider providing end-to-end security for a subset of the RTCP messages or RTP header extensions. The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints (draft-ietf-rtcweb-overview). How telepresence endpoints using the protocols defined in the CLUE working group could utilize the defined security solution needs to be considered. However, it is acknowledged that limitations may exist, resulting in restricted functionality or need for additional adaptations of the CLUE protocols. This working group will perform the following work: 1. Define a general architecture and RTP topology(s) that enables end-to-end media security for multi-party RTP conferencing. 2. Define the trust model and describe the resulting security properties. 3. Document models considered for integrating the solution with WebRTC, SIP and CLUE establishment of conferencing sessions. 4. Specify any necessary extensions to SRTP. 5. Define needed Key Management Functions that distribute the keys. The system needs to be able to bind the media to the identity of the sender of the media and/or the identity of the conference. Collaboration If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. Potential items that might require work in other WGs are DTLS extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong collaboration with the security area. We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work. Non-Goals The PERC working group is not chartered to extend any signaling system used to establish the RTP-based conferences. It will, however, need to consider in its architecture how the solution may integrate with these systems, and document such consideration for WebRTC, SIP, and CLUE. The specification of how a particular system integrates the security solution will happen outside of this working group, in suitable venues. The WG will not consider non-real-time usage, multicast-based media distribution, or Security descriptions-based keying (RFC4568). Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ Goals and Milestones: Dec 2017 - Submit SRTP protocol extension specification to IESG (Standards Track) Dec 2017 - Submit Key-management protocol specification to IESG (Standards Track) Mar 2018 - Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational) Done - Submit encrypted key transport specification to IESG (Standards Track) Done - Submit architecture or framework specification to IESG (Standards Track) Internet-Drafts: - Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-perc-double-12] (18 pages) - DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange [draft-ietf-perc-dtls-tunnel-06] (17 pages) - A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC) [draft-ietf-perc-private-media-framework-12] (28 pages) - Encrypted Key Transport for DTLS and Secure RTP [draft-ietf-perc-srtp-ekt-diet-13] (25 pages) Requests for Comments: RFC8723: Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) (18 pages) Protocols for IP Multicast (pim) -------------------------------- Charter Last Modified: 2018-07-12 Current Status: Active Chairs: Mike McBride Stig Venaas Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana 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 - igmp yang model submitted to iesg Nov 2015 - mld 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: - Anycast-RP Using Protocol Independent Multicast (PIM) [draft-ietf-pim-anycast-rp-07] (12 pages) - PIM Assert Message Packing [draft-ietf-pim-assert-packing-00] (13 pages) - Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Protocol Independent Multicast - Sparse Mode (PIM-SM) Use Case [draft-ietf-pim-bfd-p2mp-use-case-04] (8 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-10] (11 pages) - PIM Designated Router Load Balancing [draft-ietf-pim-drlb-15] (18 pages) - Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect [draft-ietf-pim-ecmp-05] (12 pages) - Explicit Reverse Path Forwarding (RPF) Vector [draft-ietf-pim-explicit-rpf-vector-09] (9 pages) - IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers [draft-ietf-pim-explicit-tracking-13] (11 pages) - PIM Group-to-Rendezvous-Point Mapping [draft-ietf-pim-group-rp-mapping-10] (11 pages) - PIM Neighbor Hello GenId Option [draft-ietf-pim-hello-genid-01] (3 pages) - An Interface Identifier (ID) Hello Option for PIM [draft-ietf-pim-hello-intid-01] (6 pages) - Hierarchical Join/Prune Attributes [draft-ietf-pim-hierarchicaljoinattr-08] (8 pages) - IGMPv3/MLDv2 Message Extension [draft-ietf-pim-igmp-mld-extension-01] (11 pages) - A Yang Data Model for IGMP/MLD Proxy [draft-ietf-pim-igmp-mld-proxy-yang-03] (16 pages) - A Yang Data Model for IGMP and MLD Snooping [draft-ietf-pim-igmp-mld-snooping-yang-18] (47 pages) - IGMP/MLD Optimizations in Wireless and Mobile Networks [draft-ietf-pim-igmp-mld-wireless-mobile-00] (13 pages) - A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) [draft-ietf-pim-igmp-mld-yang-15] (45 pages) - Use of PIM Address List Hello across address families [draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02] (5 pages) - Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) [draft-ietf-pim-ipv6-04] (5 pages) - The Protocol Independent Multicast (PIM) Join Attribute Format [draft-ietf-pim-join-attributes-06] (10 pages) - PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments [draft-ietf-pim-join-attributes-for-lisp-06] (9 pages) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (12 pages) - Protocol Independent Multicast MIB [draft-ietf-pim-mib-v2-10] (90 pages) - A YANG Data Model for Multicast Source Discovery Protocol (MSDP) [draft-ietf-pim-msdp-yang-18] (35 pages) - PIM Multi-Topology ID (MT-ID) Join Attribute [draft-ietf-pim-mtid-10] (13 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-05] (8 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) - Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments [draft-ietf-pim-rfc4601-update-survey-report-03] (12 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-rfc4601bis-06] (137 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-00] (16 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) - A YANG Data Model for Protocol Independent Multicast (PIM) [draft-ietf-pim-yang-17] (106 pages) Requests for Comments: RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (61 pages) * Updates RFC8736 RFC4601: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (150 pages) * Updates RFC5059 * Updates RFC5796 * Updates RFC6226 * Obsoletes RFC7761 RFC4602: Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis (8 pages) RFC4610: Anycast-RP Using Protocol Independent Multicast (PIM) (12 pages) RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM) (43 pages) * Updates RFC8736 RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (42 pages) * Updates RFC8736 RFC5060: Protocol Independent Multicast MIB (90 pages) RFC5240: Protocol Independent Multicast (PIM) Bootstrap Router MIB (23 pages) RFC5294: Host Threats to Protocol Independent Multicast (PIM) (12 pages) RFC5384: The Protocol Independent Multicast (PIM) Join Attribute Format (10 pages) * Updates RFC7887 RFC5496: The Reverse Path Forwarding (RPF) Vector TLV (8 pages) RFC5796: Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages (21 pages) RFC6166: A Registry for PIM Message Types (4 pages) * Obsoletes RFC8736 RFC6226: PIM Group-to-Rendezvous-Point Mapping (11 pages) RFC6395: An Interface Identifier (ID) Hello Option for PIM (6 pages) RFC6420: PIM Multi-Topology ID (MT-ID) Join Attribute (13 pages) RFC6559: A Reliable Transport Mechanism for PIM (29 pages) RFC6754: Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect (12 pages) * Updates RFC8736 RFC6807: Population Count Extensions to Protocol Independent Multicast (PIM) (15 pages) RFC7063: Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments (12 pages) RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages) * Updates RFC8736 RFC7887: Hierarchical Join/Prune Attributes (8 pages) RFC7891: Explicit Reverse Path Forwarding (RPF) Vector (9 pages) RFC8059: PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments (9 pages) RFC8364: PIM Flooding Mechanism (PFM) and Source Discovery (SD) (18 pages) * Updates RFC8736 RFC8652: A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) (45 pages) RFC8736: PIM Message Type Space Extension and Reserved Bits (8 pages) RFC8775: PIM Designated Router Load Balancing (18 pages) STD83: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (137 pages) Privacy Pass (privacypass) -------------------------- Charter Last Modified: 2020-09-10 Current Status: Active Chairs: Benjamin M. Schwartz Joseph A. Salowey Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: privacy-pass@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/privacy-pass Archive: https://mailarchive.ietf.org/arch/browse/privacy-pass/ Description of Working Group: The Privacy Pass protocol provides a performant, application-layer mechanism for token creation and anonymous redemption. Servers (Issuers) create and later verify tokens that are redeemed by an ecosystem of clients, such that: - An Issuer cannot link a redeemed token to one of N previously created tokens using the same key with probability non-negligibly larger than 1/N. - Clients can verify that a token created by an Issuer corresponds to a committed keypair. - Tokens are unforgeable. - The token issuance and redemption mechanisms are efficient. The primary purpose of the Privacy Pass Working Group is to develop and standardize a protocol that meets these requirements, influenced by applications that have arisen from the wider community. The aims of the Working Group can be split into three distinct goals: First, specify an extensible protocol for creating and redeeming anonymous and transferrable tokens. The protocol should permit suitable cryptographic ciphersuites and security parameterization for cryptographic agility. The cryptographic profile used by the protocol participants will be determined by the specific instantiation of the protocol, and it will be fixed for the duration of an Issuer's committed keypair. We will work closely with the CFRG in determining acceptable cryptographic ciphersuites and parameters that satisfy the security and privacy properties of the protocol. The Working Group will specify a preliminary set of extensions, including Issuer-supplied metadata and cryptographic instantiations that additionally support public verifiability of Issued tokens, and may consider any additional extensions that arise in the future. Security and privacy properties of the protocol shall be well-documented. Formal analysis of the protocol will ensure that the security and privacy properties of the protocol are well-understood and well-documented. Second, describe and develop protocol use cases and properties thereof. This includes, though is not limited to: 1. Describing use cases and interfaces that allow the protocol to be used for those use cases. 2. Defining the privacy goals for each Client during protocol execution, along with expectations placed on the Issuers and the ecosystem at large. 3. Describing recommended parameterization(s) of variables associated with the protocol ecosystem that control the size of the anonymity set that the client belongs to. 4. Describing verification mechanisms for trusting Issuers and their corresponding keying material. Such mechanisms should prevent Issuers from presenting any key material that could be used to deanonymize clients. 5. Describing the procedure for including small amounts of metadata with Issued tokens, as well as the associated impacts on privacy. 6. Describing the risk and possible ramifications of Issuer centralization, and exploring possible mechanisms to mitigate these risks. Third, and finally, specify a HTTP-layer API for the protocol. This includes a common understanding of how Privacy Pass is integrated with HTTP requests and responses for web-based applications. The following milestones (along with the approximate dates of completion) will be used to judge the progress of the working group: - Specification of protocol & surrounding architecture - February 2021. - Risk assessment for centralization in Privacy Pass deployments for multiple design options - February 2021 - Specification of application-layer requirements (including HTTP integration) - June 2021. - Specification of HTTP browser API (in coordination with W3C) - October 2021. Note that the specifications developed by this working group will be informed by the following initial drafts: - draft-davidson-pp-protocol-00; - draft-davidson-pp-architecture-00; - draft-svaldez-pp-http-api-00. These existing drafts may be further developed into the core deliverables of the working group, supplemented by any additional extensions. Alternatively, they may contribute indirectly to a future set of documents that meet the core goals of the working group. Goals and Milestones: Internet-Drafts: - Privacy Pass: Architectural Framework [draft-davidson-pp-architecture-01] (22 pages) - Privacy Pass: The Protocol [draft-davidson-pp-protocol-01] (20 pages) - Privacy Pass: HTTP API [draft-svaldez-pp-http-api-01] (12 pages) No Requests for Comments QUIC (quic) ----------- Charter Last Modified: 2020-10-12 Current Status: Active Chairs: Lars Eggert Lucas Pardue Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: quic@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Description of Working Group: The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience. Key goals for QUIC are: - Minimizing connection establishment and overall transport latency for applications, starting with HTTP; - Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default. The work of the group will have five main focus areas, corresponding to five core deliverables. The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, and options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features. The second of these focus areas is security. This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath). The third focus area describes the mapping between the HTTP application protocol and the transport facilities of QUIC. This mapping will have performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to define additional mappings may be included by updates to this charter, or may be worked on by other working groups. The fourth focus area will be on extensions to core protocol facilities, to enable datagram delivery, version negotiation, and multipath capabilities. Other extensions are out of the scope of this charter. The fifth focus area will provide an Applicability and Manageability Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers. Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. The QUIC working group will work closely with the HTTPbis working group, especially on the QUIC mapping for HTTP. Goals and Milestones: Jul 2020 - QUIC Applicability and Manageability Statement to IESG Dec 2020 - Working group adoption of Multipath extension document Mar 2021 - Datagram Extension to IESG Mar 2021 - Version Negotiation Extension to IESG Mar 2021 - QUIC-LB: Generating Routable QUIC Connection IDs to IESG Dec 2021 - Multipath extension document to IESG Done - Core Protocol document to IESG Done - Loss detection and Congestion Control document to IESG Done - TLS 1.3 Mapping document to IESG Done - HTTP/2 mapping document to IESG Done - Version-Independent Properties of QUIC to IESG Done - QPACK: Header Compression for HTTP over QUIC to IESG Internet-Drafts: - QUIC-LB: Generating Routable QUIC Connection IDs [draft-duke-quic-load-balancers-06] (31 pages) - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-hamilton-quic-transport-protocol-01] (45 pages) - Applicability of the QUIC Transport Protocol [draft-ietf-quic-applicability-07] (17 pages) - An Unreliable Datagram Extension to QUIC [draft-ietf-quic-datagram-01] (9 pages) - Hypertext Transfer Protocol Version 3 (HTTP/3) [draft-ietf-quic-http-32] (73 pages) - Version-Independent Properties of QUIC [draft-ietf-quic-invariants-11] (10 pages) - QUIC-LB: Generating Routable QUIC Connection IDs [draft-ietf-quic-load-balancers-04] (30 pages) - Manageability of the QUIC Transport Protocol [draft-ietf-quic-manageability-07] (23 pages) - Header Compression for HTTP over QUIC [draft-ietf-quic-qcram-00] (11 pages) - QPACK: Header Compression for HTTP/3 [draft-ietf-quic-qpack-19] (49 pages) - QUIC Loss Detection and Congestion Control [draft-ietf-quic-recovery-32] (52 pages) - The QUIC Latency Spin Bit [draft-ietf-quic-spin-exp-01] (8 pages) - Using TLS to Secure QUIC [draft-ietf-quic-tls-32] (64 pages) - QUIC: A UDP-Based Multiplexed and Secure Transport [draft-ietf-quic-transport-32] (200 pages) - QUIC Version Aliasing [draft-ietf-quic-version-aliasing-00] (11 pages) - Compatible Version Negotiation for QUIC [draft-ietf-quic-version-negotiation-01] (8 pages) - QUIC Congestion Control And Loss Recovery [draft-iyengar-quic-loss-recovery-01] (10 pages) - Header Compression for HTTP over QUIC [draft-krasic-quic-qcram-04] (9 pages) - Applicability of the QUIC Transport Protocol [draft-kuehlewind-quic-applicability-00] (7 pages) - Manageability of the QUIC Transport Protocol [draft-kuehlewind-quic-manageability-00] (10 pages) - An Unreliable Datagram Extension to QUIC [draft-pauly-quic-datagram-05] (9 pages) - Compatible Version Negotiation for QUIC [draft-schinazi-quic-version-negotiation-02] (8 pages) - HTTP/2 Semantics Using The QUIC Transport Protocol [draft-shade-quic-http2-mapping-00] (11 pages) - Version-Independent Properties of QUIC [draft-thomson-quic-invariants-00] (9 pages) - Using Transport Layer Security (TLS) to Secure QUIC [draft-thomson-quic-tls-01] (22 pages) No Requests for Comments RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2018-04-10 Current Status: Active Chairs: Lionel Morand Stefan Winter Operations and Management Area Directors: Warren Kumari Robert Wilton Operations and Management Area Advisor: Benjamin Kaduk Mailing Lists: General Discussion: radext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/radext Archive: https://mailarchive.ietf.org/arch/browse/radext/ Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director and clarify its usage and definition. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restriction is imposed on extensions considered by the RADEXT WG: All documents produced must specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. The WG will review its existing RFCs' document track categories and where necessary or useful change document tracks, with minor changes in the documents if needed. Any changes to document tracks require approval by the responsible Area Director. Work Items The immediate goals of the RADEXT working group are to address the following issues: - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect messages, but makes no provisions for how that is done in a roaming environment. This work item will provide descriptions of how to use the Operator-Name attribute in a roaming environment to proxy CoA packets in a way that ensures only authorized proxies can send these packets to the home CoA server. - Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character encoding and normalisation rules for EAP Identity responses. RADIUS (RFC2865) requires User-Name attributes to be encoded in UTF-8. When a NAS simply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced. This document will suggest restrictions on EAP Identities so that transport over AAA becomes correct under all circumstances (UTF-8) and deterministic (normalisation). - Data Types. RFC 2865 defines a number of data types, but later documents do not use those types in a consistent way. This work item will define data types, and update the IANA RADIUS Attribute Type registry so that each attribute has a data type. Where necessary, it will correct issues with previous specifications. - Larger Packets. Support RADIUS packets greater than 4096-octets over RADIUS transports with this capability. - RADIUS Attributes for IP Port Configuration and Reporting. These attributes are used by devices that implement IP port ranges to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behaviors. These attributes can be used in the context of address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333], CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.). Goals and Milestones: Nov 2015 - Larger Packets for RADIUS over TCP I-D submitted as an Experimental RFC Nov 2015 - Submit CoA Proxying as Standards Track RFC Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC Nov 2016 - Submit Populating EAP Identity as BCP RFC Nov 2016 - Data Types as Informational RFC Done - RFC 4282bis submitted as a Proposed Standard RFC Done - Dynamic Discovery I-D submitted as a Proposed Standard RFC Done - RADIUS packet fragmentation submitted as an Experimental RFC Internet-Drafts: - Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) [draft-dekok-radext-coa-proxy-00] (10 pages) - Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) [draft-dekok-radext-datatypes-06] (32 pages) - The Network Access Identifier [draft-dekok-radext-nai-02] (19 pages) - Larger Packets for RADIUS over TCP [draft-ietf-radext-bigger-packets-07] (10 pages) - Chargeable User Identity [draft-ietf-radext-chargeable-user-id-06] (10 pages) - Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol [draft-ietf-radext-coa-proxy-10] (21 pages) - Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) [draft-ietf-radext-crypto-agility-requirements-07] (12 pages) - Data Types in RADIUS [draft-ietf-radext-datatypes-08] (35 pages) - RADIUS Delegated-IPv6-Prefix Attribute [draft-ietf-radext-delegated-prefix-05] (7 pages) - RADIUS Design Guidelines [draft-ietf-radext-design-19] (38 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-digest-auth-09] (32 pages) - Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS [draft-ietf-radext-dtls-13] (27 pages) - Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) [draft-ietf-radext-dynamic-discovery-15] (32 pages) - RADIUS Dynamic Authorization Client MIB [draft-ietf-radext-dynauth-client-mib-06] (24 pages) - RADIUS Dynamic Authorization Server MIB [draft-ietf-radext-dynauth-server-mib-06] (24 pages) - Extended Remote Authentication Dial In User Service (RADIUS) Attributes [draft-ietf-radext-extended-attributes-09] (13 pages) - RADIUS Filter Rule Attribute [draft-ietf-radext-filter-08] (9 pages) - RADIUS Attributes for Filtering and Redirection [draft-ietf-radext-filter-rules-03] (30 pages) - Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes [draft-ietf-radext-fixes-08] (28 pages) - VLAN, Priority, and Filtering Attributes [draft-ietf-radext-ieee802-01] (32 pages) - RADIUS Attributes for IEEE 802 Networks [draft-ietf-radext-ieee802ext-12] (29 pages) - RADIUS Extensions for IP Port Configuration and Reporting [draft-ietf-radext-ip-port-radius-ext-17] (43 pages) - RADIUS Attributes for IPv6 Access Networks [draft-ietf-radext-ipv6-access-16] (15 pages) - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management [draft-ietf-radext-management-authorization-07] (25 pages) - The Network Access Identifier [draft-ietf-radext-nai-15] (30 pages) - Considerations regarding the correct use of EAP-Response/Identity [draft-ietf-radext-populating-eapidentity-01] (10 pages) - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions [draft-ietf-radext-radius-extensions-13] (68 pages) - Support of Fragmentation of RADIUS Packets [draft-ietf-radext-radius-fragmentation-12] (38 pages) - Transport Layer Security (TLS) Encryption for RADIUS [draft-ietf-radext-radsec-12] (22 pages) - The Network Access Identifier [draft-ietf-radext-rfc2486bis-06] (16 pages) - RADIUS Authentication Client MIB for IPv6 [draft-ietf-radext-rfc2618bis-04] (24 pages) - RADIUS Authentication Server MIB for IPv6 [draft-ietf-radext-rfc2619bis-04] (25 pages) - RADIUS Accounting Client MIB for IPv6 [draft-ietf-radext-rfc2620bis-04] (23 pages) - RADIUS Accounting Server MIB for IPv6 [draft-ietf-radext-rfc2621bis-04] (24 pages) - Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) [draft-ietf-radext-rfc3576bis-13] (34 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-rfc4590bis-02] (33 pages) - Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol [draft-ietf-radext-status-server-09] (24 pages) - RADIUS over TCP [draft-ietf-radext-tcp-transport-09] (16 pages) - New Tunnel-Type Values [draft-ietf-radext-tunnel-type-00] (6 pages) - RADIUS Attributes for Virtual LAN and Priority Support [draft-ietf-radext-vlan-06] (15 pages) - Considerations regarding the correct use of EAP-Response/Identity [draft-winter-radext-populating-eapidentity-01] (7 pages) Requests for Comments: BCP158: RADIUS Design Guidelines (38 pages) RFC4282: The Network Access Identifier (16 pages) * Obsoletes RFC7542 RFC4372: Chargeable User Identity (10 pages) RFC4590: RADIUS Extension for Digest Authentication (32 pages) * Obsoletes RFC5090 RFC4668: RADIUS Authentication Client MIB for IPv6 (24 pages) RFC4669: RADIUS Authentication Server MIB for IPv6 (25 pages) RFC4670: RADIUS Accounting Client MIB for IPv6 (23 pages) RFC4671: RADIUS Accounting Server MIB for IPv6 (24 pages) RFC4672: RADIUS Dynamic Authorization Client MIB (24 pages) RFC4673: RADIUS Dynamic Authorization Server MIB (24 pages) RFC4675: RADIUS Attributes for Virtual LAN and Priority Support (15 pages) RFC4818: RADIUS Delegated-IPv6-Prefix Attribute (7 pages) RFC4849: RADIUS Filter Rule Attribute (9 pages) RFC5080: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes (28 pages) RFC5090: RADIUS Extension for Digest Authentication (33 pages) RFC5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (34 pages) * Updates RFC8559 RFC5607: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management (25 pages) RFC5997: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (24 pages) RFC6158: RADIUS Design Guidelines (38 pages) * Updates RFC6929 * Updates RFC8044 RFC6421: Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) (12 pages) RFC6613: RADIUS over TCP (16 pages) * Updates RFC7930 RFC6614: Transport Layer Security (TLS) Encryption for RADIUS (22 pages) RFC6911: RADIUS Attributes for IPv6 Access Networks (15 pages) RFC6929: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions (68 pages) RFC7268: RADIUS Attributes for IEEE 802 Networks (29 pages) * Updates RFC8044 RFC7360: Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS (27 pages) RFC7499: Support of Fragmentation of RADIUS Packets (38 pages) RFC7542: The Network Access Identifier (30 pages) RFC7585: Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) (32 pages) RFC7930: Larger Packets for RADIUS over TCP (10 pages) RFC8044: Data Types in RADIUS (35 pages) RFC8045: RADIUS Extensions for IP Port Configuration and Reporting (43 pages) RFC8559: Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol (21 pages) Remote ATtestation ProcedureS (rats) ------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Kathleen Moriarty Nancy Cam-Winget Ned Smith Security Area Directors: Roman Danyliw Benjamin Kaduk Security Area Advisor: Roman Danyliw Mailing Lists: General Discussion: rats@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rats Archive: https://mailarchive.ietf.org/arch/browse/rats/ Description of Working Group: Introduction ========== In network protocol exchanges, it is often the case that one entity (a relying party) requires evidence about the remote peer (and system components [RFC4949] thereof), in order to assess the trustworthiness of the peer. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party. A relying party can then decide whether to consider a remote system component trustworthy or not. To improve the confidence in a system component's trustworthiness, a relying party may require evidence about: * system component identity, * composition of system components, including nested components, * roots of trust, * assertion/claim origination or provenance, * manufacturing origin, * system component integrity, * system component configuration, * operational state and measurements of steps which led to the operational state, or * other factors that could influence trust decisions. While domain-specific attestation mechanisms such as Trusted Computing Group (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS), Fast Identity Online (FIDO) Alliance attestation, and Android Keystore attestation exist, there is no interoperable way to create and process attestation evidence to make determinations about system components among relying parties of different manufactures and origins. Goals ===== This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to relying parties. Given the security and privacy sensitive nature of these assertions/claims, the WG will specify approaches to protect this exchanged data. While a relying party may use reference, known, or expected values or thresholds to assess the assertions/claims, the procedures for this activity are out of scope for this WG (without rechartering). The working group will cooperate and coordinate with other IETF WGs such as TEEP, SUIT, and SACM, and work with organizations in the community, such as the TCG and the FIDO Alliance, as appropriate. The WG will also evaluate prior work such as NEA and proprietary attestation technologies like the Android Keystore. Program of Work ============== The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows: 1. Specify use cases for remote attestation (to document and achieve WG consensus but not expected to be published as an RFC). 2. Specify terminology and architecture that enable attestation techniques. The architecture may include a system security model for the signing key material and involve at least the system component, system component provider, and the relying authority. 3. Standardize an information model for assertions/claims which provide information about system components characteristics scoped by the specified use-cases. 4. Standardize data models that implement and secure the defined information model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures [RFC7519]). 5. Standardize interoperable protocols to securely convey assertions/claims. Goals and Milestones: Dec 2020 - Submit YANG Module draft to IESG for publication Dec 2020 - Submit TUDA draft to IESG for publication Mar 2021 - Submit EAT draft to IESG for publication Jul 2021 - Submit Interaction Models draft to IESG for publication Jul 2021 - Submit Architecture draft to IESG for publication Done - Begin work on use case documentation (may not be published as an RFC) Done - Call for adoption on EAT draft. Done - Call for adoption on architecture draft Done - Call for adoption on Yang Module draft Internet-Drafts: - Remote Attestation Procedures Architecture [draft-ietf-rats-architecture-07] (43 pages) - The Entity Attestation Token (EAT) [draft-ietf-rats-eat-04] (35 pages) - Reference Interaction Models for Remote Attestation Procedures [draft-ietf-rats-reference-interaction-models-01] (22 pages) - TPM-based Network Device Remote Integrity Verification [draft-ietf-rats-tpm-based-network-device-attest-05] (43 pages) - A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs [draft-ietf-rats-yang-tpm-charra-03] (56 pages) No Requests for Comments Reliable and Available Wireless (raw) ------------------------------------- Charter Last Modified: 2020-02-07 Current Status: Active Chairs: Eve Schooler Rick Taylor Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Deborah Brungard Mailing Lists: General Discussion: raw@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/raw Archive: https://mailarchive.ietf.org/arch/browse/raw/ Description of Working Group: Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity over a wireless medium. The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS), etc. Similar to DetNet, RAW will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability. While DetNet solutions apply to both wireless and wired, there has been recent industry interest for wireless applications which were not initially included in the DetNet use cases. One critical application is Aeronautical Data Communications. The Aeronautical standards work on a physical layer and data link layer for data communications is reaching maturity and there is significant interest in IP connectivity applications. Other examples of potential wireless applications include industrial, pro audio and video, gaming, and edge robotics. In the interests of providing timely solutions for these newly identified industry applications, RAW’s focus will be on specifying use cases associated with these new applications and defining requirements derived from them. RAW will solicit input on deployment plans, requirements, and operational practices (including security and privacy aspects) for these newer industrial applications. RAW’s primary focus is on identifying areas where the DetNet adaptation to wireless networks and other IETF technologies may require additional supporting mechanisms. The RAW Working Group will also examine the applicability of other existing IETF work, e.g., MANET's dynamic link exchange protocol (DLEP). The RAW Working Group will provide input to the DetNet Working Group, MANET Working Group, and other IETF Working Groups, and cooperate in reviewing solutions to RAW’s identified deployment problems. RAW is not chartered to work on a solution. If solution work is needed, the Working Group will coordinate with the IESG to determine where the work will be done. If RAW is chosen for the solution work, the Working Group will recharter. The RAW Working Group is planned to be a short timeframe (12-18 months) Working Group to quickly address these newer industry applications. The initial milestones will be published as Informational documents: Use Cases, Requirements, Architecture/Framework Aspects for a Wireless Network, and an Evaluation of Existing IETF Technologies and Gap Analysis. Additional documents may be published or exist on a git repository, the publication format will be agreed by the Working Group at the time the document is adopted by the group. The Use Case document may consist of one or more documents to allow users/operators the opportunity to provide comprehensive deployment plans for these new (to IETF) technologies, e.g., the Aeronautical Data Communication applications. The group will closely coordinate with the DetNet and MANET Working Groups. The work produced by this group may be of interest to other SDOs, 3GPP, IEEE, and the Aeronautical industry. Goals and Milestones: Sep 2020 - Working Group Adoption of Use Cases Document Sep 2020 - Working Group Adoption of Requirements Document Nov 2020 - Working Group Adoption of Architecture/Framework Aspects for a Wireless Network Document Nov 2020 - Use Cases Document submit to IESG Dec 2020 - Working Group Adoption of Evaluation of Existing IETF Technologies and Gap Analysis Document Dec 2020 - Requirements Document submit to IESG Apr 2021 - Architecture/Framework Aspects for a Wireless Network Document submit to IESG Jun 2021 - Evaluation of Existing IETF Technologies and Gap Analysis Document submit to IESG Internet-Drafts: - L-band Digital Aeronautical Communications System (LDACS) [draft-ietf-raw-ldacs-03] (34 pages) - Reliable and Available Wireless Technologies [draft-ietf-raw-technologies-00] (58 pages) - RAW use cases [draft-ietf-raw-use-cases-00] (23 pages) No Requests for Comments Registration Protocols Extensions (regext) ------------------------------------------ Charter Last Modified: 2019-03-27 Current Status: Active Chairs: Antoin Verschuren James Galvin Applications and Real-Time Area Directors: Murray Kucherawy Barry Leiba Applications and Real-Time Area Advisor: Barry Leiba Mailing Lists: General Discussion: regext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/regext Archive: https://mailarchive.ietf.org/arch/browse/regext/ Description of Working Group: Charter for Working Group The Extensible Provisioning Protocol (EPP, Standard 69) is the standard domain name provisioning protocol for top-level domain name registries. To avoid many separate EPP extensions that provide the same functions, it's important to coordinate and standardize EPP extensions. The EPP Extensions (EPPEXT) working group completed its first goal of creating an IANA registry of EPP extensions. The registration process of the registry is documented in RFC 7451. Extensions may be registered for informational purposes as long as there is a published specification that has been reviewed by a designated expert. The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the proposed standard for retrieving registration metadata from both domain name and Regional Internet Registries. To ensure interoperable implementations it's important to coordinate and standardize extensions and profiles to be used by registries. Extensions in both cases that are targeted for the Standards Track are subject to more thorough review and open discussion within the IETF. In addition, commonality may be discovered in related extensions, especially EPP extensions listed on the EPP extension registry, for which it would makes sense to merge them into a single standard extension everybody agrees on. The REGEXT working group is the home of the coordination effort for standards track extensions. The selection of extensions for standards track shall incorporate the following guidelines. 1. Proprietary documented extensions and individual submissions of informational or experimental EPP extensions will follow the expert review process as described in RFC 7451 for inclusion in the EPP extensions registry. These documents will not be part of the REGEXT working group work or milestones. The working group may discuss or advise on these documents. 2. Extensions that seek standards track status can be suggested for WG adoption. If accepted by the working group then the development of the standard may proceed. 3. When there are no more proposals for Standards-Track extensions, the working group will either close or become dormant, with the decision made in consultation with the responsible AD. In any case, the mailing list will remain open and available for the use of the expert review process as described in RFC 7451. The working group may also take on work to develop specifications that describe the following types of information exchanged between entities involved in Internet identifier registration that are using the RDAP or EPP protocols: * Uniform representation formats for publishing local policy or configuration options regarding EPP and RDAP use. * Data formats for files exchanged between registration entities that need insertion in or extraction from EPP or RDAP. * Technical guidance for registration processes that are supported by EPP or RDAP. Goals and Milestones: Nov 2019 - Submit for publication "Registration Data Access Protocol (RDAP) Reverse search capabilities" Jul 2020 - Submit for publication "EPP Secure Authorization Information for Transfer" Jul 2020 - Submit for publication "EPP Unhandled Namespaces" Aug 2020 - Submit for publication "JSON Responses for the Registration Data Access Protocol (RDAP)" Aug 2020 - Submit for publication "Registration Data Access Protocol (RDAP) Query Format" Oct 2020 - Submit for publication "Registry Maintenance Notifications for the EPP" Mar 2021 - Submit for publication "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect" Done - Submit for publication "Registry Fee Extension for EPP" Done - Submit for publication "Change Poll Extension for EPP" Done - Submit for publication "EPP Domain Name Mapping Extension for Bundling Registration" Done - Submit for publication "Login Security Extension for the Extensible Provisioning Protocol (EPP)" Done - Submit for publication "Registry Data Escrow Specification" Done - Submit for publication "Domain Name Registration Data (DNRD) Objects Mapping" Done - Submit for publication "Registration Data Access Protocol (RDAP) Partial Response" Done - Submit for publication "Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging" Internet-Drafts: - Finding the Authoritative Registration Data (RDAP) Service [draft-blanchet-regext-rfc7484bis-00] (17 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-gould-casanova-regext-unhandled-namespaces-02] (18 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-gould-regext-secure-authinfo-transfer-03] (24 pages) - Registration Data Access Protocol (RDAP) Query Format [draft-hollenbeck-regext-rfc7482bis-06] (25 pages) - JSON Responses for the Registration Data Access Protocol (RDAP) [draft-hollenbeck-regext-rfc7483bis-01] (85 pages) - Key Relay Mapping for the Extensible Provisioning Protocol [draft-ietf-eppext-keyrelay-12] (16 pages) - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-eppext-launchphase-07] (61 pages) - ICANN TMCH functional specifications [draft-ietf-eppext-tmch-func-spec-01] (60 pages) - Allocation Token Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-allocation-token-12] (17 pages) - Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration [draft-ietf-regext-bundling-registration-11] (25 pages) - Change Poll Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-change-poll-12] (20 pages) - Registry Data Escrow Specification [draft-ietf-regext-data-escrow-10] (23 pages) - Domain Name Registration Data (DNRD) Objects Mapping [draft-ietf-regext-dnrd-objects-mapping-10] (182 pages) - Third Party DNS operator to Registrars/Registries Protocol [draft-ietf-regext-dnsoperator-to-rrr-protocol-05] (15 pages) - Registry Fee Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-fees-20] (30 pages) - Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping [draft-ietf-regext-epp-rdap-status-mapping-04] (11 pages) - Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-epp-registry-maintenance-04] (20 pages) - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-launchphase-07] (58 pages) - Login Security Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-login-security-10] (21 pages) - Extensible Provisioning Protocol (EPP) China Name Verification Mapping [draft-ietf-regext-nv-mapping-00] (37 pages) - Extensible Provisioning Protocol (EPP) Organization Mapping [draft-ietf-regext-org-12] (43 pages) - Organization Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-org-ext-11] (22 pages) - Registration Data Access Protocol (RDAP) Object Tagging [draft-ietf-regext-rdap-object-tag-05] (13 pages) - Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect [draft-ietf-regext-rdap-openid-05] (25 pages) - Registration Data Access Protocol (RDAP) Partial Response [draft-ietf-regext-rdap-partial-response-16] (15 pages) - Registration Data Access Protocol (RDAP) Reverse search capabilities [draft-ietf-regext-rdap-reverse-search-05] (10 pages) - Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging [draft-ietf-regext-rdap-sorting-and-paging-19] (31 pages) - Extensible Provisioning Protocol (EPP) Reseller Mapping [draft-ietf-regext-reseller-01] (30 pages) - Reseller Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-reseller-ext-01] (18 pages) - Registration Data Access Protocol (RDAP) Query Format [draft-ietf-regext-rfc7482bis-02] (25 pages) - JSON Responses for the Registration Data Access Protocol (RDAP) [draft-ietf-regext-rfc7483bis-04] (85 pages) - Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer [draft-ietf-regext-secure-authinfo-transfer-04] (28 pages) - Simple Registration Reporting [draft-ietf-regext-simple-registration-reporting-01] (16 pages) - ICANN TMCH functional specifications [draft-ietf-regext-tmch-func-spec-08] (63 pages) - Extensible Provisioning Protocol (EPP) Unhandled Namespaces [draft-ietf-regext-unhandled-namespaces-04] (20 pages) - Validate Mapping for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-validate-04] (16 pages) - Verification Code Extension for the Extensible Provisioning Protocol (EPP) [draft-ietf-regext-verificationcode-06] (38 pages) - Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) [draft-sattler-epp-registry-maintenance-10] (22 pages) - Simple Registration Reporting [draft-yee-regext-simple-registration-reporting-01] (16 pages) Requests for Comments: BCP221: Registration Data Access Protocol (RDAP) Object Tagging (13 pages) RFC8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping (11 pages) RFC8063: Key Relay Mapping for the Extensible Provisioning Protocol (16 pages) RFC8334: Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) (58 pages) RFC8495: Allocation Token Extension for the Extensible Provisioning Protocol (EPP) (17 pages) RFC8521: Registration Data Access Protocol (RDAP) Object Tagging (13 pages) RFC8543: Extensible Provisioning Protocol (EPP) Organization Mapping (43 pages) RFC8544: Organization Extension for the Extensible Provisioning Protocol (EPP) (22 pages) RFC8590: Change Poll Extension for the Extensible Provisioning Protocol (EPP) (20 pages) RFC8748: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) (30 pages) RFC8807: Login Security Extension for the Extensible Provisioning Protocol (EPP) (21 pages) Routing In Fat Trees (rift) --------------------------- Charter Last Modified: 2020-03-20 Current Status: Active Chairs: Jeff Tantsura Zhaohui (Jeffrey) Zhang Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Mailing Lists: General Discussion: rift@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rift Archive: https://mailarchive.ietf.org/arch/search/?email_list=rift Description of Working Group: Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. Clos and Fat-Tree topologies have gained popularity in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services. The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence. It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification that will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed, security and privacy mitigations for the protocol as identified in the threat analysis document. (q.v.) - A YANG module focused on configuration and monitoring of protocol instances - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors, which shall be sent for publication at the same time as the protocol specification Goals and Milestones: Apr 2020 - Submit protocol specification to IESG for publication Aug 2020 - Submit YANG module to IESG for publication Aug 2020 - Submit Applicability Statement to IESG for publication Done - Adopt a protocol specification document Internet-Drafts: - RIFT Applicability [draft-ietf-rift-applicability-03] (29 pages) - RIFT: Routing in Fat Trees [draft-ietf-rift-rift-12] (163 pages) - A YANG Data Model for Routing in Fat Trees (RIFT) [draft-ietf-rift-yang-01] (34 pages) - RIFT: Routing in Fat Trees [draft-przygienda-rift-05] (67 pages) - RIFT Applicability [draft-wei-rift-applicability-02] (23 pages) - RIFT YANG Model [draft-zhang-rift-yang-02] (22 pages) No Requests for Comments RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------- Charter Last Modified: 2020-03-25 Current Status: Active Chairs: Anna Brunstrom Colin Perkins Transport Area Directors: Martin Duke Magnus Westerlund Transport Area Advisor: Martin Duke Mailing Lists: General Discussion: rmcat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rmcat Archive: https://mailarchive.ietf.org/arch/browse/rmcat/ Description of Working Group: Today's Internet traffic includes interactive real-time media, which is often carried via sets of flows using RTP over UDP. There is no generally accepted congestion control mechanism for this kind of data flow. With the deployment of applications using the RTCWEB protocol suite, the number of such flows is likely to increase, especially non-fixed-rate flows such as video or adaptive audio. There is therefore some urgency in specifying one or more congestion control mechanisms that can find general acceptance. Congestion control algorithms for interactive real time media may need to be quite different from the congestion control of TCP: for example, some applications can be more tolerant to loss than delay and jitter. The set of requirements for such an algorithm includes, but is not limited to: - Low delay and low jitter for the case where there is no competing traffic using other algorithms - Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves. - Effective use of signals like packet loss and ECN markings to adapt to congestion The working group will: - Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. This must be completed prior to finishing any Experimental algorithm specifications. - Identify interactions between applications and RTP flows to enable conveying helpful cross-layer information such as per-packet priorities, flow elasticity, etc. This information might be used to populate an API, but the WG will not define a specific API itself. - Determine if extensions to RTP/RTCP are needed for carrying congestion control feedback, using DCCP as a model. If so, provide the requirements for such extensions to the AVTCORE working group for standardization there. - Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM. - Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck. - Define evaluation criteria for proposed congestion control mechanisms, and publish these as an Informational RFC. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Find or develop candidate congestion control algorithms, verify that these can be tested on the Internet without significant risk, and publish one or more of these as Experimental RFCs. - Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one algorithm; in this case it will be one of the objects of the experimentation to determine the applicabilities and relative merits of the algorithms. - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether there are significant flaws, such as ones that turn out to be harmful to flows using or competing with them. If so, the WG will write a document describing the issues encountered and recommending to the IESG to move the specification to Historic status. The work will be guided by the advice laid out in RFC 5405 (UDP Usage Guidelines), RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion Control Algorithms). The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere: - Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE - Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic - Defining active queue management algorithms or modifications to TCP of any kind - Multicast congestion control; common control of multiple unicast flows is in scope - Topologies other than point-to-point connections; implications on multi-hop connections will be considered at a later stage The working group is expected to work closely with the RAI area, including the underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and the applications/protocol suites being developed in the CLUE and RTCWEB working groups. It will also coordinate closely with other Transport area groups working on congestion control, and with the Internet Congestion Control Research Group of the IRTF. Deliverables: - Requirements for congestion control algorithms for interactive real time media as an Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media as an Informational RFC - Requirements for RTCP extensions for use with congestion control algorithms as an input to the AVTCORE WG. - Interactions between applications and RTP flows as an Informational RFC - Identifying and controlling groups of flows as a Proposed Standard RFC - Techniques to detect, instrument or diagnose failing to meet RT schedules as either an Informational RFC or on the Standards Track if needed for interoperability or other aspects that would justify it. - Candidate congestion control algorithm for interactive real time media as Experimental RFCs (likely more than one) - Experimentation and evaluation results for candidate congestion control algorithms as an Informational RFC - One or more recommended congestion control algorithms for interactive real time media as Proposed Standard RFCs Goals and Milestones: Nov 2020 - Publish first draft of evaluation results Nov 2020 - Publish first draft of Standards Track congestion control algorithm Mar 2021 - Submit congestion control to IESG for Proposed Standard Done - Adopt first WG draft on requirements Done - Adopt first WG draft on evaluation criteria Done - Adopt first WG draft of RTCP extensions for use with congestion control algorithms and interactions between applications and RTP flows (if needed) Done - Adopt first congestion control candidate as WG draft Done - Adopt first WG draft on identifying and controlling groups of flows Done - Submit identifying and controlling groups of flows to IESG for Experimental publication Done - Submit first congestion control candidate to IESG for Experimental publication Done - Submit RTCP extension requirements for use with congestion control algorithms to AVTCORE (if needed) Done - Submit requirements and evaluation criteria to IESG as Informational Internet-Drafts: - A Google Congestion Control Algorithm for Real-Time Communication [draft-alvestrand-rmcat-congestion-03] (19 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control [draft-dt-rmcat-feedback-message-04] (10 pages) - Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. [draft-hayes-rmcat-sbd-02] (18 pages) - RTP Application Interaction with Congestion Control [draft-ietf-rmcat-app-interaction-01] (15 pages) - Congestion Control and Codec interactions in RTP Applications [draft-ietf-rmcat-cc-codec-interactions-02] (12 pages) - Congestion Control Requirements for Interactive Real-Time Media [draft-ietf-rmcat-cc-requirements-09] (12 pages) - Coupled Congestion Control for RTP Media [draft-ietf-rmcat-coupled-cc-09] (20 pages) - Evaluating Congestion Control for Interactive Real-time Media [draft-ietf-rmcat-eval-criteria-14] (17 pages) - Test Cases for Evaluating RMCAT Proposals [draft-ietf-rmcat-eval-test-10] (33 pages) - A Google Congestion Control Algorithm for Real-Time Communication [draft-ietf-rmcat-gcc-02] (19 pages) - Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media [draft-ietf-rmcat-nada-13] (26 pages) - RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences [draft-ietf-rmcat-rtp-cc-feedback-05] (12 pages) - Shared Bottleneck Detection for Coupled Congestion Control for RTP Media [draft-ietf-rmcat-sbd-11] (25 pages) - Self-Clocked Rate Adaptation for Multimedia [draft-ietf-rmcat-scream-cc-13] (36 pages) - Video Traffic Models for RTP Congestion Control Evaluations [draft-ietf-rmcat-video-traffic-model-07] (19 pages) - Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks [draft-ietf-rmcat-wireless-tests-11] (23 pages) - Congestion Control Requirements For RMCAT [draft-jesup-rmcat-reqs-01] (9 pages) - Self-Clocked Rate Adaptation for Multimedia [draft-johansson-rmcat-scream-cc-05] (27 pages) - Test Cases for Evaluating RMCAT Proposals [draft-sarker-rmcat-eval-test-01] (36 pages) - Evaluating Congestion Control for Interactive Real-time Media [draft-singh-rmcat-cc-eval-04] (19 pages) - Coupled congestion control for RTP media [draft-welzl-rmcat-coupled-cc-05] (20 pages) - RTP Application Interaction with Congestion Control [draft-zanaty-rmcat-app-interaction-01] (14 pages) - Congestion Control and Codec interactions in RTP Applications [draft-zanaty-rmcat-cc-codec-interactions-00] (11 pages) - Framework for Real-time Media Congestion Avoidance Techniques [draft-zhu-rmcat-framework-00] (8 pages) - NADA: A Unified Congestion Control Scheme for Real-Time Media [draft-zhu-rmcat-nada-06] (18 pages) Requests for Comments: RFC8298: Self-Clocked Rate Adaptation for Multimedia (36 pages) RFC8382: Shared Bottleneck Detection for Coupled Congestion Control for RTP Media (25 pages) RFC8593: Video Traffic Models for RTP Congestion Control Evaluations (19 pages) RFC8698: Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media (26 pages) RFC8699: Coupled Congestion Control for RTP Media (20 pages) Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Charter Last Modified: 2019-11-27 Current Status: Active Chairs: Dominique Barthel Ines Robles Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Alvaro Retana Secretary: Michael Richardson Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: https://mailarchive.ietf.org/arch/browse/roll/ Description of Working Group: Low power and Lossy Networks (LLNs ) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. RFC7102 discusses ROLL specific aspects of LLNs, and RFC7228 provides additional terminology for constrained devices. RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from several application perspectives. The Working Group has focused on routing solutions for the areas: connected home, building, and urban sensor networks. It has developed a Framework that takes into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group continues to focus on routing issues for LLN and to maintain, improve and streamline the protocols already developed, including RPL and MPL. The focus is on IPv6 work only. The Working Group will pay particular attention to routing security and manageability (e.g., self-configuration) issues. The working group will consider the transport characteristics that routing protocol messages will experience. ROLL will coordinate closely with the working groups in other areas that focus on constrained networks and/or constrained nodes, such as 6lo, 6tisch, ipwave, lwig and CoRE. Other working groups such as pim, bier and manet will be consulted as needed. The Working group will align with the 6man WG when needed. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Additional protocol elements to reduce packet size and the amount of required routing states - Automatic selection of MPL forwarders to reduce message replication. - Data models for RPL and MPL management. - Multicast enhancements algorithms. Goals and Milestones: Mar 2020 - Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG Mar 2020 - Initial submission of Common Ancestor Objective Functions and Parent Set DAG Metric Container Extension to the IESG Jun 2020 - Initial submission of a proposal for Source-Route Multicast for RPL to the IESG Jun 2020 - Initial submission of a proposal to augment DIS flags and options to the IESG Jun 2020 - Initial submission of Enabling secure network enrollment in RPL networks draft to the IESG Jul 2020 - Initial submission of a YANG model for MPL to the IESG Jul 2020 - Initial submission of a root initiated routing state in RPL to the IESG Dec 2020 - Initial submission of Mode of Operation extension and Capabilities for RPL to the IESG Oct 2021 - Recharter WG or close Done - Initial submission of a solution to the problems due to the use of No-Path DAO Messages to the IESG Done - Initial submission of a reactive P2P route discovery mechanism based on AODV-RPL protocol to the IESG Done - Initial submission of routing for RPL Leaves draft to the IESG Done - Initial submission to the IESG of mechanism to turn on RFC8138 compression feature within a RPL network Internet-Drafts: - MPL Parameter Configuration Option for DHCPv6 [draft-doi-roll-mpl-parameter-configuration-05] (10 pages) - Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-admin-local-policy-03] (15 pages) - AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-Power and Lossy Networks [draft-ietf-roll-aodv-rpl-08] (27 pages) - Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks [draft-ietf-roll-applicability-ami-15] (24 pages) - Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control [draft-ietf-roll-applicability-home-building-12] (38 pages) - ROLL Applicability Statement Template [draft-ietf-roll-applicability-template-09] (10 pages) - Building Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-building-routing-reqs-09] (26 pages) - RPL Capabilities [draft-ietf-roll-capabilities-07] (16 pages) - Constrained-Cast: Source-Routed Multicast for RPL [draft-ietf-roll-ccast-01] (10 pages) - Root initiated routing state in RPL [draft-ietf-roll-dao-projection-14] (31 pages) - DIS Modifications [draft-ietf-roll-dis-modifications-01] (15 pages) - Efficient Route Invalidation [draft-ietf-roll-efficient-npdao-18] (23 pages) - Controlling Secure Network Enrollment in RPL networks [draft-ietf-roll-enrollment-priority-03] (8 pages) - Home Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-home-routing-reqs-11] (17 pages) - Industrial Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-indus-routing-reqs-06] (27 pages) - The Minimum Rank with Hysteresis Objective Function [draft-ietf-roll-minrank-hysteresis-of-11] (13 pages) - Mode of Operation extension [draft-ietf-roll-mopex-02] (9 pages) - Mode of Operation extension and Capabilities [draft-ietf-roll-mopex-cap-01] (10 pages) - MPL Forwarder Select (MPLFS) [draft-ietf-roll-mpl-forw-select-00] (10 pages) - Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 [draft-ietf-roll-mpl-parameter-configuration-08] (10 pages) - A YANG model for Multicast Protocol for Low power and lossy Networks (MPL) [draft-ietf-roll-mpl-yang-02] (30 pages) - Common Ancestor Objective Function and Parent Set DAG Metric Container Extension [draft-ietf-roll-nsa-extension-09] (17 pages) - Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-roll-of0-20] (14 pages) - A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network [draft-ietf-roll-p2p-measurement-10] (29 pages) - Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [draft-ietf-roll-p2p-rpl-17] (40 pages) - Overview of Existing Routing Protocols for Low Power and Lossy Networks [draft-ietf-roll-protocols-survey-07] (26 pages) - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header [draft-ietf-roll-routing-dispatch-05] (37 pages) - Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks [draft-ietf-roll-routing-metrics-19] (30 pages) - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [draft-ietf-roll-rpl-19] (157 pages) - RPL applicability in industrial networks [draft-ietf-roll-rpl-industrial-applicability-02] (31 pages) - RPL Observations [draft-ietf-roll-rpl-observations-04] (20 pages) - A Security Framework for Routing over Low Power and Lossy Networks [draft-ietf-roll-security-framework-07] (49 pages) - A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) [draft-ietf-roll-security-threats-11] (40 pages) - Terms Used in Routing for Low-Power and Lossy Networks [draft-ietf-roll-terminology-13] (8 pages) - The Trickle Algorithm [draft-ietf-roll-trickle-08] (13 pages) - Multicast Protocol for Low-Power and Lossy Networks (MPL) [draft-ietf-roll-trickle-mcast-12] (29 pages) - A RPL DODAG Configuration Option for the 6LoWPAN Routing Header [draft-ietf-roll-turnon-rfc8138-17] (10 pages) - Routing for RPL Leaves [draft-ietf-roll-unaware-leaves-22] (38 pages) - Routing Requirements for Urban Low-Power and Lossy Networks [draft-ietf-roll-urban-routing-reqs-05] (21 pages) - Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane [draft-ietf-roll-useofrplinfo-41] (63 pages) - ROLL Applicability Statement Template [draft-richardson-roll-applicability-template-02] (15 pages) - MPL forwarder policy for multicast with admin-local scope [draft-vanderstok-roll-admin-local-policy-00] (8 pages) Requests for Comments: RFC5548: Routing Requirements for Urban Low-Power and Lossy Networks (21 pages) RFC5673: Industrial Routing Requirements in Low-Power and Lossy Networks (27 pages) RFC5826: Home Automation Routing Requirements in Low-Power and Lossy Networks (17 pages) RFC5867: Building Automation Routing Requirements in Low-Power and Lossy Networks (26 pages) RFC6206: The Trickle Algorithm (13 pages) RFC6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (157 pages) RFC6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (30 pages) RFC6552: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (14 pages) RFC6719: The Minimum Rank with Hysteresis Objective Function (13 pages) RFC6997: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (40 pages) RFC6998: A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network (29 pages) RFC7102: Terms Used in Routing for Low-Power and Lossy Networks (8 pages) RFC7416: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) (40 pages) RFC7731: Multicast Protocol for Low-Power and Lossy Networks (MPL) (29 pages) RFC7732: Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) (15 pages) RFC7733: Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control (38 pages) RFC7774: Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 (10 pages) RFC8036: Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (24 pages) RFC8138: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header (37 pages) Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2018-03-21 Current Status: Active Chairs: Chris Bowers Jeff Tantsura Routing Area Directors: Deborah Brungard Alvaro Retana Martin Vigoureux Routing Area Advisor: Martin Vigoureux Secretary: Yingzhen Qu Mailing Lists: General Discussion: rtgwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtgwg Archive: https://mailarchive.ietf.org/arch/browse/rtgwg/ Description of Working Group: The Routing Area working group (RTGWG) is chartered to provide a venue to discuss, evaluate, support and develop proposals for new work in the Routing Area and may work on specific small topics that do not fit with an existing working group. Options for handling new work include: - Directing the work to an existing WG (including RTGWG) - Developing a proposal for a BoF. - Developing a charter and establishing consensus for a new WG. This option will primarily be used with fairly mature and/or well-defined efforts. - Careful evaluation, leading to deferring or rejecting work. It is expected that the proposals for new work will only include items which are not aligned with the work of other WGs or that may span multiple WGs. The Area Directors and WG Chairs can provide guidance if there is any doubt wheth